Standard compliant ES Modules format

[Buslowicz]

Feature Request

RxJS should come in a standard compliant (browser-friendly) ES Modules format.

Describe the solution you'd like
The _esm5 and _esm2015 are close to what we need, but still far from standards. First of all, ES Modules means the browser definitely supports ES6, so no need for esm5 output to be honest.
Next, the _esm2015 format still misses .js file extensions and without them it is impossible for the browser to know what are we trying to load (it works literally as with script src or css link, it needs to point to the exact file, browser will not check for multiple locations as each check has a network latency cost). Furthermore, the _esm2015/internal/Rx.js file has bunch of imports (rxjs-compat) based on Bare Module Specifier (which is strictly a node.js resolution system, not existing in the browser).
In order for the format to be standard compliant, it needs to point to exact file on the server.

Describe alternatives you've considered
So far the only 2 ways of dealing with the issue is to have the server that rewrites the path or bundle the output. As bundling is often a must on production anyway, it is not needed on many development workflows, as it would only slow down the browser reactivity to changes. Path rewrites on-the-fly however work only for custom servers. Some projects use existing tools and writing custom logic just makes more code to maintain, not to mention possible bugs slowing down the development. It would be great to just fetch the file from cdn and not care about further post processing.

This issue has been raised already in #2858 and #3858 but so far both issues are closed and locked as resolved (which is not how it is). Back then browser support for ES Modules could have been lower, but at this moment we have all of the major browsers having a stable implementation enabled by default which gives over 80% of the browsers supporting the feature (node.js also supports it now behind the flag). I really think supporting this format should be a high priority for rxjs.

P.S. Adding module field to package.json would also be a nice addition to the above.

[kwonoj]

Yes, one of issue closed unexpectedly and new issue would be ok to track down further.

It is no doubt we will support native es module, but there are some things need to be resolved including issues you described already. In major, we probably will visit this with upstream support arrives microsoft/TypeScript#16577 , rather than trying to having custom postbuild processing.

[Buslowicz]

The provided issue on TypeScript GH doesn't really bring any hope, quite opposite actually. Is there any chance to push it forward with rxjs itself? If not with this repo, maybe with a separate one (like it used to be with rxjs-es)?

Side note: just thought of how nice (in my personal opinion) would it be to have separate format packages like @reactivex/esm, @reactivex/umd etc :).

[kwonoj]

Rxjs-es was not native module, and from experiences of 5 having separate packages we decided not to separating packages. This is obviously different scope to this issue though.

For supporting es modules, I'd like to understand how urgent this is: yes, major browser supports it, it's capability allows we can support this further. But internal organization of our export / import, and surroundings like compat package is non trivial work to make this happen in real world.

In short,

• what's specific usecases of native module?
• and what prevents to use current module system for those?

As said it is no doubt we will / have to support this eventually but this is sinilar to node side mjs support as well: feature is (somewhat) there, but lacks of toolling and surroundings. If we have strong reason we have to support this in like next major (7) we may need to think how we can do it out of current tooling support, but I am bit doubt about those yet.

[Buslowicz]

Well, the reasoning is dev environment without tools.
With the current state of ES features implemented across modern browsers, projects could be built without any sort of build process which simplifies maintenance by a lot, also reducing number of possible bug sources. Obviously production will heavily benefit from building (due to tree shaking and other code optimizations), but development could be simplified by a lot (even allowing to edit source files directly via chrome dev tools).
Moreover having native modules would allow the use of custom cdn (unpkg sometimes has performance issues).

Current module system aren't native and require 3rd party libraries to make it work. For a project using es modules, the only way for development is to use custom servers (or write additional custom logic for own server if project has one) or use bundlers like webpack, which requires additional configuration and thus consumes project time + makes it more complex/error prone.

I understand many (if not most) projects currently is based on bundlers, but it is because we didn't have native modules before. Now we have them and development cycle will start to change. Having more big libraries (like RxJS) be compatible with it would make the transition faster.

[kwonoj]

but it is because we didn't have native modules before. Now we have them and development cycle will start to change

100% agreed. It's just matter of when. Still, I feel it's bit rough & edgey to make changes right away. All details you mentioned are good, but I doubt you can immediately changes your dev pipeline even if rx ships with es module right away - there are other dependencies doesn't have es module right now that you can't use, isn't it? I agree having some big player will give an acceleration of those trends though.

In short, clarifying, I am not opposed to this implementation itself but I would like to have proper support from upstream & release proper module build doesn't potentially breaking / regresses by having internal tooling to workaround.

[Buslowicz]

As to me, I am currently working on an RxJS based Web Components base class where I am trying to limit the npm dependencies to absolute minimum and try to utilize the browser native api as much as possible (currently got literally 4 folders in node_modules aside of dev dependencies like karma etc). Things will probably grow, but so far everything all I needed was RxJS (1 dep), lit-html (0 deps) and immutable (0 deps) to build a full app. Aside of RxJS, everything works natively in the browser, my custom server fixes paths just for RxJS and I would prefer to not maintain its code :).

I fully understand you prefer to wait a bit, was just hoping anything can be done as a temporary solution. If not, well I guess all we can do is wait.

[Buslowicz]

Hi there, a little update on the TS side of this: microsoft/TypeScript#16577 (comment)
According to a Program Manager of TypeScript they will most likely not implement this, so it's all up for rxjs (and others) to handle this.
If you need more hands on this (either to plan/discuss the functionality or with pure coding), I am here to help, just no rush, I understand this is not a highest priority.

[Buslowicz]

Hi @kwonoj did anything change on your side about the above? I've hit this again as a partial blocker and am wondering how far from resolving it is.

[frehner]

Ah, just ran into this trying to use the ESM version of the build. Seems... weird to have an esm build but not actually have it work? 🤷‍♀

[Buslowicz]

This should really be fixed on rxjs level, typescript will not implement it on their side, and it would be good to have rxjs browser friendly.

[kwonoj]

@frehner minor nit but we never provided native esm, our pkg clarifies it's es-import syntax module only. those 2 are different.

---

I'm keeping an eye on this issue and with node.js's native esm supports without .mjs extension give a few attempts. Unfortunately, until several upstream issues resolved it is not possible to publish our package correctly can be consumed in browser / node.js side.

When issue first created I assume tsc extension issue is only problem but it wasn't - node.js side module property to allow module resolutions, and properly importing esm across our references, make testing work (node.js won't allow native esm module import via require cjs), etcs are all blockers to proceed. That's only coming from quick poc attempts, so maybe there should be more issues coming after even.

Once all these blockers are good to go, we'll make attempt to create major breaking semver with alpha to try out. Sadly, it won't happen soon in current state in my opinion.

[Buslowicz]

That's understandable. Well, fingers crossed to have it fixed as soon as possible, even though it's not going to be soon.

[frehner]

@frehner minor nit but we never provided native esm, our pkg clarifies it's es-import syntax module only. those 2 are different.

Hm, I'm probably reading this wrong then:

Published along with rxjs 5.5 is builds of rxjs in ECMAScript Module format (imports and exports) with both ES5 and ES2015 language level.

But in any case, I understand it may require some work. Thank you for your response.