Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

error when updating legacy module with CAPS in name #4665

Closed
dominictarr opened this Issue Feb 13, 2014 · 7 comments

Comments

Projects
None yet
5 participants

caps are no longer legal in module names, but there are a few modules that do have caps in the name, that where published before this rule was created.

I tried to update JSONStream today, but I got an error. It's good that npm prevents publishing new modules with uppercase letters in the name, but it should allow updating an old module that has uppercase letters.

the alternative would be migrating all modules to use lower case names, but this would require updating all the modules which depend on uppercase modules...

(the restriction is only in the client - so I was able to update the module, but only using an alternative npm publish - my npm-atomic-publish which a wrote a few months back as part of my npmd project.)

anvaka commented Feb 13, 2014

Looks like iriscouch got it semi updated, and now returns v.0.8.0, which is missing _id property:
http://isaacs.iriscouch.com/registry/_design/scratch/_view/byField?keys=%5B%22JSONStream%22%5D

Response:

{
  "total_rows": 58673,
  "offset": 27840,
  "rows": [
    {
      "id": "JSONStream",
      "key": "JSONStream",
      "value": {
        "name": "JSONStream",
        "version": "0.8.0",
        "description": "rawStream.pipe(JSONStream.parse()).pipe(streamOfObjects)",
        "homepage": "http://github.com/dominictarr/JSONStream",
        "repository": {
          "type": "git",
          "url": "git://github.com/dominictarr/JSONStream.git"
        },
        "dependencies": {
          "jsonparse": "0.0.5",
          "through": "~2.2.7"
        },
        "devDependencies": {
          "it-is": "~1",
          "assertions": "~2.2.2",
          "render": "~0.1.1",
          "trees": "~0.0.3",
          "event-stream": "~0.7.0",
          "tape": "~0.3.3"
        },
        "author": "Dominic Tarr <dominic.tarr@gmail.com> (http://bit.ly/dominictarr)",
        "scripts": {
          "test": "set -e; for t in test/*.js; do echo '***' $t '***'; node $t; done"
        },
        "scripts.test": "set -e; for t in test/*.js; do echo '***' $t '***'; node $t; done",
        "optionalDependencies": {},
        "engines": {
          "node": "*"
        },
        "readmeFile": "readme.markdown",
        "dist": {
          "shasum": "efc462d5a5bc94ec007f4b22571acd7f6f2ae013",
          "tarball": "https://fullfatdb.npmjs.com/registry/JSONStream/JSONStream-0.8.0.tgz"
        },
        "maintainers": [
          {
            "name": "dominictarr",
            "email": "dominic.tarr@gmail.com"
          }
        ]
      }
    }
  ]
}

@anvaka anvaka added a commit to anvaka/npmgraph that referenced this issue Feb 13, 2014

@anvaka anvaka Temprorary workaround until npm issue is fixed 60c44f2
Contributor

smikes commented Jan 6, 2015

Is this still broken, or was it fixed/worked around?

We are trying to clean up older npm issues, so if we don't hear back from you within a week, we will close this issue. (Don't worry -- you can always come back again and open a new issue!)

Thanks!

Contributor

othiym23 commented Jan 15, 2015

We will probably be merging and migrating legacy packages with caps in their names as part of the rollout of registry-2, the version of the registry that supports private packages. This will be happening over the next few months.

normalize-package-data, the module that npm-registry-client and read-package-data use to do package name verification, will only complain about caps in package names if the normalizer is run in strict mode (which it currently is, at least in npm-registry-client). We should probably still warn on deprecation here, but not error. A patch for this would be most welcome! I won't be able to get to it for at least a month (by which point we may have migrated everything to all-lowercase names, rendering this issue moot).

Contributor

smikes commented Jan 16, 2015

I'm probably not going to bite on this -- want to spend some more time on pure-fts this weekend -- but I might circle back in a couple weeks if it hasn't been touched. @faiq, want a fun one to work on?

Contributor

smikes commented May 3, 2015

ping to the registry team ( @bcoe ? )- is there any change to the backend wrt this issue?

Owner

bcoe commented May 3, 2015

@smikes we now allow legacy packages to have capital letters, but don't allow new packages to be created with capital letters in their name -- long story short, I think with a change to client code, we could fix these publication issues.

Contributor

othiym23 commented Nov 4, 2015

This has since been fixed in both npm@2 and npm@3 to follow the restrictions mentioned by @bcoe above – legacy packages with mixed-case names can be updated, but new packages must include only lowercase letters in their names. There's still an outstanding project to deal with the cases in which the package names collide, but that's a project for the registry team and npm support, and not the CLI team.

@othiym23 othiym23 closed this Nov 4, 2015

@othiym23 othiym23 removed the next-patch label Nov 4, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment