You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
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).
The text was updated successfully, but these errors were encountered:
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.
This is a feature request.
RxJS recently added support for package
exports
. The exports are currently defined like this: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?
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 naiveinstanceof
may fail to detect the right version. My opinion on this is that it is not different from trying to mixObservable
from different RxJS versionrs: there may already be a few versions in thenode_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).The text was updated successfully, but these errors were encountered: