Node.js will treat the following as [ES modules][] when passed to node
as the
initial input, or when referenced by import
statements within ES module code:
Files ending in
.mjs
.Files ending in
.js
when the nearest parentpackage.json
file contains a top-level ["type"
][] field with a value of"module"
.Strings passed in as an argument to
--eval
, or piped tonode
viaSTDIN
, with the flag--input-type=module
.
Node.js will treat as [CommonJS][] all other forms of input, such as .js
files
where the nearest parent package.json
file contains no top-level "type"
field, or string input without the flag --input-type
. This behavior is to
preserve backward compatibility. However, now that Node.js supports both
CommonJS and ES modules, it is best to be explicit whenever possible. Node.js
will treat the following as CommonJS when passed to node
as the initial input,
or when referenced by import
statements within ES module code:
Files ending in
.cjs
.Files ending in
.js
when the nearest parentpackage.json
file contains a top-level field ["type"
][] with a value of"commonjs"
.Strings passed in as an argument to
--eval
or--print
, or piped tonode
viaSTDIN
, with the flag--input-type=commonjs
.
Package authors should include the ["type"
][] field, even in packages where
all sources are CommonJS. Being explicit about the type
of the package will
future-proof the package in case the default type of Node.js ever changes, and
it will also make things easier for build tools and loaders to determine how the
files in the package should be interpreted.