Coder Social home page Coder Social logo

Support JSON5 about proposal-json-modules HOT 4 OPEN

tc39 avatar tc39 commented on June 16, 2024 15
Support JSON5

from proposal-json-modules.

Comments (4)

Andrew-Cottrell avatar Andrew-Cottrell commented on June 16, 2024 7

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?

from proposal-json-modules.

tomByrer avatar tomByrer commented on June 16, 2024

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

But I wish both could happen.

from proposal-json-modules.

styfle avatar styfle commented on June 16, 2024

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" } });

from proposal-json-modules.

errorx666 avatar errorx666 commented on June 16, 2024

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.

from proposal-json-modules.

Related Issues (17)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.