The npm community forum has been discontinued.
To discuss usage of npm, visit the GitHub Support Community.
It would be awesome to support
package.json is typically edited by humans, and JSON5 was designed as a small superset to JSON exactly for that purpose. It allows comments, unquoted keys and trailing comments.
I believe this could be done in a 100% backward compatible way. We simply need that
npm publish automatically translate
package.json. Thus, anyone downloading any npm library would still get a
package.json as before (and no
npm install could look for a
package.json file, and if none is found look for a
package.json5. Developers could thus work locally with the
package.json5 file instead (assuming they had a version of
npm that supports it). Meanwhile, end users wouldn’t see that
package.json5 and could still use an old version of
I would be glad to provide a PR for this if the general idea is accepted.
Note: Babel already supports JSON5 for its
I should have mentioned that I am aware of previous discussions on Github, in particular proposals that focused on
package.yml. I’d like to point out that YAML (even just “safe” YAML without arbitrary objects) isn’t 1-to-1 with JSON (for example it allows recursive structures), so makes it way more complicated and less adequate than JSON5. JSON5 is both simple, safe, and has the same domain as JSON.
Moreover, I’ve not seen a discussion about a way to make it 100% backwards compatible before, so I hope that my proposal doesn’t offend anyone.
I think this is an interesting idea, but I think there’s more to the implementation than that. For example, comments would need to be preserved when npm changes the package (e.g. when adding dependencies, changing the version, etc.), and I don’t know how difficult that would be with the JSON5 stringifier. Besides, npm would need to track whether to write to
package.json5 in that case.
Good points. It is not currently possible to edit JSON5 files and maintain the original format, although it’s in the plan.
I was proposing support for either
package.json5, never both concurrently.
We could still go ahead and not support rewriting
package.json5, instead print something like “npm can not currently modify ‘package.json5’, you need to add the dependency “foo: ‘^0.1.0’” manually”.
I can’t say how many developers would be willing to pay the price for not having
npm modify the
package.json5 (at least initially). Personally, I never use these features, which is why I didn’t think about it :-)
The biggest hurdle to a separate manifest format is the …entire node.js ecosystem? Like, literally all of it. Module resolution during
require(), myriad tools that read
package.json for config props, and so forth. JSON isn’t perfect, but it’s Good Enough™.
It shouldn’t be necessary 95% of the time. Manipulating dependencies (add/upgrade/remove) should almost always be done from CLI commands, as they properly synchronize the lockfile and whatnot. Modifying scripts, sure, that’s manual, but how frequently does that happen in a given project?
Thanks for the reply. I understand that many tools read the ‘package.json’ file directly. If they do it with
require('./package'), then they would be compatible, otherwise they’d need to be updated. Maybe a basic API to access package information would be helpful, and pave the way for more flexible structure if ever desired (e.g. allowing config files separate from dependency lists, …)?
Indeed it usually isn’t necessary, as far as the dependency list go. Nor is using the CLI necessary either and I don’t see why it “should be done” this way. Synchronizing the lockfile happens with
npm install. I’m not aware of any other “whatnot” that needs to be taken into account. All the other options of
package.json need to be edited manually. I believe that giving the option to developers to edit their package file however they prefer, and allowing very helpful features (comments in particular) would be a win.
My two top wishlist related to packge.json adopting json5
- supporting tailing comma
- supporting comments
There could also be support for HJSON which has similar goals and features as JSON5