Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

package.json name cannot have spaces #3105

Closed
avoidwork opened this Issue · 9 comments

5 participants

Jason Mulligan isaacs Mariusz Nowak Brett Zamir Nathan Zadoks
Jason Mulligan

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
Owner

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.

isaacs isaacs closed this
Jason Mulligan

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
Owner

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

Hahahahahahaahhahahaahhahahaha.

Good one.

isaacs isaacs reopened this
isaacs isaacs closed this
Mariusz Nowak

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
Owner

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

Mariusz Nowak

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

Brett Zamir

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

Nathan Zadoks
Collaborator

@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'
Brett Zamir

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.