npm list should warn if a package name is not publishable

[appsforartists]

Currently, npm publish will fail if your module name contains any characters other than [a-z\-]. However, it is very likely that users new to npm will choose names with capital letters or underscores; JavaScript identifiers are conventionally CamelCased, and file/folder names are often snake_cased.

It is incredibly frustrating to invest hundreds of hours into developing a package only to find out at the last minute that you can't publish it because there is an undocumented name validator that disagrees with your name choice. Because of the nature of dependency management, this forces you to rename every require statement in every module that imports your package, as well as modify any other pieces of code that make presumptions about the naming or organization of your filesystem. It's a problem that cascades across interdependent packages and needlessly risks introducing errors.

npm list already warns about all kinds of things, and it's run commonly enough that a user should be warned fairly early if npm detects a package whose name it disagrees with. As such, it should throw a warning if one of your dependencies does not follow the kebab-case convention.

[appsforartists]

(On a separate note, I'm really curious how a package manager for a language that's conventionally CamelCased decided that all packages must be kebab-cased, especially since the node_modules folder itself is snake_cased.)

[kenany]

[a-z\-]

Where is this regex from? normalize-package-data has the validation logic, and from its docs:

If name field is given, the value of the name field must be a string. The string may not:

• start with a period.
• contain the following characters: /@\s+%
• contain and characters that would need to be encoded for use in urls.
• resemble the word node_modules or favicon.ico (case doesn't matter).

validate-npm-package-name, used by the website, allows underscores, periods, and even exclamation marks (I didn't even know about that last one).

all packages must be kebab-cased, especially since the node_modules folder itself is snake_cased

Underscores are allowed, so one can snake_case if they want.

[appsforartists]

That's just from my experience. It's not pulled from anywhere official.

I thought I had seen snake_case rejected in the past. Perhaps not. Still insane that CamelCasing isn't allowed on a JS-focus package manager.

[smikes]

It is incredibly frustrating to invest hundreds of hours into developing a package only to find out at the last minute that you can't publish it because there is an undocumented name validator that disagrees with your name choice. Because of the nature of dependency management, this forces you to rename every require statement in every module that imports your package, as well as modify any other pieces of code that make presumptions about the naming or organization of your filesystem. It's a problem that cascades across interdependent packages and needlessly risks introducing errors.

I agree, it is frustrating. My first package that I wanted to publish was for processing International Chemical Identifiers -- generally styled InChI -- and I had all sorts of pain from that. 😞

npm modules names have been required to be lowercase-only for a long time. Some of the reasons for that are listed here: #3914 (comment)

and then there's this:

Also, in Node, require parameters are case-insensitive.

It looks like something like the feature suggested here : #4627 would have helped in this situation.

Or maybe even earlier -- should we treat this as a feature request that npm init should warn if the package name does not satisfy the requirements of normalize-package-data?

[appsforartists]

Should we treat this as a feature request that npm init should warn if the package name does not satisfy the requirements of normalize-package-data?

That's a good start. npm list is also good to have, for people who hand-write their own JSON.

[smikes]

There are some related issues and maybe even some PRs. I will try to find them.

One wrinkle is that there are some legacy mixed-case modules, and uppercase is allowed in private module names, so there may need to be a config switch to turn off the warning.

/cc @othiym23 feature-request

[othiym23]

npm list is also good to have, for people who hand-write their own JSON.

That's a weird place to put validation for package metadata. npm ls should only be checking that dependencies check out. The under-development multi-stage branch has a new --dry-run option that can be used in a few different ways, and while I think it mostly only affects installation right now, it wouldn't be super tough to extend it to publishing so that we can do all of the preflighting checks in one place before trying to push anything to the registry, letting you validate as you go. That seems like the correct way to handle this.

We're also working on more clearly documenting all the restrictions on package names, which I agree that npm as a team has done a less than stellar job of thus far.

[othiym23]

This has been moved to the npm roadmap, which we're using instead of the confusing next-* labels now.

[npm-robot]

We're closing this issue as it has gone thirty days without activity. In our experience if an issue has gone thirty days without any activity then it's unlikely to be addressed. In the case of bug reports, often the underlying issue will be addressed but finding related issues is quite difficult and often incomplete.

If this was a bug report and it is still relevant then we encourage you to open it again as a new issue. If this was a feature request then you should feel free to open it again, or even better open a PR.

For more information about our new issue aging policies and why we've instituted them please see our blog post.