Support for JSON5

[EvHaus]

Is your feature request related to a problem? Please describe.

The lack of comments in package.json is clearly a big problem that the community faces (examples 1, 2, 3, 4). Currently the community is forced to use all sorts of ugly and hacky workarounds (examples 1, 2, 3, 4). Discussions to add it to npm have failed.

Describe the solution you'd like

Adding native support for JSON5 in Node would help address this pain point and move the entire ecosystem forward.

Describe alternatives you've considered

Other alternatives would be exploring non-JSON formats like TOML, but that seems like it would be a bigger project. JSON5 is backwards compatible so it should be a simpler integration.

[targos]

What do you mean exactly with "Adding native support for JSON5 in Node" ? That Node.js provides a function to parse JSON5 strings?

[EvHaus]

What do you mean exactly with "Adding native support for JSON5 in Node" ? That Node.js provides a function to parse JSON5 strings?

The specific problem I want to solve is the ability to use JSON5 for the package.json file.

I suspect (although not confident of) that to do this right, it means adding first-level support for JSON5 for anything you can do with JSON files and strings in Node. In which case you would be able to:

• Use JSON5 for package.json configuration
• Use JSON5 for ES imports (ie. import foo from 'bar.json' where bar.json is a JSON5 file)
• Use JSON5 for CJS requiers (ie. const foo = require('bar.json') where bar.json is a JSON5 file)
• Use JSON5 in parsed strings (ie. JSON.parse(someJson5String))

[ljharb]

Presumably to parse, and to stringify, just like JSON.

Stringification is a bit trickier tho because of things like comments, optional quotes and trailing commas, etc - there'd need to be a pretty complex API to support all that.

[wesbos]

Yeah I think if this is ever going to make any headway, it needs to start as a language spec for JSON.

[ljharb]

I think that to achieve the package.json5 goal, this is the order of operations:

1. Define a “standard” parse/stringify api, and spec (these may already exist but need to be collected in one place). This standard need not be in the language, but probably should be.
2. add support for it to node, and also to browsers so that there’s broad JS ecosystem adoption and not just node
3. Wait a likely long amount of time for ecosystem adoption
4. assuming very widespread user outcry for it, add package.json5 support to npm, and define the complex interactions around both a json and json5 package file being present
5. add support for node to read “exports” and “main” and “type” from package.json5, and define the complex interactions around both package files being present and their meta info being different

[tniessen]

The great thing about JSON is that it simply works everywhere, and most of the time, no extra libraries or tools are needed. For example, parsing a package.json file is a single dependency-less line of code in all JavaScript environments, whether it's a browser, Node.js, or Deno, and in most other popular languages (including Python, PHP, Android Java, C#, ...).

I agree that JSON5 looks like a nice format, but also that serialization won't be simple. For example, tools such as npm that modify JSON files need to preserve comments etc.

[TheJaredWilcurt]

Hi, I created the RRFC for npm to allow for a more permissive manifest format.

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

The key points of it is:

• Specific npm commands (like npm install or npm publish) would apply new changes to the new format and would process the new format back to a traditional package.json.
• This allows the new manifest format to be opt-in on a per-project basis.
• It also makes this completely backwards compatible, as all prior versions of Node/npm would still have a package.json to refer to.
• More details and caveats are specifically documented there.

I do not see a new manifest format as requiring any changes on Node's part, this can just be an additional dependency shipped with npm to handle this feature. It seems like the most economical and simplest solution that would be easiest for everyone to agree upon. However, there is some pushback from npm, preferring Node support this feature directly. So if that is the easiest path forward to achieve this goal, I won't argue.

[ljharb]

@TheJaredWilcurt npm never exists in a vacuum; tons of tooling and libraries need to read from, and write to, the source of truth (package.json5 in this case), and npm supporting a new manifest format will be a pretty high burden on that tooling ecosystem - node natively supporting it would make that slightly easier.

[fregante]

It's more likely that an additional file is added for scripts and other config, like config.json5

I'd campaign for that instead of this as I very much doubt package.json5 will ever happen.

[TheJaredWilcurt]

npm supporting a new manifest format will be a pretty high burden on that tooling ecosystem - @ljharb

Indeed, it would break a lot of code out there if require('./package.json') stops working.... - @Trott

Again, in my proposal, it is 100% BACKWARDS COMPATIBLE. Anything doing require('./package.json') would not break. The package.json5 or package.hjson or whatever, would always be a meta-language file used to produce the official package.json file. So no tooling would need to change, unless it modifies your manifest directly. In which case, it would need to check for the package.json5 first, and then if it exists, modify it instead. This is all documented in the link that I posted.

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

All you need to do is import an extra library and add 1 additional if statement at the top and bottom of your code (for reading and writing). It is not a high burden, it is a very small, and optional, change. If libraries do not wish to support the new system, they don't have to. Not everyone will adopt the new manifest format, and those that do will either update the tools they use via PR's, or switch to alternative tooling that works for their new workflow.

It's more likely that an additional file is added for scripts and other config, like config.json5. I'd campaign for that instead of this as I very much doubt package.json5 will ever happen. - @fregante

That's what we are asking for. The package.json remains. And a new file is created to solve all of the identified problems with the current system. For simplicity, instead of naming it config.json5 or something else that could conflict, it is called package.json5 (or whatever format). Ultimately, we need to keep scripts, dependencies, and devDependencies in the package.json and we need to be able to sort, organize, and document them as well. That's what this proposal solves by allowing that sorting/documentation to be handled in a meta file.

[fregante]

It's more likely that an additional file is added for scripts and other config, like config.json5. I'd campaign for that instead of this as I very much doubt package.json5 will ever happen. - @fregante

That's what we are asking for.

No it’s not. You’re asking for people to check 2 identical files into git, connected by a “build” command (npm install). That’s even worse than just switching format. Again, the chances of this happening are nil IMHO.

What I suggest is literally just an additional file, not a “copy with comments” file.

Your RFC even mentions a “transition period” as if package.json would ever stop being supported or generated.

[ljharb]

@TheJaredWilcurt most tools don’t just read package.json, they write to it also - the ones that just read are a minority. As a maintainer of some of these tools, i can assure you this is a large burden, especially since these tools are often transitively depended on, many layers deep.

@fregante making a separate files just for dev-time scripts seems much more feasible, and would require only ~2-3 of the steps mentioned in #40714 (comment), including that only npm, not node, would need (ever) to look at this new file, so it seems like a much more feasible option.

[pinuke]

@ljharb

most tools don't just read package.json, they write to it also...

Most tools (that are used seriously) feature any of these 4 things, if not all of them:

• QA testing - if it's a serious tool, they would detect this immediately upon change using QA procedures
• Open source - if they don't support it, help them fix it and open a pull request
• Ticketing/Issue tracking - if they don't detect this with proper QA, the userbase will and they will submit a trouble ticket
• Code maintainers - a group of people who should be actively looking for breaking-changes before bugs appear

FUD can be managed

[Trott]

Thank you for the feature request, @EvHaus. In my view, adding JSON5 support for package.json in Node.js isn't going to happen any time in the foreseeable future, and probably never. I'm going to close this as leaving it open provides the misleading perception that it is being seriously considered.

@nodejs/tsc If anyone disagrees and thinks the original feature request here is likely to come to pass, please feel free to say so and/or re-open.

[bmulholland]

How are we supposed to document what packages are for, why a version is pinned, and so on? Doing so is a regular part of the maintenance of our rails backend, with comments explaining why we've pinned a version and linking a ticket to fix that problem. For example, sometimes this is an issue we've filed in the package's repo, and so anyone on the team can periodically check that link to see if the version pin can be updated or removed.

Using "//" to comment doesn't work: it's a single line, with not enough space to put everything, and neither npm or dependabot support it.

I'm disappointed that this aspect of "comments in package.json" has been completely trumped by backward compatibility, with seemingly no consideration to the problems of actually maintaining a real-life application that makes active use of package.json and version pinning, where it's important that knowledge is persisted in situ. Workarounds like putting package notes in the README or elsewhere make maintaining knowledge connected to packages and versions are far more likely to not be updated. It's also near-impossible to enforce, and so simply doesn't scale.

I don't understand why the package.json5 proposal wasn't even considered? Yes, it's an additional file, and it's not pretty, but it would unblock us from actually being able to connect knowledge with code. Commenting your code is something that is widely considered to be best practice in the industry -- why does that best practice stop when documenting dependencies?

Heck, with all the attention that supply chain management is getting these days, one would think that documenting dependencies would be even more important. Instead, npm is ignoring this because node is ignoring it. And dependabot isn't even supporting yarn's solution because npm doesn't support it.

Maybe I'll just make a package that does the package.json5 hack myself, but for a mature ecosystem I'd honestly expect table stakes like this to be sorted out.

[bmulholland]

Checking all the package managers that dependabot support, here's a list of package managers that do support comments in their dependency declarations: bundler, cargo, docker, hex, go, gradle, maven, nuget, pip, terraform, pub

Ones that don't: composer, elm...

and npm (because node doesn't) & yarn (because node doesn't).

[aduh95]

because node is ignoring it

I'd like to remind everyone that Node.js is a community-driven project, it's not a corporation or a self-aware entity that takes arbitrary decisions. It's also up to you to take ownership of this problem and find a solution. See #41927 (comment) for a roadmap if you feel like that's something you want to take up.

Maybe I'll just make a package that does the package.json5 hack myself

That's probably the most reasonable move atm, and hopefully if package.toml or package.json5 hack starts to gain in popularity, maybe other tools in the ecosystem (like npm) would adopt it.

[bmulholland]

I see your point, and I don't want to disagree or argue, I just want to clarify that my saying "node is ignoring it" was in reference to @Trott's final comment and closing of the issue.

[ljharb]

Using a package.json5 for an app - something not published or consumed by anyone else - is fine, and the downsides of that are minimal. Uncountable problems would stem from using it in a published package.

Due to node and npm not separating those use cases into different files, anything supported with package.json for one, affects the other. I think that’s one of the bigger constraints, personally (to not affect the package ecosystem).

[targos]

npm pack could convert the file to a valid package.json.

[bmulholland]

Here's my MVP (obviously for yarn, please post if you adapt for npm):

1. yarn add json5
2. Add:

  "scripts": {
    "compile-package-json": "json5 -o package.json --space 2 package.json5",
    "prepack": "yarn compile-package-json"
  }

3. cp package.json package.json5
4. Make all changes to package.json5 from here on out.

One issue is it needs to be bootstrapped, hence the dedicated compile-package-json. It also needs testing; I have a feeling that yarn doesn't run this lifecycle hook as often as I'd like. Once it's more tested, I'll see if I can publish a package.

[ljharb]

@targos that would only be viable if npm (like package-lock.json) never published package.json5, so that it was impossible for it to be in, or extracted from, the tarball.

[Trott]

I see your point, and I don't want to disagree or argue, I just want to clarify that my saying "node is ignoring it" was in reference to @Trott's final comment and closing of the issue.

As I wrote in that comment:

If anyone disagrees and thinks the original feature request here is likely to come to pass, please feel free to say so and/or re-open.

That comment was directed at the TSC to discourage drive-by requests to re-open, but let me scope it more properly: I don't mind this being re-opened if someone is (publicly, transparently) actually working on it or investigating it seriously.

I understand the frustration. It's wrong, though, to conclude that Node.js maintainers don't appreciate the seriousness of the problem. (OMG, I would love to be able to put comments in package.json.) It's wrong to conclude that the Node.js maintainers are a bunch of people who are completely insensitive to the needs of the user base yet somehow ended up maintaining a software package with an inconceivably large user base. To me, at least, Occam's Razor suggests that because the maintainers have experience supporting the inconceivably large Node.js community, they have awareness of obstacles that end users don't (or perhaps can't?) fully appreciate, even when those end users are really smart and accomplished people.

[bmulholland]

I agree that I am probably the least informed person in this thread about all of the Node.js codebase, either package manager, and the impacts choices here make. I'm sorry that my comments came across as disrespectful to the maintainers. Not at all how I want to be communicating; I appreciate your understanding of my frustration and the ensuing poor wording choices.

I also appreciate your clarity that you (and presumably other maintainers) want this feature, too. I really did have the opposite impression from previous discussions on the topic. That may well by my own fault in interpreting what I read :).

From what I hear, achieving this isn't totally impossible, it's just threading a needle of broad tool support and other impact. In particular (forgive the terminology, it's probably not quite right):

1. Having a single, widely/easily parseable package file format keeps things simple. Requiring tools to support two+ package.* formats is basically a non-starter.
2. Few languages ship with a native JSON5 parser (and many/most stdlibs do have a JSON parser already). And:
3. Making any change to package.json and managing its impact on the full Node.js ecosystem is a painful, years-long process. No one, understandably, wants to manage that.
4. A system that compiles another format to package.json is unpopular because it introduces a third package file that would have to be checked in to source control, and that would be even more confusing to e.g. new programmers.
5. While Yarn and NPM could support something directly, they choose not to because Node.js doesn't support it.
6. Implementing the pre-compile package I suggested is difficult because Yarn does not have a consistent preinstall hook. NPM does have one that could work, though I haven't tested it.

Please let me know if there's anything I've missed.

While there's some very tricky parts here, I wonder if there's some basic solution that can meet these constraints. Ideally, this would be an ecosystem-wide approach. IMHO, if node maintainers could agree on and indicate a workable direction, that may give yarn and npm the "permission" they need to make something. (Maybe that's an uninformed outsider's perspective.) It thus would need to be very simple, and achieve some level of general consensus or at least consent. From what I understand supporting this for applications ("end users" of node) is likely highest impact, lowest risk.

With all that said, one idea off the top of my head: Indicate that Node endorses the approach of using a third package file (maybe just one, maybe any of a set such as json5, toml). Scope that only to end applications (i.e. not supported for published packages), and constrain it to dev machines only (so no tooling needs to be updated). Get some level of agreement from yarn and npm (I'm happy to help, though I imagine the maintainers of these projects have direct relationships and don't need me.) Perhaps all that's needed from yarn and npm is a single, consistent lifecycle hook that an outside package can use to run a compile step -- this makes it an optional, power user feature that can be used to measure interest and adoption.

(Fundamentally, I suppose this would also be a bet that e.g. JSON5 gets broader stdlib support. YAML could be an option that has nearly the same level of language support already. Though Node supporting JSON5 could certainly help solve the chicken-and-egg problem of "why bundle JSON5, no one uses it".)

I imagine there could also be valid concern about "what happens next." This post is already long enough, but I think if the initial approach is chosen with enough constraints, there would be a roll-out option that is simply removing constraints on a published timeline. This would require some project management, but not as much community management. Or maybe this won't even be needed...

Feel free to tell me why this wouldn't work, ideally paired with a "and here's what could" :).

[mcollina]

I think it's not possible for Node to support two formats as it will break the ecosystem.

Your best option is to ask npm and yarn to give you enough hooks to implement a transpilation step.

[bmulholland]

Hey, look, this is really frustrating and discouraging.

I have made statements about how the Node maintainers are blocking anything to do with this, and I've rightfully gotten pushback that that is not the case. But then, based on the openness that suggests, I take the time to make a constructive proposal on how to move forward -- incorporating all issues raised to date -- and your response is saying outright no.

What's especially frustrating is that it is a different person saying no, in a different way, with each response I've received. When that happens, I lose all motivation to try to help out. Is that the sort of impression you want to give potential contributors to Node.js?

To directly address your comments, I have already linked to examples where Yarn and NPM have explicitly said no to something like this because Node does not support it. That's why my suggestion was for a form of publish endorsement, without any code changes or ecosystem impact to Node.js itself.

Anyway, I would appreciate if you Node.js Members could talk between yourself and decide whether you're open to the idea or closed to it, because this inconsistency is driving me crazy.

[aduh95]

5. While Yarn and NPM could support something directly, they choose not to because Node.js doesn't support it.

I don't really understand this point, package.json usage in Node.js is quite limited outside the node_modules/ folder: it's only used when you require('./path/to/a/folder/') to resolve the "main" field, for self-resolving the package you're in, and to resolve package imports.
If adding support for other formats means the runtime need to look up for more files, that's probably a non-starter as the runtime performance could suffer quite a lot. A better solution would be to transpile to JSON before running node (or not use any of the above features) and before publishing to npm.

I don't think you need blessing from this project to be honest, if you make a Yarn plugin that converts your package.json5 or package.toml to a git-ignored package.json on the fly, you should be good to go. (Dependabot is using lock files to check for files to update I think, right?)

Anyway, I would appreciate if you Node.js Members could talk between yourself and decide whether you're open to the idea or closed to it, because this inconsistency is driving me crazy.

Well that's what we are doing in this thread, where else would you want us to talk about it? x)

[bmulholland]

When I said "While Yarn and NPM could support something directly, they choose not to because Node.js doesn't support it." I was referring to these responses:
npm/feedback#56
yarnpkg/berry#241

[devsnek]

I was referring to these responses:

fwiw the people who answered those questions are also node maintainers. i think they were saying less that node as some entity unto itself refuses and more that they can not see a path forward to the node ecosystem migrating beyond normal json.

Anyway, I would appreciate if you Node.js Members could talk between yourself and decide whether you're open to the idea or closed to it, because this inconsistency is driving me crazy.

I'm sorry for the confusion. We generally don't make decisions like this until concrete implementation is brought to discussion, which is why you're getting what sounds like conflicting answers. In terms of our official process, this would not actually be blocked until someone opened a PR and collaborators stated active objections to it (and even then, only that specific PR would be blocked). The openness of the issue is generally an indicator of whether someone would be tracking/implementing such a feature, or whether we think it is likely for that to happen in the "near" future.

[Trott]

From what I hear, achieving this isn't totally impossible, it's just threading a needle of broad tool support and other impact.

I guess it depends what you mean by "this" and "it". You wrote:

Requiring tools to support two+ package.* formats is basically a non-starter.

To me, that says that any version of this that makes a JSON5 version of package.json a first-class citizen is a non-starter (impossible). But I'm not sure we're understanding things exactly the same way here.

Making any change to package.json and managing its impact on the full Node.js ecosystem is a painful, years-long process.

Yes, and making a change that causes some users to have a package.json that can't even be used or parsed by the previous version of Node.js, npm, yarn, and pnpm is worse than that. It's a never-ending boiling-the-ocean task. I won't say a breaking change like that is impossible, but the bar is fantastically high. I don't think I've ever seen anything that rises to that level in my 7 years of involvement in Node.js, and I don't think I ever will. Not impossible, but extremely unlikely.

While Yarn and NPM could support something directly, they choose not to because Node.js doesn't support it.

I think this hints at a key obstacle. To introduce a new and backwards-incompatible format, you'd need to basically get four projects on board to do it together: Node.js, npm, yarn, and pnpm. Getting Node.js to do ANYTHING in a "hot stove" area like package.json format is a big lift. Adding on the others makes it a colossal lift. Again, I won't say it's impossible, but it needs to be something extremely compelling. If npm, yarn, and pnpm all came to Node.js with "We want this to happen", that might move the needle. (And... it also might not.) I know it's frustrating because you feel like they've basically said "We need Node.js to say this is going to happen". I don't know what the answer is other than spending a lot of time to talking to a lot of people and making the case (and that has a high probability of failing anyway, but you never know until you try).

Node endorses the approach of using a third package file

I don't understand this. What does Node endorsing an approach involve? Just a statement? Or...?

I have made statements about how the Node maintainers are blocking anything to do with this, and I've rightfully gotten pushback that that is not the case. But then, based on the openness that suggests, I take the time to make a constructive proposal on how to move forward -- incorporating all issues raised to date -- and your response is saying outright no.

Node.js is not a monolith and no one individual speaks for the project. Matteo is certainly at or near the top of any list of our most influential maintainers, but there are over 20 people on the Node.js Technical Steering Committee and nearly 100 people who meet the conventional definition of maintainer (meaning they have the ability to commit to the repository and can approve or reject pull requests).

This organizational approach has lots of advantages, but also considerable disadvantages. One is that people can feel like they are getting a lot of mixed messages from "the project". So try to bear in mind that no one is speaking on behalf of Node.js, only themselves.

In the uncommon cases where conversation runs its course but agreement has still not been reached, things get escalated to the Technical Steering Committee.

[MylesBorins]

@bmulholland if it is any consolation pnpm actually supports both json5 + yaml out of the box. great work @zkochan!

This could practically unlock the flows you want today. I could not find a ton of documentation but I did find doing a simple mv package.json package.json5 seemed to "just work" in pnpm, which was a pretty great experience. The majority of commands worked as expected and I was even able to publish the package and pnpm did the smart thing converting package.json5 -> package.json.

The major road block I hit was that when running the application node.js had no local package.json to reference so I lost the ability to use package.exports + package.imports in my own project. This could likely be dealt with by transpiling the json5 -> json when running pnpm start (or maybe a feature pnpm could implement.

This shows that this is indeed a feature that various CLIs could implement without requiring the support from node, but it is kinda edge case'y and I'd argue probably not the best solution for the average person today.

Play around with it a bit and if you still want to propose json5 or yaml or whatever configuration language you can make an earnest proposal at https://github.com/npm/rfcs. The bar will be much higher to ship in npm, which is a reason why clients like pnpm tend to really shine for these use cases.

[zkochan]

There was some backlash when I added this feature to pnpm. I was accused of introducing division in the ecosystem and incompatibilities with Node.js, npm, and other tools. So, I decided not to talk about this feature. I keep it because a few times, users have asked for it. But I don't think this feature is mentioned anywhere in the docs.

[TheJaredWilcurt]

@zkochan I'd appreciate if you could take some time to review the proposal I've written up here:

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

For adopting an optional package.json5 file that is auto-processed to package.json any time npm install, npm run, and similar scripts are ran. It would be helpful to have input from someone that has already attempted an implementation to point out any potential issues that have not already been addressed in that proposal.

[jasonkhanlar]

I referenced this here (re PHP): https://phabricator.wikimedia.org/T302694#7919654

but also (re Node.js): there are various JS libraries that strip comments from JSON https://npmjs.com/search?q=json%20comment in addition to PHP library I found https://packagist.org/packages/adhocore/json-comment

Perhaps these single-line multi-line comment stripping functionalities can be standardized more formally/officially across all modern scripting languages.

"If anyone disagrees and thinks the original feature request here is likely to come to pass, please feel free to say so and/or re-open."

I disagree and I think the original feature here is likely to come to pass, and should be considered, but I will not dare re-open this! I'll just simulate the idea of reopening it per leaving this comment feedback. Besides, in my opinion, from a technical standpoint, parsing/stripping out all comments in a standardized fashion that works across all languages abilities to parse in standardized fashion, I am pretty sure this is easy to accomplish, and at some point it will be implementable.

"I'm sorry for the confusion. We generally don't make decisions like this until concrete implementation is brought to discussion,"

Oh, uhm, I did not exhaustively research, investigate or analyze for widespread implementations of single-line, multi-line comment removal in JSON, however, for my own dev projects, I encountered libraries that provide this capability and I referenced them above, and I believe others may be able to find all sorts of similar libraries across all sorts of scripting/coding/programming languages that accomplish similar results. Perhaps I should explore and find all sorts of examples across all sorts of languages that accomplish similar capabilities and try to connect them altogether to try to encourage some kind of standardization adoption.

• C
  • @jc21 https://github.com/jc21/json-strip-comments
• C# https://github.com/search?l=C%23&q=json+strip+comment&type=Repositories
• C++ https://github.com/search?l=C%2B%2B&q=json+strip+comment&type=Repositories
  • @google https://github.com/google/jsonnet
• CoffeeScript https://github.com/search?l=CoffeeScript&q=json+strip+comment&type=Repositories
• Erlang
  • @talentdeficit https://github.com/talentdeficit/jsx
• Go https://github.com/search?l=Go&q=json+strip+comment&type=Repositories
  • @google https://github.com/google/go-jsonnet
• JS
  • @kaelzhang https://npmjs.com/package/comment-json
  • @vitaly-t https://npmjs.com/package/decomment
  • @vitaly-t https://npmjs.com/package/grunt-decomment
  • @vitaly-t https://npmjs.com/package/gulp-decomment
  • @sindresorhus https://npmjs.com/package/gulp-strip-json-comments
  • @noahsug https://npmjs.com/package/json5-writer
  • @onury https://npmjs.com/package/jsonc
  • @microsoft https://npmjs.com/package/jsonc-parser
  • @codenothing https://npmjs.com/package/json-lint
  • @fkei https://npmjs.com/package/jsonminify
  • @serkanyersen https://npmjs.com/package/jsonplus
  • @Flamenco https://npmjs.com/package/really-relaxed-json
  • @phadej https://npmjs.com/package/relaxed-json
  • @krakenjs https://npmjs.com/package/shush
  • @sindresorhus https://npmjs.com/package/strip-json-comments
• Lex https://github.com/search?l=Lex&q=json+strip+comment&type=Repositories
• Perl
  • @plainblack https://metacpan.org/pod/Config::JSON
  • @makamaka https://metacpan.org/pod/JSON
  • https://metacpan.org/pod/JSON::DWIW
  • https://metacpan.org/pod/JSON::Relaxed
  • @ingydotnet https://metacpan.org/dist/JSONY/view/lib/JSONY.pod
• PHP
  • @adhocore https://packagist.org/packages/adhocore/json-comment
  • @hjson https://packagist.org/packages/laktak/hjson
• Python
  • https://github.com/search?l=Python&q=json+strip+comment&type=Repositories
  • @vaidik https://pypi.org/project/commentjson/
  • @leontrolski https://pypi.org/project/dnjs/
  • @nazrulworld https://pypi.org/project/fhir.resources/
  • @ICRAR https://pypi.org/project/ijson/
  • @vinitkumar https://pypi.org/project/json2xml/
  • @dpranke https://pypi.org/project/json5/
  • @NickolaiBeloguzov https://pypi.org/project/jsonc-parser/
  • @pasztorpisti https://pypi.org/project/json-cfg/
  • https://pypi.org/project/jsoncomment/
  • @getify https://pypi.org/project/JSON_minify/
  • @mverleg https://pypi.org/project/json-tricks/
• Ruby
  • @geoffyoungs https://rubygems.org/gems/json-minify
  • @LumberJ https://rubygems.org/gems/json_minify
  • @json-next https://rubygems.org/gems/json-next
• Rust https://github.com/search?l=Rust&q=json+strip+comment&type=Repositories
  • @Canop https://crates.io/crates/deser-hjson
  • @tmccombs https://crates.io/crates/json_comments
  • @google https://crates.io/crates/json5format
  • @dprint https://crates.io/crates/jsonc-parser
  • https://crates.io/crates/jsonc_tools
  • @hjson https://crates.io/crates/serde-hjson
  • @thomcc https://crates.io/crates/smoljson

Not quite comment stripping, but notable JSON parsing mentions:

• Brainfuck: https://codereview.stackexchange.com/questions/194538/json-formatter-in-your-least-favorite-language
• Erlang: https://github.com/mochi/mochiweb/blob/main/src/mochijson.erl
• Haskell: https://abhinavsarkar.net/posts/json-parsing-from-scratch-in-haskell/
• Lua: https://github.com/rxi/json.lua
• Lua: https://github.com/ReallySnazzy/single-file-lua-json-parser

Ok there! I still did not exhaustively research, but I found a bunch of implementations, but they are probably not concrete. Anyone got some cement to spare?

Oh also,

"the existence of userland packages doesn't matter; unless browsers or the language adds a parser/serializer, node's unlikely to, and until all three have it, npm is unlikely to support it, and that's a blocker for node supporting it" -@ljharb

and I agree! Developer Tools console in modern web browsers should also have something like JSONC.parse/JSONC.stringify or JSON5.parse/JSON5.stringify also!

@brave
@chromium
@GoogleChrome
@mozilla

@Fyrd - re https://caniuse.com/

Also see https://json.org/json-en.html

[pubmikeb]

JSON is a great (de-)serialization format for apps' configs and data.
However, it doesn't support comments. Luckly, there are two formats, which support comments in JSON: .jsonc and .json5.

As a modern application environment, it would be great to be able to use .jsonc and .json5 instead of classical .json in projects.

[TheDirigible]

Node needs a simple global switch to have it read all .json files as .json5. Strict json is a plague on humanity, especially those trailing commas.

[sdudnic]

please guide me is there a way to create under nodejs app a server able to parse json5 POST bodies, like

const app = express();

// Use express-json5 to parse JSON5 request bodies
app.use(expressJson5());

because i use typescript and the exising library does not work with

[cwtuan]

As a developer, I sometimes have trouble with the regular JSON format when dealing with my project dependencies.

JSON5 is like an upgraded version of JSON. It has extra features such as comments and trailing commas. But, unfortunately, NPM, a popular tool for managing packages, doesn't accept JSON5 for its package.json file.

If Node.js could accept JSON5, it would help developers handle dependencies and settings in a clearer way. And don't worry, it would still work with the usual JSON format.

Usage Trend of JSON5

[rlidwka]

As a developer, I sometimes have trouble with the regular JSON format when dealing with my project dependencies.

@cwtuan, fortunately, you have some options here.

1. pnpm supports both package.json5 and package.yaml. Use it!

Since npm has always been (...), and yarn went into a weird direction since v2, pnpm is the best package manager right now anyway (on both usability and speed).

Downside of that approach is that 3rd party tools would still expect package.json. You can bother maintainers of those packages to support json5, or write your own tools.

2. You can switch to deno.

If you use deno, you specify your dependencies in the individual source files (people use deps.ts for this by convention). Which you can of course comment out, and use whatever syntax javascript modules allow you to use.

It installs dependencies much faster (native executable would outperform package managers written in js every time), it has security model that node.js doesn't have, so a choice worth considering anyway.

Since last year, deno has been pushing for backward compatibility with node.js, so everything should run fine by now, but support from 3rd party tools will be lacking. Again, if a tool doesn't do what you need, consider writing your own.

---

Personally, I've completely switched to deno a few months ago (because of this issue + dependency install time). But it'd be interesting to see more wide adoption of package.json5 managed by pnpm as well in node.js packages.