Support package.json5


(Marc André Lafortune) #1

It would be awesome to support package.json5.

The file 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.json5 to package.json. Thus, anyone downloading any npm library would still get a package.json as before (and no package.json5 file).

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

I would be glad to provide a PR for this if the general idea is accepted.

Note: Babel already supports JSON5 for its .babelrc file.


(Marc André Lafortune) #2

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.


(Lars Willighagen) #3

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.json or package.json5 in that case.


(Marc André Lafortune) #4

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.json or 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 :-)


(Daniel Stockman) #5

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?


(Marc André Lafortune) #6

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.