Version 7 -> 8 Roadmap

Question

Version 7 -> 8 Roadmap

benlesh opened this issue 4 years ago · 17 comments

Answer 1 · 2021-05-18T20:12:15.000Z

🔥 IE 🔥 🥳 - every time I see that statement in some repo it makes my day better

Answer 2 · 2021-08-23T15:21:46.000Z

Since "??? TBD" seems to imply we can suggest anything, what about #2686?

It seems to be a recurring "issue" people are having to configure headers for every request (most popular seem to be Bearer, CorrelationId and Content-Type).

While it's not "hard" to make your own ajax, I feel it's a bit sad everyone has to write that piece of code and it might be helpful for everyone to have an helper provided by rxjs.

Answer 3 · 2022-05-10T12:51:54.000Z

Wouldn't publishing multiple packages for what is essentially the same code actually increase risk of non tree shakable use-case and thus increase bundle size ?

As seen with lodash, if one of my dependency decides to depends on the future @rxjs/observable, but my app depends on the current rxjs, then all the code from @rxjs/observable will essentially be bundled twice, won't it ?

And of course it would be much worse if we actually publish a package for each operator. Then a single operator could be bundled three times if my deps happened to depend on rxjs, @rxjs/operators and say @rxjs/operators-map.

I could also imagine compatibility issues if one of my dependency depends on an old version of @rxjs/observable and my app pass one of those object to a new, incompatible version of an operator coming from the latest version of rxjs. This kind of issue already happened with the graphql package where they had to add manual check in their code to throw error if it happens.

That seems a lot of tricky tradeoffs to attempt to solve the issue of bundle size that is already properly solved by tree shaking.

Is that really worth it ? 🤔

Answer 4 · 2022-07-02T07:08:20.000Z

It looks like the items for version 7 are all done except one. Is there any progress? Feels a bit stagnated ):

Answer 5 · 2022-09-20T15:19:36.000Z

Do you honestly think this signature change on the subscribe, etc. methods is critical enough to cause billions of lines of code change across the internet?

Answer 6 · 2023-02-22T11:46:15.000Z

You seem to have "Publish @rxjs/fetch" twice. I'm sure it will be an awesome package but it probably only needs to be done once 😋

Answer 7 · 2023-12-21T08:53:32.000Z

@benlesh, it seems development toward v8 is picking up lately. However I am not aware that the concerns expressed in #6367 (comment) and #6786 (comment) have been addressed. And it seems a few persons are sharing those concerns.

Is the plan still to split in multiple, possibly redundant, packages ? What's the team opinion about the pitfalls of such a strategy, as experienced by lodash and graphql (for example) ?

Answer 8 · 2023-12-28T11:01:53.000Z

have you considered 8.x being your first esm-only version of rxjs? seems to me it is the ideal opportunity to do that.

we're now at a point where most consumers are on a version of node which is capable of importing ESM packages, and all popular bundlers are too.

anyone who can only use CJS must be on a fairly old node version, so are likely going to be fine sticking to rxjs 7.x.

there's a few hazards and disadvantages with dual packages (esm + cjs), and the complexity of the build scripts for contributors/maintainers etc.

you mentioned you considered publishing CJS and ESM packages separately, but i wouldn't bother to be honest. many other packages have already moved to pure ESM and consumers managed fine, imo we could do the same here.

Answer 9 · 2024-01-02T15:04:46.000Z

Just tested latest alpha release and these errors appear, is that on purpose? If yes, I would go and open issues on GH for these.

Answer 10 · 2024-01-04T17:20:55.000Z

Wouldn't publishing multiple packages for what is essentially the same code actually increase risk of non tree shakable use-case and thus increase bundle size ?

It shouldn't... rxjs itself will re-export @rxjs/observable, @rxjs/fetch, et al. So there's only really one copy of those dependencies. The only real risk is the same risk we've always had, where a dependency can depend on rxjs@7, and some other dep uses rxjs@6, and then you can depend on rxjs@8 and you end up with three different versions in your codebase... you're doomed in that scenario even WITHOUT this change.

Answer 11 · 2024-01-04T17:21:07.000Z

Do you honestly think this signature change on the subscribe, etc. methods is critical enough to cause billions of lines of code change across the internet?

Yes. In order to align with native observables, the change to subscribe is required to move forward. However, you're wrong that it will "cause billions of lines of code change". Whatever version of RxJS that code is using will still exist. There's very, very little chance of any security issues or reasons to change those old versions, and if there were, we'd just fix it and publish a new 7.x or whatever.

Answer 12 · 2024-01-04T17:23:50.000Z

have you considered 8.x being your first esm-only version of rxjs?

We can't really do this yet. There are way too many people using RxJS with CJS still. Myself included.

Answer 13 · 2024-01-04T17:28:47.000Z

For those of you wondering about the path of different packages for each thing... the primary motivator is around how many libraries choose to use some other, untested, and or cobbled-together observable implementation because they "don't want all of RxJS". This causes us to end up shipping our observables alongside other people's observables in the same bundles, and then it causes developers to need to deal with interop, etc.

Ideally, we can convince developers that want observables to use the most battle tested and common implementation, at least until native observables land.

Answer 14 · 2024-10-24T05:17:20.000Z

What is the status of this?

Answer 15 · 2024-10-29T00:36:53.000Z

Right now, version 8 is on hold because it doesn't make sense to release a new major version of RxJS, then have to write a new major version to match the observable landing in the Web Platform.

Answer 16 · 2024-10-29T01:02:28.000Z

@benlesh Is the idea then that version 8 will eventually be released using a polyfilled version of the Web Platform observable?

Answer 17 · 2024-10-29T01:28:59.000Z

There will be an optional polyfill, or an identical observable to directly import. The RxJS observable will pass all web platform tests as well, and there will be some backwards compat solution.

Version 7 -> 8 Roadmap

NOTE (10/28/2024): RxJS 8 is on hold while observable is being standardized for the web platform. RxJS 8 should match the web platform as much as possible and support it directly. 7.0 is stable, running well, and overall solid.

In Version 7

Before Version 8 is released

During Version 8