Letter case for npm packages

[scanossmining]

Hello,

According to the specifications for the npm purl type, the package name inside the purl should be lowercased, however this would trigger some purl duplication. npmjs.com hosts case sensitive packages, some examples being:

• base64 and Base64
• dva, DVA, DvA, dVa

[stevespringett]

By convention, npm is lowercase. The spec states the name SHOULD be lowercased, but it doesn't state that it MUST be lowercased. I do think we need clarity here though.

This issue was recently discovered in the official Package URL Java implementation and has subsequently been corrected. package-url/packageurl-java#38 There may be other implementations also affected.

[scanossmining]

Hi @stevespringett , thanks for answering this, it's clearer now.
Before creating the issue, I've read the npm type specs here https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst#npm ,where it says

Per the package.json spec, new package "must not have uppercase letters in the name", therefore the must be lowercased.

I guess it's a typo there and the ending was supposed to say "therefore the package must be lowercased" ?

[pombredanne]

@scanossmining re:

I guess it's a typo there and the ending was supposed to say "therefore the package must be lowercased" ?

Yes, good catch! PR welcomed!

[iamwillbar]

From the npm documentation:

The name must be less than or equal to 214 characters. This includes the scope for scoped packages.
The names of scoped packages can begin with a dot or an underscore. This is not permitted without a scope.
New packages must not have uppercase letters in the name.
The name ends up being part of a URL, an argument on the command line, and a folder name. Therefore, the name can't contain any non-URL-safe characters.

The use of the word "New" on the third rule implies that this doesn't apply to existing packages. Since we want purls to be able to reference "new" and "old" packages that means we'd need to support mixed-case. The case should match the case used in the package's package.json.

[wesleytodd]

The use of the word "New" on the third rule implies that this doesn't apply to existing packages.

Sorry for reviving an old thread, but you are correct that there are older packages with names not following current rules.

I will expand on this to say that while I agree with some of the apparent goals of this project, you are going to have a really tough time trying to get adoption in the JS ecosystem because you chose to break from the existing well understood and widely deployed formats. Honestly looking at the work in this repo, it looks like y'all skipped the step of asking folks who work on the JS package managers what they think.

Not sure if y'all are too far along here to make a change in direction, but I would guess based on this issue that if you want a standard which is used by the npm registry that you will really need to re-assess the current proposal.

[pombredanne]

This came up again. @wesleytodd if you can reel in npm maintainers that would be awesome.

Here is the status so far:

People are technically correct that npm used to support mixed case names in the past. But this is has long been not the case.
The npm package.json spec is clear on this. Please see: https://docs.npmjs.com/cli/v11/configuring-npm/package-json

New packages must not have uppercase letters in the name.

New was 10+ years ago:
https://web.archive.org/web/20150516132705/https://docs.npmjs.com/files/package.json

There are possibly a few legacy old warts alright, and @zeke did nicely track them all at https://github.com/nice-registry/mixed-case-package-names and 719 legacy npm names have overlapping names, for which both a mixed-case and lowercase package exist.

Questions:

1. Is it allowed to publish an npm package to the public registry with mixed case names today?
2. Are there any active, non-deprecated packages with mixed case on the public registry?

@matt-phylum ping because of your comment in:

• Add validation tests #614 (comment)

Overall, I am fine going either way, but I would not want to get weird validation just as a exception for a few old, legacy packages from 10+ years ago that are likely unused. So it would be great to get evidence.