package.json name cannot have spaces

[avoidwork]

package.json cannot have a name with spaces in it. I'm sure there's a reason for this constraint, but it doesn't make sense to me as an end user, considering this is a JSON document.

Outside of the context of npmjs.org, this constraint can hurt adoption and cause a lot of wasted cycles trying to understand why any npm fails.

I'm using grunt to build some enterprise apps that will never land on npmjs.org, so in that context I'd argue this is a bug.

[isaacs]

It's by design. Not changing. Yes, of course, JSON can handle spaces just fine, but they're a pita on file systems, command lines, and urls, which are places that package names often appear.

Wontfix.

[avoidwork]

That's a poor excuse to not replace(" ", "\ "), and has a negative impact on end user UX. Being a package manager means it should afford everything the end user could want.

[isaacs]

Being a package manager means it should afford everything the end user could want.

Hahahahahahaahhahahaahhahahaha.

Good one.

[medikoo]

Name is rather a human readable id than description, it should allow just tight subset of characters.

There was already a problem when it was possible to create two packages that have same name but written with different case, it was impossible to install them both in one project on most systems. Thankfully it's no longer possible.

It's great the way it is now, the only thing that could imo be improved is to use just lower-case chars for package names, but it's probably too late for that, and people would yell ;-)

[isaacs]

@medikoo New packages can only have lowercase names. Existing packages are grandfathered in.

[medikoo]

@isaacs That's great, I wasn't aware.

[brettz9]

(Posting here as may be of interest to followers of this issue)

Is there no way around the lower case restriction? I have been using a convention for a shim loader plugin that the requested file contain the object name to shim (e.g., Array.prototype.map.js).

Although many of the shims one might use or create would be for the browser (and I understand npm is not confined to Node code), it is also possible one might wish to use it for up-and-coming JS features in Node too. In either case, it would be nice if I didn't need to require shim creators to follow some other means of mapping a requested shim-as-object into a file name. Any chance of a change back or a suggested way around this? Thanks...

[edef1c]

@brettz9 a little creativity easily solves this (the initial-capital isn't perfect, but this does its best to fit in with the npm slug naming convention)

> function convert(str) { return str.slice('shim-'.length).replace(/(.|^)-(.)/g, function(_, a, b) { return a + b.toUpperCase() }) }
undefined
> convert('shim--array.prototype.for-each')
'Array.prototype.forEach'

[brettz9]

Yes, thank you--I was just hoping to avoid workarounds like these which may add some extra hassle, however minor, to people wanting to distribute a shim. On the plus side, I guess at least the prefix does help namespace things so that if some popular library comes around that is simply called "Array", there won't be a conflict (unless someone made an implementation one doesn't like of the same name but there are ways I can work around this). But if upper-case were allowed, it would be ideal.