module: unflag detect-module#53619
Merged
nodejs-github-bot merged 1 commit intonodejs:mainfrom Jul 20, 2024
Merged
Conversation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Notable change
Module syntax detection (the
--experimental-detect-moduleflag) is now enabled by default. Use--no-experimental-detect-moduleto disable it if needed.Syntax detection attempts to run ambiguous files as CommonJS, and if the module fails to parse as CommonJS due to ES module syntax, Node.js tries again and runs the file as an ES module. Ambiguous files are those with a
.jsor no extension, where the nearest parentpackage.jsonhas no"type"field (either"type": "module"or"type": "commonjs"). Syntax detection should have no performance impact on CommonJS modules, but it incurs a slight performance penalty for ES modules; add"type": "module"to the nearest parentpackage.jsonfile to eliminate the performance cost. A use case unlocked by this feature is the ability to use ES module syntax in extensionless scripts with no nearbypackage.json.Description
This is a PR to unflag
--experimental-detect-module. It does two things:--experimental-detect-moduleflag enabled by default, letting people disable it via--no-experimental-detect-module.formathint returned by Node’s internalresolvefor ambiguous (nopackage.jsontypefield, no.mjsor.cjsextension) files fromcommonjstonull. This is more correct, as the format hasn’t yet been determined at the time of resolution, because with detection enabled we need to load the source and parse it to detect the format.I also updated the tests because of the unflagging:
Not breaking changes
test/es-module/test-esm-cjs-exports.jsshould error on invalid CJS exports: Previously this was testing for the error stringsWarning: To load an ES moduleandUnexpected token \'export\'; now it tests for the error stringSyntaxError: The requested module './invalid-cjs.js' does not provide an export named 'default'. Arguably the new version is more appropriate as it’s testing the actual thing the test describes rather than testing an error that was thrown before getting to the invalid CommonJS exports.test/es-module/test-esm-import-flag.mjsshould import when running –check fails: This test checks that an ESM file passed to--importis evaluated with a CommonJS entry passed to--checkfails the syntax check. The file passed to--importis run in both cases, though the previousSyntaxErroris now a success; but the point of the test is about the--importfile being evaluated at all, not whether its evaluation was successful.test/es-module/test-require-module-implicit.js: Some tests were attempting torequirean ambiguous, extensionless ESM file and expecting an exception withUnexpected token 'export'. These tests were removed. This file is run via--experimental-require-moduleso this change shouldn’t be considered breaking.Possibly breaking changes
test/es-module/test-esm-detect-ambiguous.mjsshould not hint wrong format in resolve hook: Previously this expected aformathint ofcommonjsfrom aresolvehook, and now it expectsnull, an intentional change. The hooks are still experimental and theformathint fromresolveis documented as optional, so hooks should be written to expect it not to be present; but the unflagging would cause some code that currently returns a hint to no longer do so.test/es-module/test-esm-loader-hooks.mjsshould use ESM loader to respond to require.resolve calls when opting in: Theloadhook in this test previously assumed that most files being imported got aformatofcommonjs, whereas now many of them areundefined, an intentional change. Same impact as previous.test/es-module/test-esm-resolve-type.mjs: Some tests for aformathint ofcommonjsnow check for aformathint ofnull. Same impact as previous.test/es-module/test-esm-extensionless-esm-and-wasm.mjs:extensionless ES modules within no package scope: tests for ambiguous extensionless ESM running as the entry point and ambugious extensionless ESM running viaimport()used to test for exceptions being thrown; now they test for success. Anyone expecting exceptions on running or importing ambiguous or extensionless ESM (for example, to do detection themselves) will be broken by this change.