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
module: Unflag JSON modules #41736
module: Unflag JSON modules #41736
Conversation
Review requested: |
e116204
to
c63bfc3
Compare
I still believe this should not happen until it's possible to import JSON modules without an assertion. |
To clarify, you think the unflagging should wait, correct? Also, it is already possible to import JSON modules without an assertions using custom loaders, so would you be satisfied if there was a CLI flag to enable that? |
Changes LGTM. I'm not concerned about the assertion-less scenario as it's already possible. I'm not aware of any other concerns that would prevent unflagging.
This section should also be updated:
Lines 480 to 494 in f458f1b
#### No JSON Module Loading | |
JSON imports are still experimental and only supported via the | |
`--experimental-json-modules` flag. | |
Local JSON files can be loaded relative to `import.meta.url` with `fs` directly: | |
<!-- eslint-skip --> | |
```js | |
import { readFile } from 'fs/promises'; | |
const json = JSON.parse(await readFile(new URL('./dat.json', import.meta.url))); | |
``` | |
Alternatively `module.createRequire()` can be used. |
Otherwise, LGTM
@aduh95 yes, i believe unflagging should wait, until it’s possible by default to import json assertionless, with no flags. |
c63bfc3
to
bd1f35b
Compare
a85b524
to
a63df21
Compare
I have no problems with this PR, but likely we should figure out how to describe cache behavior in a follow on for collisions due to the JS spec since there are multiple resolution strategies possible. I'm fine punting that effort due to scope being unclear.
@ljharb I'd also like to see assertionless JSON imports happen at some point (I even tried to make them happen), but I don't think it's reasonable to block the unflagging until it happens, and that was also the takeaway of the discussion last time it was brought up at the TSC meeting. Unflagging JSON modules now will let folks start exploring them in the wild, and gather more feedback. Holding it up wouldn't help much I'm afraid. |
PR-URL: #41736 Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Guy Bedford <guybedford@gmail.com> Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Bradley Farias <bradley.meck@gmail.com>
Notable changes: lib: * (SEMVER-MINOR) add fetch (Michaël Zasso) #41749 module: * unflag esm json modules (Geoffrey Booth) #41736 node-api: * (SEMVER-MINOR) add node_api_symbol_for() (Darshan Sen) #41329 stream: * (SEMVER-MINOR) add iterator helper find (linkgoron) #41849 * (SEMVER-MINOR) add toArray (Benjamin Gruenbaum) #41553 * (SEMVER-MINOR) add forEach method (Benjamin Gruenbaum) #41445 * (SEMVER-MINOR) support some and every (Benjamin Gruenbaum) #41573 deps: * upgrade npm to 8.4.1 (npm team) [#41836](#41836)
Notable changes: lib: * (SEMVER-MINOR) add fetch (Michaël Zasso) #41749 module: * unflag esm json modules (Geoffrey Booth) #41736 node-api: * (SEMVER-MINOR) add node_api_symbol_for() (Darshan Sen) #41329 stream: * (SEMVER-MINOR) add iterator helper find (linkgoron) #41849 * (SEMVER-MINOR) add toArray (Benjamin Gruenbaum) #41553 * (SEMVER-MINOR) add forEach method (Benjamin Gruenbaum) #41445 * (SEMVER-MINOR) support some and every (Benjamin Gruenbaum) #41573 deps: * upgrade npm to 8.4.1 (npm team) [#41836](#41836)
Notable changes: lib: * (SEMVER-MINOR) add fetch (Michaël Zasso) #41749 module: * unflag esm json modules (Geoffrey Booth) #41736 node-api: * (SEMVER-MINOR) add node_api_symbol_for() (Darshan Sen) #41329 stream: * (SEMVER-MINOR) add iterator helper find (linkgoron) #41849 * (SEMVER-MINOR) add toArray (Benjamin Gruenbaum) #41553 * (SEMVER-MINOR) add forEach method (Benjamin Gruenbaum) #41445 * (SEMVER-MINOR) support some and every (Benjamin Gruenbaum) #41573 deps: * upgrade npm to 8.4.1 (npm team) [#41836](#41836)
Notable changes: lib: * (SEMVER-MINOR) add fetch (Michaël Zasso) #41749 module: * unflag esm json modules (Geoffrey Booth) #41736 node-api: * (SEMVER-MINOR) add node_api_symbol_for() (Darshan Sen) #41329 stream: * (SEMVER-MINOR) add iterator helper find (linkgoron) #41849 * (SEMVER-MINOR) add toArray (Benjamin Gruenbaum) #41553 * (SEMVER-MINOR) add forEach method (Benjamin Gruenbaum) #41445 * (SEMVER-MINOR) support some and every (Benjamin Gruenbaum) #41573 deps: * upgrade npm to 8.4.1 (npm team) [#41836](#41836) PR-URL: #41897
Notable changes: lib: * (SEMVER-MINOR) add fetch (Michaël Zasso) #41749 module: * unflag esm json modules (Geoffrey Booth) #41736 node-api: * (SEMVER-MINOR) add node_api_symbol_for() (Darshan Sen) #41329 stream: * (SEMVER-MINOR) add iterator helper find (linkgoron) #41849 * (SEMVER-MINOR) add toArray (Benjamin Gruenbaum) #41553 * (SEMVER-MINOR) add forEach method (Benjamin Gruenbaum) #41445 * (SEMVER-MINOR) support some and every (Benjamin Gruenbaum) #41573 deps: * upgrade npm to 8.4.1 (npm team) [#41836](#41836) PR-URL: #41897
PR-URL: #41736 Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Guy Bedford <guybedford@gmail.com> Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Bradley Farias <bradley.meck@gmail.com>
@GeoffreyBooth just want to confirm for release purposes - should this be semver-minor or is this a patch? |
Unflagging is adding something new for the end user, so it definitely shouldn’t be a patch. |
JSON modules are experimental, so semver rules don't apply to it. It does enable new capabilities that's true, maybe somone from @nodejs/lts have an option regarding this landing on a semver-patch LTS? |
To me that just means it can break in a non-major, not that semver loses all meaning. |
fwiw, I think this should be a minor |
This feels like a minor to me. It's arguably new functionality, not a bugfix. |
Thanks all, i'll tag as minor |
WebAssembly has been unflagged in V8 for years, and is presented on equal footing with Javascript in [how V8 describes itself][v8.dev] for years now ("Google’s open source high-performance JavaScript and WebAssembly engine"). I can't find any specified reasons to keep it flagged and called experimental in Node (though maybe this PR will draw those out?). Following nodejs#41736 as a model, this PR leaves the flag present as a no-op and removes it from documentation, but keeps the "Stability: 1 - Experimental" in esm.md and the runtime warning message. I want to remove those too (or else draw out some specified reasons not to :) ) but there appears to be a convention of decoupling unflagging from stabilizing: nodejs#41736 (comment), so, like JSON modules, maybe drop the warning in 18.0.0? [v8.dev]: https://v8.dev/
WebAssembly has been unflagged in V8 for years, and is presented on equal footing with Javascript in [how V8 describes itself][v8.dev] for years now ("Google’s open source high-performance JavaScript and WebAssembly engine"). I can't find any specified reasons to keep it flagged and called experimental in Node (though maybe this PR will draw those out?). Following nodejs#41736 as a model, this PR leaves the flag present as a no-op and removes it from documentation, but keeps the "Stability: 1 - Experimental" in esm.md and the runtime warning message. I want to remove those too (or else draw out some specified reasons not to :) ) but there appears to be a convention of decoupling unflagging from stabilizing: nodejs#41736 (comment), so, like JSON modules, maybe drop the warning in 18.0.0? [v8.dev]: https://v8.dev/
WebAssembly has been unflagged in V8 for years, and is presented on equal footing with Javascript in [how V8 describes itself][v8.dev] for years now ("Google’s open source high-performance JavaScript and WebAssembly engine"). I can't find any specified reasons to keep it flagged and called experimental in Node (though maybe this PR will draw those out?). Following nodejs#41736 as a model, this PR leaves the flag present as a no-op and removes it from documentation, but keeps the "Stability: 1 - Experimental" in esm.md and the runtime warning message. I want to remove those too (or else draw out some specified reasons not to :) ) but there appears to be a convention of decoupling unflagging from stabilizing: nodejs#41736 (comment), so, like JSON modules, maybe drop the warning in 18.0.0? [v8.dev]: https://v8.dev/
This PR unflags JSON modules, removing the
--experimental-json-modules
flag.import
of JSON files is already unflagged in Chrome, and the HTML spec has stabilized since the change that led to JSON modules’ unflagging being reverted two years ago in #29754. Deno also added support for the same syntax in denoland/deno#12866.Since we added support for import assertions in #40250, I haven’t heard of any issues with the experimental implementation.
cc @MylesBorins @aduh95 @guybedford @nodejs/modules @nodejs/loaders