Use JSON5 for package.json

[wesbos]

This was closed 5 years ago, but I wanted to see if there was any renewed interest in this.

Using JSON5 to parse the package.json would alleviate many common tripping points with json

• Ability to add trailing commas after the last item in an object
• Ability to add comments to the JSON file (We currently can with keys of "//")
• Single quoted strings

VS Code has moved to JSON5 for their config files and I love it.

I know other tools parse package.json, so they would need to be updated as well? Would that be too disruptive?

Backwards compat would also be something to think about as well..

[reconbot]

Dangerous but wonderful!

[ljharb]

It would be exceedingly disruptive. There's no builtin JSON5 parser in node, and tons of tools already parse - and expect to parse - regular JSON.

I can't see how it could possibly be worth the ecosystem churn.

[ljharb]

@DanKaplanSES that wouldn't work unless npm also ensured that any changes made to package.json were brought back to the json5 file, without disrupting comments or overall file style.

[DanKaplanSES]

@ljharb I am sorry. I don't understand why it's required to go from package.json to package.json5. What am I missing?

[ljharb]

@DanKaplanSES i'm saying that "automatically transpiling json5 → json" would only support the "read" use case. Many other tools write to package.json, so you'd also need "automatically transpile json → json5" - but because the json will be a subset of the json5, and because file watching is complex, that's not trivial to do.

[Eccenux]

The tools can adapt. And if they don't and if one cares then one can still use package.json. I see no reason not to add json5 support for those that wish to use it. Most of the time you only need npm i to work. Everything published would have a transpiled package.json so that is not a problem for the system as whole at all.

[ljharb]

@Eccenux of course they can, but that doesn't mean they will - and, forcing that kind of disruption only hurts users.

[borekb]

I agree that it's not feasible to change this, as per the accepted answer, but my no. 1 wish are comments for scripts. I know there are solutions like nps but we don't usually bother setting this up (as don't most public packages as far as I've noticed).

[wesbos]

You can sorta do it with the "//" key:

"//": "This script starts the build command",
"build": "node build.js" 

[wesbos]

npm has said they will never use the // key as well, so it's safe to use it

[borekb]

And you need to number them or otherwise distinguish if you have more comments to add.

We usually end up with a separate .js or .sh files if the scripts get "complicated" but "complicated" often means like 2-3 lines of code still, so it feels like a waste 😄. Plus, binaries are (much) more painful to call from external scripts – no automatic resolution from node_modules/.bin.

Simply a small but unpleasant dilemma we have all the time 😄.

[ljharb]

@borekb if the external script is invoked from an npm run-script then the PATH will already be set up for you.

[annanyearian]

Can't use the // form in a dependencies section, npm still tries to install the // package. The duplicate key hack is probably better because of this. Unfortunate that both of these hacks still break syntax highlighting.

[TheJaredWilcurt]

I have created an issue with a proposal that solves all mentioned issues here, would be backwards compatible, requires no changes to Node, a low effort implementation, and has no negative side effects. It is completely opt-in.

• [RRFC] Opt-in solution to support comments in package.json (among other features) rfcs#291

[jimmywarting]

unless the official json specification don't change then I do not think we should ship json5 or any other json variant JSON should be a interchangeable format that every programming language (JSON.parse included) can reliable use to parse any JSON structure.

[TheJaredWilcurt]

This is easily solved by having a package.json file be auto-generated from the package.json5 file during specific npm commands. Such as npm install, npm publish, etc. Basically any existing command that already modifies the file would be updated to check if there is a package.json5 file first, process it to the package.json file and then work as normal. This is completely backwards compatible and opt-in. Please read the above RRFC before adding comments that have already been addressed there.

[bennettellis]

alternatively maybe just update all npm commands to take optional --json5 argument, and use that to determine behavior from there generating and using a package.json5 file instead of a package.json file.

[aharbavets]

This is a really big drawback. Package.json - is actually a config file. And all config files in various computer systems had comments for decades. And now in 21-th century we use the format which doesn't support comments. Additionally it could promote more modern JSON version like JSON5. And as @TheJaredWilcurt told it could be an opt-in

[baboon-king]

This is really big drawback. Package.json - is actually a config file. And all config files in various computer systems had comments for decades. And now in 21-th century we use format which doesn't support comments. Additionally it could promote more modern JSON version like JSON5. And as @TheJaredWilcurt told it could be an opt-in

"package.js/ts" is much better than package.json
When a static configuration is needed (e.g. pushing a library), package.js can be executed to get a JSON formatted configuration object

[baboon-king]

And we can provide sufficient type hints through helper functions (perhaps from node built-in modules), but for now package.json relies on ide (I'm not entirely sure)

[judfs]

Configuration IS code. And we've known that code should have comments basically forever. Not supporting comments is actively failing the world. Npm not fixing this is irresponsible.

I weep thinking about the amount of hours globally that have been lost over issues that only occurred because comments could not be provided. [While melodramatic, you know I'm not wrong.]

[Eccenux]

Eslint does support using various formats. You just change the extension mostly. And new version will use JS (not JSON) by default.
https://eslint.org/docs/latest/use/configure/configuration-files

Seems like something that could happen in a few years in npm/node. I mean: support json5 and js first, transpile to json when publishing packages, check what works best, choose most popular format as new default (keep json as a fallback)

[Eccenux]

Here is how this can be done (first steps):

1. Add JSON5 support in Node/npm. See: Support for JSON5 nodejs/node#40714
2. Implement a transpilation option in npm to convert JSON5 and JS to plain JSON (code provided below).
3. Automatically transpile package.json5/.js during npm publish (and possibly during npm install or npm update).
4. Prioritize reading from package.json5/.js before package.json in npm i and such. This may require disabling the automatic sorting performed by npm install (as it would ruin comments).

That's essentially it. The next step is to wait for tooling to catch up. Visual Studio Code already supports jsonc (JSON with Comments), providing some level of support for JSON5. So already got zero-day support :).

Then, after some time:

1. Allow time for other tools to adapt.
2. After a period of 2-5 years, evaluate which extensions have gained popularity.
3. Consider adopting a new default format for npm init, retaining JSON as a fallback option.

Transpilation:
That is literary the whole code required for transpilation (assuming json5 would be built in):

import * as fs from 'fs';
import JSON5 from 'json5';

try {
  const data = fs.readFileSync('./package.json5', 'utf8');
  const jsonData = JSON5.parse(data);
  const jsonString = JSON.stringify(jsonData, null, '\t');
  fs.writeFileSync('package.json', jsonString, 'utf8');
  //console.log('Transpiled json.');
} catch (error) {
  console.error('TranspilationError:', error);
}

At the moment code above works with npm i json5 -D.

Appendix: Code from the 20th Century

Don't get me wrong. Visual Studio 6 was terrible, and sometimes it's easier to edit this old code with Notepad++. But VS6 did support comments in most configuration files (including dsw, dsp, rc). You wouldn't normally edit them manually, but you could. It's not much different than package.* files (which you generate with npm init and update with npm install most of the time).

Why am I mentioning this? Computers were slow back then, yet this approach worked quite well. You could manually edit RC files, comment out stuff, and then edit the RC files in the IDE, and your comments would be preserved. This worked seamlessly. Back in 1998.

[cwtuan]

JSON5 is the next trend of data format.

[dutscher]

the argument that every progamming language has comment indicator/function in his file extension, is it.
we need json5 in our daily business package.json.

this thread is gettin hot in the last days, i think this answers wes bos initial question.

cheers

[MylesBorins]

Hey all. I'm locking this conversation because it's derailing.

The npm team's stance is fairly clear. We will not be supporting JSON5 as an npm feature. If the JavaScript language or the Node.js platform support JSON5 we can revisit this discussion