Support comments in package.json

[Timmmm]

Sorry if there's an existing issue for this but I only found #793 which is closed. I believe this is the status quo:

1. Users really want this. Look at this StackOverflow question - over 600 upvotes!
2. None of the current workarounds are very good.
3. It would be a (minor) breaking change.

The current workarounds are:

1. You can officially add a single top-level key "//". This sucks because I want more than one comment!
2. Various hacks to put comments inside script commands. This sucks because it only works for scripts, and it's also terrible.
3. Use duplicate keys. This sucks because JSON's duplicate key handling is not well defined, and NPM will delete the duplicate keys if it modifies package.json.
4. Generate package.json from another file. This is probably the best solution right now but it means you can't npm install -D stuff and it's an extra step.

These all really suck. This is an age-old feature request wanted by many many people.

As far as I understand it the reason NPM "can't" be changed to just support package.json5 or package.jsonc is that third party tools would get confused when they try to read package.json and it's not there. I can think of two solutions:

1. When you run npm, as well as generating package-lock.json it also generates package.json (and this should be .gitignored if you also have package.json{5,c}). Are there any third party tools that want to modify package.json?
2. Just ask those third party tools to support package.json{5,c} too. This is clearly a smaller problem than not allowing comments in NPM's most important config file forever.

[ljharb]

It's not just third-party tools, it's javascript itself. Before any format should be supported by anyone, parsing and serializing it should be built in to node, and broadly available (meaning, shipped for years first)

[Timmmm]

Why? What third party tools would actually need to write to package.json{c,5)?

[ljharb]

Tons of tools write to package.json, including all of the package managers.

[Timmmm]

Ok but this would be entirely optional; you can still use package.json if you need to work with those third party tools. Or they can be updated!

[Simbiat]

Hm, why not support JSON5 or JSONC and have logic which will check for JSON5/JSONC file first and then for JSON one, if it does not exist? That way you won't even need to break anything. In fact, you can even generate JSON file from JSON5 similar to what Caddy web server can do when you pass it certain types of configs.

[ljharb]

@Timmmm if it is possible for users to do then it is mandatory for tools to support it.

@Simbiat for the same reason - there's no such thing as a built-in way to work with those formats in any platform.

[Timmmm]

if it is possible for users to do then it is mandatory for tools to support it.

I don't see why. It would be nice, but certainly not mandatory.

there's no such thing as a built-in way to work with those formats in any platform.

Why is "built-in" a requirement? There's no built-in way to read JSON in many platforms.

[ljharb]

Let me rephrase - if the tool wants to be relevant, it must support it.

The only platforms that matter for npm are browsers and node, which have provided a built-in way to read and write JSON for well over two decades.

[MRagunandhan24]

@Timmmm Thanks for taking the time to share your idea! New ideas are always appreciated and are better suited for our RFC repo instead since that's the right place in order to get more attention from the rest of the team and the community.

Can you create an RRFC in that repo?

[Timmmm]

Sure I started writing one but then I had a search and found a 5-year old one that is almost exactly what I would have written: npm/rfcs#291

Basically support package.json5 and automatically convert it to package.json when you run npm commands (I think that could also be optional and controlled by a key in package.json5).

It has overwhelming support. What would be the next step? Write an actual RFC?

[MRagunandhan24]

@Timmmm Thanks Tim for creating the RFC. I'm closing this as this is transferred to RFC.