Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose native ESM to Node #6643

Closed
demurgos opened this issue Oct 15, 2021 · 1 comment
Closed

Expose native ESM to Node #6643

demurgos opened this issue Oct 15, 2021 · 1 comment

Comments

@demurgos
Copy link

This is a feature request.

RxJS recently added support for package exports. The exports are currently defined like this:

{
  // ...
  "exports": {
    ".": {
      "node": "./dist/cjs/index.js",
      "es2015": "./dist/esm/index.js",
      "default": "./dist/esm5/index.js"
    },
    // ...
    "./package.json": "./package.json"
  }
}

The exports above mean that Node is forced to use the CommonJS version. Would it be possible to allow for native ESM support with something like the following?

{
  // ...
  "exports": {
    ".": {
      "node": {
        "import": "./dist/esm/index.js",
        "default": "./dist/cjs/index.js"
      },
      "es2015": "./dist/esm/index.js",
      "default": "./dist/esm5/index.js"
    },
    // ...
    "./package.json": "./package.json"
  }
}

On the implementation side, it would require to add extensions to relative imports, but it should be simple enough.

The main drawback is that it would expose users to the dual package hazard. RxJS does not have much internal state so it would mostly be about class identity where it would be possible to load two versions of a class (e.g. Observable from both ./dist/cjs/index.js and ./dist/esm/index.js) and where a naive instanceof may fail to detect the right version. My opinion on this is that it is not different from trying to mix Observable from different RxJS versionrs: there may already be a few versions in the node_modules tree, as such the risk is already there.

The upside would be that it would bring the Node and Browser experience closer by having the exact same semantics when using import in Node. It would also be the first step for an eventual deprecation/removal of the CommonJS version in the very far future (reducing the project complexity).

@kwonoj
Copy link
Member

kwonoj commented Oct 15, 2021

Dupe of #4416.

There are internal core team discussions how to land native esm in rxjs with preserving current behavior and that's the reason we don't have native esm output anywhere yet. Please follow original issue, we'll update if we make progress.

@kwonoj kwonoj closed this as completed Oct 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants