Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should JSON modules export Records/Tuples? #2

Open
dandclark opened this issue Aug 27, 2020 · 2 comments
Open

Should JSON modules export Records/Tuples? #2

dandclark opened this issue Aug 27, 2020 · 2 comments

Comments

@dandclark
Copy link
Collaborator

As currently proposed, JSON modules have a default export and no other exports, where the default export is the object resulting from parsing the module's content as JSON, like what you'd get from JSON.parse(). In the July TC39 meeting (notes here) @rricard and @erights expressed interest in exporting Records/Tuples instead of an object.

Pro: For folks in favor of #1 , the immutability is a positive. IMO exporting as Record/Tuple is a nicer way of achieving immutability than doing Object.freeze under the hood, although as I stated in the other Issue I'm not convinced that immutability is a requirement.
Con: People have long-standing historical expectations that JSON is an Object (I think @bmeck raised a point like this during the meeting). Any change where JSON modules produce something fundamentally different from JSON.parse() could be a source of confusion and even a drag on adoption. My expectation had been that developers would be able to straightforwardly swap out parts of their code that did thinks like fetch() content that gets fed to JSON.parse() and replace with a simpler import of a JSON module. The more that JSON.parse() differs from JSON modules, the harder this gets. Then again, I see that JSON.parseImmutable() is also proposed so perhaps one could argue that we're looking to expand the expectations about what JSON should be in JS and that long-term this isn't a concern.

Thoughts? I guess this whole issue is contingent on the discussion at #1 about whether JSON modules should be immutable in the first place, so maybe that needs to be decided first.

@bmeck
Copy link
Member

bmeck commented Aug 27, 2020

I will restate; I think the biggest issue is that various tools already load JSON as Objects. I do not think it appropriate to alter that de-facto output / expectation from tooling, but do think any sort of new expectations can just use a new attribute to flag the import for specialized evaluation.

@Jamesernator
Copy link

I think it would be worth investigating having a new module attribute kind for loading JSON as immutable, e.g. import config from "./config.json" with { kind: "immutable" } assert { type: "json" };.

This however would probably need to create a second module record, although it could re-use the same backing json string so it's probably not a big deal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants