Tools: You cannot use CommonJS exports in an ES module

[cavoirom]

Description:

I got an error while bundling my React application

node_modules/symbol-observable/lib/index.js:29 analyzeDependencies 

✖ You cannot use CommonJS exports in an ES module

28 │ var result = (0, _ponyfill2['default'])(root);
29 │ exports['default'] = result;
   │ ^^^^^^^^^^^^^^^^^^^^^^^^^^^

Steps To Reproduce

I'm not sure about the config, here is my project information:

• In package.json, I specify "type": "module" because other type does not allow me to use import.
• Project dependency: react, redux
• I got this issue from Rome commit 105fd775.

Expected Results

Rome should allow CommonJS dependencies when building ES6 Module.

[cavoirom]

Work around

When I remove the "type": "module" from symbol-observable's package.json. I can bundle successfully.

[ljharb]

If you use type module, it’s ESM, which doesn’t have exports. If you don’t, it’s CJS, which doesn’t have import.

[cavoirom]

The problem is Rome resolve wrong JavaScript file in dependencies.
It bundles the files in /lib/* of a dependency when it's package.json already declare "type": "module", it should resolve file in /es/*.

[ljharb]

That’s not how type module works - it just means that dot js files are ESM.

You’d need the “exports” field to conditionally point imports at a different directory.

[cavoirom]

It happen in the dependency. In my case: symbol-observable. Do I need to manually change the symbol-observable source code to make it works?

[ljharb]

In this case, it's not using type: "module", it's using the nonstandard "module" field. I'm not sure if Rome pays attention to it (but I hope it doesn't, since nobody should be relying on nonstandard module fields). If it's not, then it should be pointing to https://unpkg.com/browse/[email protected]/lib/index.js which is a CJS module.

[sebmck]

it's using the nonstandard "module" field. I'm not sure if Rome pays attention to it

It doesn't. The Node ES modules resolution is the only thing implemented. jsnext:main used to be supported as an alternative to main but I removed it a couple days ago.

[cavoirom]

Now I was confuse wherever it's a bug in Rome or it's a bug in symbol-observable?

[sebmck]

Did you add the "type": "module" field to the package.json of symbol-observable or was it already there? I can't find it in the source repo or npm release.

[cavoirom]

Did you add the "type": "module" field to the package.json of symbol-observable or was it already there? I can't find it in the source repo or npm release.

It is modified. I don't why the symbol-observable/package.json in my node_modules was modified and added with some specific information related to my project. I could see the lines:

"_requiredBy": [
  "/redux"
],

redux is my project's direct dependency.

The command I used to install redux is npm install --save redux

In the package.json of my project. I specified "type": "module". I don't know if it could affect the dependencies or not.

[ljharb]

It should not; the "type" field does not extend to things in node_modules.

[sebmck]

Did you add the "type": "module" field to the package.json of symbol-observable or was it already there? I can't find it in the source repo or npm release.

It is modified. I don't why the symbol-observable/package.json in my node_modules was modified and added with some specific information related to my project. I could see the lines:

Those are some properties injected by npm (or yarn).

In the package.json of my project. I specified "type": "module". I don't know if it could affect the dependencies or not.

There might be a bug in the way we resolve manifests when providing them to a worker. All workers are sent a (sub)copy of every single manifest in a project and assigned to an id. Whenever we need to perform an operation on a file, we also include the relevant manifest id. There might be something wrong there.

[sebmck]

We're just focused on linting which shouldn't surface dependency graph errors from inside node_modules. This should be addressed when we eventually tackle bundling.