nx NX automatically adds `"type": "commonjs"` to package.json when using generators, which breaks imports with 16.8 changes

Current Behavior

New packages created with generators have "type": "commonjs" in their package.json, which in [email protected] prevents them from being imported by some projects (for example, a vanilla create-react-app project) if "generateExportsField" is also set to true.

Module parse failed: 'import' and 'export' may appear only with 'sourceType: module' (1:0)
File was processed with these loaders:
 * ./node_modules/babel-loader/lib/index.js
 * ./node_modules/source-map-loader/dist/cjs.js
You may need an additional loader to handle the result of these loaders.

I'm able to work around this by explicitly setting my package.json's "type": undefined in my generator, but this feels like a pretty easy thing to miss.

Since everything seems to work fine without "type": "commonjs" (I tested it in both ESM and commonjs consumers), should this simply not be added automatically?

Expected Behavior

New packages created with generators have able to be imported into React projects as ES modules.

GitHub Repo

No response

Steps to Reproduce

use a generator based on libraryGenerator to create a package in a monorepo
use executor: '@nx/rollup:rollup' and generateExportsField: true in the package's build
observe "type": "commonjs" is added automatically to the dist/package.json when built
use npx create-react-app to create a barebones react app
observe that artifacts from the nx package cannot be imported due to above module error

Nx Report

>  NX   Report complete - copy this into the issue template

   Node   : 18.13.0
   OS     : linux-x64
   npm    : 9.7.2
   
   nx                 : 16.9.1
   @nx/js             : 16.9.1
   @nx/jest           : 16.9.1
   @nx/linter         : 16.9.1
   @nx/workspace      : 16.9.1
   @nx/devkit         : 16.9.1
   @nx/eslint-plugin  : 16.9.1
   @nx/plugin         : 16.9.1
   @nx/rollup         : 16.9.1
   @nrwl/tao          : 16.9.1
   @nx/web            : 16.9.1
   nx-cloud           : 16.4.0
   typescript         : 5.1.6
   ---------------------------------------
   Local workspace plugins:
         @js-sdk-contrib/workspace-plugin

Failure Logs

Module parse failed: 'import' and 'export' may appear only with 'sourceType: module' (1:0)
File was processed with these loaders:
 * ./node_modules/babel-loader/lib/index.js
 * ./node_modules/source-map-loader/dist/cjs.js
You may need an additional loader to handle the result of these loaders.

Package Manager Version

No response

Operating System

[ ] macOS
[X] Linux
[ ] Windows
[ ] Other (Please specify)

Additional Information

Workaround: https://github.com/open-feature/js-sdk-contrib/pull/596

Sep 29 '23 16:09 toddbaert

I'm not really sure this is related (but it probably is). Even if "type": "module" is in the source package.json file it is replaced by "type": "commonjs" in the generated output.

So I'm following this issue as this breaks my entire project if I want to upgrade to 16.8

Oct 04 '23 14:10 3dos

I'm not really sure this is related (but it probably is). Even if "type": "module" is in the source package.json file it is replaced by "type": "commonjs" in the generated output.

So I'm following this issue as this breaks my entire project if I want to upgrade to 16.8

hmm. That's a bit surprising to me, since I was able to work around this with "type": undefined in my generators. I haven't experimented with it in the source package.json.

Oct 04 '23 15:10 toddbaert

possibly related: https://github.com/nrwl/nx/issues/18801

Oct 24 '23 12:10 mandarini

As I commented on the linked issue, I think there's a logical flaw in Nx trying to determine the type of package based on the tsconfig module setting. That seems to be what's happening here.

Everyone working in this area should read some of Typescript's new docs about this stuff, it explains a lot of things that I think Nx is currently doing wrong and producing invalid package outputs https://www.typescriptlang.org/docs/handbook/modules/reference.html#the-module-compiler-option