The future of --experimental-json-modules

[targos]

The import assertions proposal is in stage 3 and V8 implemented it (the API will be available in V8 8.9).
The JSON modules proposal is in stage 2 and is built on top of import assertions.

I think it's time to discuss about what we are going to do with --experimental-json-modules.
We'll be able to implement the type: "json" assertion soon. Should we aim to replace --experimental-json-modules with it? Should we add a new experimental flag? Should we deprecate the current behavior of --experimental-json-modules?

@nodejs/modules

[ljharb]

JSON Modules will be stage 3 once reviewers have finished reviewing it.

[devsnek]

I would pull the experimental json modules and use the official v8 impl when it lands.

[zackschuster]

assuming assertions are mandatory, i don't think the flag should "just" be pulled, for the sake of those unable to adopt new syntax (e.g. teams stuck on an older typescript by angular 8). they'd be effectively blocked from updating the platform if they ever relied on importing json. i'd recommend replacing the flag instead with one that allows omitting assertions.

[devsnek]

@zackschuster importing json does not require type: json, but any import with type: json must be a json module.

[zackschuster]

@devsnek that's good then. last i heard was that it wasn't certain if the assertion would be mandatory, at least under node. being able to simply drop the flag without code changes is nice :)

[bmeck]

@zackschuster likely it won't be mandatory under node, but due to some reasons likely it won't have the same cache key between them so you could get 2 different modules if you do or do not include the assertion.

[zackschuster]

@bmeck would that just mean another read from disk, or is it supposed to be possible to observably mutate the json module?

[devsnek]

in the context of node's resolver I would not expect it to use type:json as part of the cache key (assertions are specificallynot resolver attributes)

[bmeck]

Assertions are specifically part of resolution, see tc39/proposal-json-modules#10

[ljharb]

They are allowed to be; they are also allowed not to be, and encouraged not to be. The web won’t make them part of the cache key when it can avoid it, for example - which won’t be always.

[bmeck]

@zackschuster I'm unclear on the question, I would expect if we follow the web spec, it usually wouldn't cause a secondary read due to having a fetch cache (node currently does not have one). In the web if a HREF resolves and it has an existing entry w/ a different type an error is expected to be thrown, I don't think Node would throw that error. So, we could see 2 disk reads if there isn't a cache, same as today; and JSON modules are mutable so mutation is observable.

[bmeck]

The web won’t make them part of the cache key when it can avoid it, for example - which won’t be always.

This is 100% false, in the web they will 100% of the time be part of the cache key when they go through the fetch infrastructure.

[devsnek]

@bmeck my understanding and consensus was on them not being required to be part of the cache key. is that not the case?