Closed SukkaW closed 2 years ago
The decision to not require a build step and publish the source code is a very intentional choice. As both a publisher and a consumer of packages I do not want anything else than the source code installed. Having multiple versions of the same files, which are conditionally loaded is just a recipe for disaster and a major pain point in the node/npm ecosystem. Publishing the raw source code, in a standardized format, avoids all the unnecessary complexity. You can just install the package, from npm or from Github, even from a specific commit or branch, and then use it directly. If you use a bundler/framework/environment that struggles with normal javascript you may need some special handling, but that is preferable to increasing the complexity for everyone else.
The decision to not require a build step and publish the source code is a very intentional choice. As both a publisher and a consumer of packages I do not want anything else than the source code installed. Having multiple versions of the same files, which are conditionally loaded is just a recipe for disaster and a major pain point in the node/npm ecosystem. Publishing the raw source code, in a standardized format, avoids all the unnecessary complexity. You can just install the package, from npm or from Github, even from a specific commit or branch, and then use it directly. If you use a bundler/framework/environment that struggles with normal javascript you may need some special handling, but that is preferable to increasing the complexity for everyone else.
It is even a bigger disaster when you use index.js
as the filename of an ESM module without setting type: module
in the package.json
. And you are even mixing ESM and CJS files in the same project.
You should either rename the file to index.mjs
, or add type: module
to the package.json
(where you have to rename all CommonJS module to use .cjs
file extension), or build both CJS and ESM versions.
Node.js (and Webpack, and Rollup, and any other bundlers, you name it) will consider this file as a CommonJS module where it is actually an ESM module. That's why you have to add next-transpile-modules
.
https://nodejs.org/docs/latest/api/esm.html#esm_differences_between_es_modules_and_commonjs
Node.js will treat the following as ES modules when passed to node as the initial input, or when referenced by import statements or import() expressions:
- Files with an .mjs extension.
- Files with a .js extension when the nearest parent package.json file contains a top-level "type" field with a value of "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, import() expressions, or require() expressions:
- Files with a .cjs extension.
- Files with a .js extension when the nearest parent package.json file contains a top-level field "type" with a value of "commonjs".
Add
rollup.config.js
to build CommonJS and ESM format ofstyle9
entries and add the correct exports map (for Node.js 12+).This removes the requirements for
next-transpile-module
and also enables wider bundler support.