tc39 / proposal-json-modules

Proposal to import JSON files as modules
https://tc39.es/proposal-json-modules
Apache License 2.0
265 stars 21 forks source link

Support JSON5 #14

Open phistuck opened 3 years ago

phistuck commented 3 years ago

JSON5 basically allows comments in JSON and some harmless leniency - https://json5.org/ type: "json5"?

tomByrer commented 3 years ago

I do not think browsers natively can process JSON5. That might be a better place to start.

But I wish both could happen.

Andrew-Cottrell commented 2 years ago

Seems like a load of haters have clicked the dislike button and given no comment to the reason why they hate the idea.

Thumbs down doesn't mean hate!

I am concerned with interoperability and narrowing the attack surface. Besides, I believe it's very easy to convert JSON5 to JSON on the HTTP server or application server at the point of transmission or earlier. For a static website it might be necessary to convert from JSON5 to JSON at deploy time using a build tool, but again this should be very easy.

Is there a use case where it would be useful to support JSON5 in import modules and it would also be difficult to convert to JSON before transmission?

Why choose to support JSON5 rather than HJSON, HOCON, or YAML, which are also strict JSON supersets?

styfle commented 1 year ago

I think JSON5 belongs in its own proposal.

For example, I would also want JSON.parse() and JSON.stringify() too

JSON.parse(str, { type: "json5" })
JSON.stringify(obj, { type: "json5" })

in addition to imports

import foo from "./foo.json" assert { type: "json5" };
import("foo.json", { assert: { type: "json5" } });
errorx666 commented 2 months ago

Why choose to support JSON5 rather than HJSON, HOCON, or YAML, which are also strict JSON supersets?

I don't see how one precludes the others. I'd even like to see import string from './foo.txt' with { type: 'text', encoding: 'utf8' }; which would enable userland parsing for arbitrary formats. Or perhaps type: 'buffer'.

Perhaps there could be some other extensibility mechanism for registering custom types. I imagine something like:

import 'js-yaml/register'; // some code to register custom type: yaml
import yaml from 'foo.yaml' with { type: 'yaml' };

I'm already accomplishing similar effects with webpack custom loaders, but I'd love to lose the dependency on an external bundler.

I do see the value in minimizing the scope of this proposal though. These should be follow-on proposals.