Node.js 13.2.0 及更高版本
Node.js 13.2.0现在支持不带标志的 ES 模块。但是,该实现仍被标记为实验性的,因此在生产中使用时要谨慎。
要在 13.2.0 中启用 ECMAScript 模块 (ESM) 支持,请将以下内容添加到您的package.json
:
{
"type": "module"
}
所有.js
, .mjs
(或没有扩展名的文件)将被视为 ESM。
除了完整的选择加入之外,还有许多不同的选项package.json
,所有这些选项都在13.2.0 的文档中进行了详细说明。
Node.js 13.1.0 及以下
那些仍在使用旧版本 Node 的人可能想尝试[esm][3]
模块加载器,它是 Node.js 的 ES 模块规范的生产就绪实现:
node -r esm main.js
详细更新...
2019 年 4 月 23 日
最近登陆的 PR 改变了 ECMAScript 模块的检测方式:
https ://github.com/nodejs/node/pull/26745
它仍然落后于--experimental-modules
标志,但加载模块的方式发生了重大变化:
package.type
可以是module
或者commonjs
type: "commonjs"
:
type: "module"
:
.js
被解析为 ECMAScript 模块
- 默认不支持加载 JSON 或原生模块
- 没有扩展的入口点的默认值是 ECMAScript 模块
--type=[mode]
让您在入口点设置类型。将覆盖package.type
入口点。
- 一个新的文件扩展名
.cjs
。
- 这是专门支持在
module
模式下导入 CommonJS 的。
- 这仅在 ECMAScript 模块加载器中,CommonJS 加载器保持不变,但如果您使用完整文件路径,扩展将在旧加载器中工作。
--es-module-specifier-resolution=[type]
- 选项是
explicit
(默认)和node
- 默认情况下,我们的加载器不允许在导入中使用可选的扩展名,如果有,模块的路径必须包含扩展名
- 默认情况下,我们的加载器不允许导入具有索引文件的目录
- 开发人员可以使用
--es-module-specifier-resolution=node
CommonJS 说明符解析算法来启用
- 这不是“功能”,而是实验的实现。预计在删除标志之前会发生变化
--experimental-json-loader
- 导入 JSON 的唯一方法
"type": "module"
- 当启用所有
import 'thing.json'
将通过独立于模式的实验加载器
- 基于whatwg/html#4315
- 您可以使用
package.main
为模块设置入口点
- main 中使用的文件扩展名将根据模块的类型进行解析
2019 年 1 月 17 日
Node.js 11.6.0仍然将 ES 模块列为实验性的,在标志后面。
2017 年 9 月 13 日
Node.js 8.5.0已发布,支持标志后面的 mjs 文件:
node --experimental-modules index.mjs
对此的计划是删除 v10.0 LTS 版本的标志。
——过时的信息。出于历史目的而保留在这里——
2017 年 9 月 8 日
Node.js 主分支已更新,初始支持 ESM 模块:
https ://github.com/nodejs/node/commit/c8a389e19f172edbada83f59944cad7cc802d9d5
这应该在最新的每晚可用(可以通过 nvm 安装以与您现有的安装一起运行):
https ://nodejs.org/download/nightly/
--experimental-modules
并在标志后面启用:
包.json
{
"name": "testing-mjs",
"version": "1.0.0",
"description": "",
"main": "index.mjs" <-- Set this to be an mjs file
}
然后运行:
node --experimental-modules .
2017 年 2 月:
Node.js 中 ES6 模块的更新
Node.js 的人已经决定最不坏的解决方案是使用.mjs
文件扩展名。从中得出的结论是:
换句话说,给定两个文件foo.js
和bar.mjs
, usingimport * from 'foo'
将被foo.js
视为 CommonJS 而import * from 'bar'
将被bar.mjs
视为 ES6 模块
至于时间线……
在当前时间点,在 Node.js 甚至可以开始构建可支持的 ES6 模块实现之前,仍然需要在 ES6 和虚拟机方面发生许多规范和实现问题。工作正在进行中,但需要一些时间——我们目前至少要考虑一年左右。
2016 年 10 月:
Node.js 的一位开发人员最近参加了 TC-39 会议,并写了一篇关于 Node.js 实施的阻止程序的精彩文章:
Node.js、TC-39 和模块
基本的收获是:
- ECMAScript 模块被静态分析,CommonJS 被评估
- CommonJS 模块允许猴子补丁导出,而 ECMAScript 模块目前不允许
- 如果没有某种形式的用户输入,很难检测出什么是 ECMAScript 模块和什么是 CommonJS,但他们正在尝试。
*.mjs
似乎是最有可能的解决方案,除非他们可以在没有用户输入的情况下准确检测到 ECMAScript 模块
-- 原始答案 --
很长一段时间以来,这一直是一个烫手山芋。底线是,是的,Node.js 最终将支持用于导入/导出模块的ES2015语法 - 最有可能在加载模块的规范最终确定并达成一致时。
这是一个很好的概述,是什么阻碍了 Node.js。本质上,他们需要确保新规范适用于主要是条件同步加载的 Node.js 以及主要是异步的 HTML。
现在没有人确切知道,但我想 Node.js 将支持import/export
静态加载,除了新System.import
的动态加载 - 同时仍然保留require
遗留代码。
以下是关于 Node 如何实现这一点的一些建议: