Starting from version 8.5.0, Node.js supports native ES modules, which can be turned on through command line options. The new features are largely due to Bradley Farias. This article mainly introduces to you the use of native ES module method parsing in Node.js, as well as links to some content. Let’s take a look at it together. Friends who need it can refer to it. I hope it can help you.
1. Demonstration
The code directory structure of this example is as follows:
esm-demo/ lib.mjs main.mjs
lib. mjs:
export function add(x, y) { return x + y; }
main.mjs:
##
import {add} from './lib.mjs'; console.log('Result: '+add(2, 3));
$ node --experimental-modules main.mjs Result: 5
2. Checklist: Things to note
·Can’t Dynamically import modules. However, work on dynamic import() is in progress and support should be available soon.
·There are no meta variables such as __dirname and __filename. However, there is a proposal for a similar function: "import.meta". It might look like this:
console.log(import.meta.url);
·Now all module identifiers are URLs (this part is new in Node.js):
· File - Relative path with file extension: ../util/tools.mjs
Library - no file extension and no path lodash
It remains to be seen how better to make the npm library also available in the browser (without using bundler). One possibility is to introduce RequireJS-style configuration data that maps paths to actual paths. Currently, it is illegal to use bare path module identifiers in browsers.
You can import CJS modules, but they always only have the default exports - i.e. module.exports value. Making CJS modules support named exports is already being worked on, but may take a while. If you can help, you can do it.
import fs1 from 'fs'; console.log(Object.keys(fs1).length); // 86 import * as fs2 from 'fs'; console.log(Object.keys(fs2)); // ['default']
Require() cannot be used in ES modules. The main reason is:
Path resolution works slightly differently: ESM does not support NODE_PATH and require.extensions. Also, the fact that its identifier is always a URL causes some slight differences.
ES modules are always loaded asynchronously, which ensures maximum compatibility with the web. This loading style cannot be mixed with synchronous loading of CJS modules via require().
Disabling synchronous module loading can also preserve a fallback path for Top-level await imported ES modules (a feature currently under consideration).
If you want to use it on Node.js versions before 8.5.0 ES modules, see John-David Dalton's @std/esm.
Tip: If you do not enable any unlockable extra features, you will remain 100% compatible with native ES modules in Node.js.
The current plan is to make ES modules available by default in Node.js 10 LTS.
For more information about ES modules in Node.js and the browser:
“Making transpiled ES modules more spec-compliant” [using ES modules natively vs. transpiling them via Babel]
“Module specifiers: what's new with ES modules?” [Why .mjs? How are module specifiers resolved? Etc.]
“Modules” [in-depth chapter on ES modules in “Exploring ES6”]
Upcoming ECMAScript proposals:
Blog: “ES proposal: import() – dynamically importing ES modules”
Proposal: "import.meta"Related recommendations:
The above is the detailed content of How to use native ES modules in Node.js. For more information, please follow other related articles on the PHP Chinese website!