ESM version is never used

[akanass]

Bug Report

Current Behavior ES5 version is always used in client project when we build it with rollup or webpack even if we set mainFields to es2015 to take package.json attribute like in previous version.

CJS version is always used in node project even if we want to use module in latest node runtime.

This is due to the exports attribute in package.json which only declares node and default values.

Expected behavior ESM version should be used when client project is built and we are using rxjs with import in javascript or typescript code and we want to build a script compatible with HTML <script type="module"> in HTML

ESM version should be used in node project if in package.json we set type:module attribute and we used it in latest runtime.

Reproduction In a client project,

import { ajax, AjaxConfig, AjaxResponse } from 'rxjs/ajax';
import { Observable } from 'rxjs';

After that, you have to build the client project and you will see that only ES5 version is taken and not ESM version even if we set mainFields to es2015 in webpack or rollup config.

In a Node project,

import { Observable } from 'rxjs';

Build your project and in package.json set type:module and you will see that only CJS version is taken.

Environment

• RxJS version: 7.0.0

Possible Solution

You can see all possibilities here and we have to make a proposition to change package.json:exports attribute

You can see examples in the link provided before and they are explaining how to manage node and module version.

If we don't change the exports attribute, we should allow build system to take the good version we want using main, module or es2015 attributes from package.json like it was possible in previous version especially for client project.

[benlesh]

I'm looking through the solutions here and none of them seem ideal: https://webpack.js.org/guides/package-exports/#target-environment-independent-packages

One thing I know comes up is situations where people are doing instanceof checks. The "stateless" solution for Node seems like it would cause issues. One gotcha is RxJS Observables are often used as a return type from third party packages. Some may use ESM, and other CJS, if that's the future there.

In other news: God, I hate module systems.

[benlesh]

Core Team Meeting: We probably can't act on this during version 7, because it would incur a breaking change for some folks. But we definitely want to move to modern ESM in version 8, probably ES2018+.

[shrinktofit]

Could you add an simple package.json into dist/esm5 with content: { "type": "module" } so Node native ESM system can treat modules under this directory ESM modules?

Another import thing to note: ESM modules under dist/esm5/ use extension-less module specifiers which would not be resolved on neither browser native ESM or Node native ESM.

[kwonoj]

None of published module in rx is native esm so we can't / won't specify separate pkg manifest to esm. Supporting native esm is another topic core team discusses heavily to ensure avoiding potential regressions with ecosystem support, but this specific topic is not intend to make changes to current esm into native one.

[Ronsku]

But we definitely want to move to modern ESM in version 8

Great to hear, looking forwad to RxJS 8! 🥳

[grosch]

Any updates on this? I tried using he 8.0.0-alpha.3 build but I'm still getting this failure when using ESM and trying to import:

import {TestScheduler} from 'rxjs/testing'

SyntaxError: The requested module 'rxjs/testing' does not provide an export named 'TestScheduler'

[Ronsku]

Also looking very much forward to this

[Ronsku]

2 months has passed again, does anyone have any updates, suggestions, workarounds or help?

[devversion]

It seems like, even if you would resolve to the ESM artifacts, the .js files are not considered as ESM because there is no corresponding package.json with type: module. So, either there needs to be a such a file in dist/esmX or the files should use the .mjs extension.

[benlesh]

v8 is going to consolidate on ES2022 and get rid of ES5. That should resolve this issue.

[demensky]

@benlesh, can you provide a link to the ES2022 issue?

I only found mention of ES2021:

Ensure we're publishing only ES2021 or later and CJS. Drop tslib.