mirror of
https://github.com/nodejs/node.git
synced 2024-12-01 16:10:02 +01:00
b1094dbe19
This PR updates the current `--experimental-modules` implementation
based on the work of the modules team and reflects Phase 2 of our
new modules plan.
The largest differences from the current implementation include
* `packge.type` which can be either `module` or `commonjs`
- `type: "commonjs"`:
- `.js` is parsed as commonjs
- default for entry point without an extension is commonjs
- `type: "module"`:
- `.js` is parsed as esm
- does not support loading JSON or Native Module by default
- default for entry point without an extension is esm
* `--entry-type=[mode]`
- allows you set the type on entry point.
* A new file extension `.cjs`.
- this is specifically to support importing commonjs in the
`module` mode.
- this is only in the esm loader, the commonjs loader remains
untouched, but the extension will work in the old loader if you use
the full file path.
* `--es-module-specifier-resolution=[type]`
- options are `explicit` (default) and `node`
- by default our loader will not allow for optional extensions in
the import, the path for a module must include the extension if
there is one
- by default our loader will not allow for importing directories that
have an index file
- developers can use `--es-module-specifier-resolution=node` to
enable the commonjs specifier resolution algorithm
- This is not a “feature” but rather an implementation for
experimentation. It is expected to change before the flag is
removed
* `--experimental-json-loader`
- the only way to import json when `"type": "module"`
- when enable all `import 'thing.json'` will go through the
experimental loader independent of mode
- based on https://github.com/whatwg/html/issues/4315
* You can use `package.main` to set an entry point for a module
- the file extensions used in main will be resolved based on the
`type` of the module
Refs: https://github.com/nodejs/modules/blob/master/doc/plan-for-new-modules-implementation.md
Refs: https://github.com/GeoffreyBooth/node-import-file-specifier-resolution-proposal
Refs: https://github.com/nodejs/modules/pull/180
Refs: https://github.com/nodejs/ecmascript-modules/pull/6
Refs: https://github.com/nodejs/ecmascript-modules/pull/12
Refs: https://github.com/nodejs/ecmascript-modules/pull/28
Refs: https://github.com/nodejs/modules/issues/255
Refs: https://github.com/whatwg/html/issues/4315
Refs: https://github.com/w3c/webcomponents/issues/770
Co-authored-by: Myles Borins <MylesBorins@google.com>
Co-authored-by: John-David Dalton <john.david.dalton@gmail.com>
Co-authored-by: Evan Plaice <evanplaice@gmail.com>
Co-authored-by: Geoffrey Booth <webmaster@geoffreybooth.com>
Co-authored-by: Michaël Zasso <targos@protonmail.com>
PR-URL: https://github.com/nodejs/node/pull/26745
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Guy Bedford <guybedford@gmail.com>
Reviewed-By: Ben Coe <bencoe@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com>
|
||
|---|---|---|
| .. | ||
| abort | ||
| addons | ||
| async-hooks | ||
| benchmark | ||
| cctest | ||
| code-cache | ||
| common | ||
| doctool | ||
| es-module | ||
| fixtures | ||
| internet | ||
| js-native-api | ||
| known_issues | ||
| message | ||
| node-api | ||
| parallel | ||
| pseudo-tty | ||
| pummel | ||
| report | ||
| sequential | ||
| testpy | ||
| tick-processor | ||
| v8-updates | ||
| wpt | ||
| .eslintrc.yaml | ||
| README.md | ||
| root.status | ||
Node.js Core Tests
This directory contains code and data used to test the Node.js implementation.
For a detailed guide on how to write tests in this directory, see the guide on writing tests.
On how to run tests in this directory, see the contributing guide.
For the tests to successfully run on Windows, Node.js has to be checked out from
GitHub with the autocrlf git config flag set to true.
Test Directories
| Directory | Runs on CI | Purpose |
|---|---|---|
abort |
Yes | Tests for when the --abort-on-uncaught-exception flag is used. |
addons |
Yes | Tests for addon functionality along with some tests that require an addon to function properly. |
async-hooks |
Yes | Tests for async_hooks functionality. |
benchmark |
No | Test minimal functionality of benchmarks. |
cctest |
Yes | C++ tests that are run as part of the build process. |
code-cache |
No | Tests for a Node.js binary compiled with V8 code cache. |
common |
Common modules shared among many tests. Documentation | |
doctool |
Yes | Tests for the documentation generator. |
es-module |
Yes | Test ESM module loading. |
fixtures |
Test fixtures used in various tests throughout the test suite. | |
internet |
No | Tests that make real outbound connections (mainly networking related modules). Tests for networking related modules may also be present in other directories, but those tests do not make outbound connections. |
js-native-api |
Yes | Tests for Node.js-agnostic n-api functionality. |
known_issues |
Yes | Tests reproducing known issues within the system. All tests inside of this directory are expected to fail consistently. If a test doesn't fail on certain platforms, those should be skipped via known_issues.status. |
message |
Yes | Tests for messages that are output for various conditions (console.log, error messages etc.) |
node-api |
Yes | Tests for Node.js-specific n-api functionality. |
parallel |
Yes | Various tests that are able to be run in parallel. |
pseudo-tty |
Yes | Tests that require stdin/stdout/stderr to be a TTY. |
pummel |
No | Various tests for various modules / system functionality operating under load. |
sequential |
Yes | Various tests that are run sequentially. |
testpy |
Test configuration utility used by various test suites. | |
tick-processor |
No | Tests for the V8 tick processor integration. The tests are for the logic in lib/internal/v8_prof_processor.js and lib/internal/v8_prof_polyfill.js. The tests confirm that the profile processor packages the correct set of scripts from V8 and introduces the correct platform specific logic. |
v8-updates |
No | Tests for V8 performance integration. |