Skip to content


package.json name cannot have spaces #3105

avoidwork opened this Issue · 9 comments

5 participants


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, 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, so in that context I'd argue this is a bug.


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.


@isaacs isaacs closed this

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.


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


Good one.

@isaacs isaacs reopened this
@isaacs isaacs closed this

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 ;-)


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


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


(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.,

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...


@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() }) }
> convert('shim--array.prototype.for-each')

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.