Repository navigation
Version 7 -> 8 Roadmap #6367
Description
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.
This issue is outlining what needs to be done in version 7 before we can move to version 8 in earnest.
- Once ALL items in version 7 are complete, we can consider moving the
8.xbranch tomaster, and create a7.x` branch. - Once ALL items in version 8 are finalized and implemented, we can move from
8.x.x-alphato8.x.x-beta.
In Version 7
-
groupByconfig (feat(groupBy): Support named arguments, support ObservableInputs for duration selector #5679) -
shareobservable resets (feat(share): use another observable to control resets #6169) -
splitBy - Add all exports to top level
- More configurable
retry(feat(retry): Add configurable delay #6421) - More configurable
repeat(feat(repeat): now has configurable delay #6640) - Deprecate
MapTovariants (DeprecatingMapTovariants. #6399, PR: chore: deprecate MapTo variants #6860) - Deprecate
retryWhen/repeatWhen? (Deprecate retryWhen and repeatWhen #6859) - Deprecate
onErrorResumeNextoperator in favor ofonErrorResumeNextWith(feat(onErrorResumeNextWith): renamedonErrorResumeNextand exported from the top level #6755) - Various selectors/arguments should support
ObservableInput-
delayWhen'snotifier(feat(delayWhen):delayWhen'sdelayDurationSelectorshould supportObservableInput#7049), -
buffer'sclosingNotifier(feat(buffer): closingNotifier should support ObservableInput #7073), -
distinct'sflushes(feat(distinct):flushsupportsObservableInput#7081), -
repeatWhen'snotifier(feat(repeatWhen):notifiersupportsObservableInput#7103), -
sample'snotifier(feat(sample):notifiersupportsObservableInput#7104), -
retryWhen'snotifier(feat(retryWhen):notifiersupportsObservableInput#7105), -
sequenceEqual'scompareTo(feat(sequenceEqual): compareTo should support ObservableInput #7102), -
ShareConfig'sresetOnError,resetOnCompleteandresetOnRefCountZero(feat(share): ShareConfig factory properties should support ObservableInput #7093), -
skipUntil'snotifier(feat(skipUntil): notifier should support ObservableInput #7091) and -
window'swindowBoundaries(feat(window): windowBoundaries should support ObservableInput #7088)
-
Before Version 8 is released
- Remove all deprecated APIs marked to be removed in v8 or marked deprecated ages ago.
- Remove
sourceparameters from predicates. (Deprecating these via the type system effects problems - see chore: deprecate thisArg signatures #6361.) - Ensure we're publishing only ES2021 or later and CJS. Drop tslib. (ESM version is never used #6321)
- Drop all Internet Explorer support into a pit of flames! 🔥 IE 🔥 🥳
- Idempotent subscription add (feat(Subscription): idempotent add and remove of teardowns #6401)
- Replace all external uses of
anywithunknown. (This could likely be non-breaking, FWIW.) - productize our internals for creating operators (Productize operator creation internals #6803)
- Implement
[Symbol.asyncIterator]()onObservable(TBD. We should try this out in an alpha, at least. Issue: Implement Symbol.asyncIterator on Observable #6857) - Convert repo to monorepo (Monorepo and Splitting Out To Different Packages #6786)
- Docs app can be a separate project under monorepo
- Operator Decision Tree can also likely be its own project under monorepo
- Keep
rxjsas "whole package". (It's not going away, ever, really) - Publish
@rxjs/observablewith justObservable. - Publish
@rxjs/ajax - Publish
@rxjs/fetch - Publish
@rxjs/testing - Decide on how we'll do other packages: Current thoughts are that we could publish a package for each operator, even. Subjects and multicasting might be trickier, but maybe not. Maybe individual packages is right for all. Needs discussion.
- ??? TBD
During Version 8
- Create new schedulers and deprecate old schedulers.
- Implement
Symbol.asyncIteratoron observable. (Implement Symbol.asyncIterator on Observable #6779)
Activity
kbrilla commentedon May 18, 2021
🔥 IE 🔥 🥳 - every time I see that statement in some repo it makes my day better
MaximeBernard commentedon Aug 23, 2021
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,CorrelationIdandContent-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 byrxjs.chore(retryWhen): add dtslint deprecation test
chore: deprecate MapTo variants
chore: deprecate MapTo variants
chore(retryWhen): add dtslint deprecation test
chore: deprecate MapTo variants (#6860)
PowerKiKi commentedon May 10, 2022
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 currentrxjs, then all the code from@rxjs/observablewill 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/operatorsand say@rxjs/operators-map.I could also imagine compatibility issues if one of my dependency depends on an old version of
@rxjs/observableand my app pass one of those object to a new, incompatible version of an operator coming from the latest version ofrxjs. This kind of issue already happened with thegraphqlpackage 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 ? 🤔
alfaproject commentedon Jul 2, 2022
It looks like the items for version 7 are all done except one. Is there any progress? Feels a bit stagnated ):
1 remaining item
edwardaskew commentedon Feb 22, 2023
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 😋PowerKiKi commentedon Dec 21, 2023
@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
lodashandgraphql(for example) ?43081j commentedon Dec 28, 2023
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.
muuvmuuv commentedon Jan 2, 2024
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.
benlesh commentedon Jan 4, 2024
It shouldn't...
rxjsitself 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 onrxjs@7, and some other dep usesrxjs@6, and then you can depend onrxjs@8and you end up with three different versions in your codebase... you're doomed in that scenario even WITHOUT this change.benlesh commentedon Jan 4, 2024
Yes. In order to align with native observables, the change to
subscribeis 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.benlesh commentedon Jan 4, 2024
We can't really do this yet. There are way too many people using RxJS with CJS still. Myself included.
benlesh commentedon Jan 4, 2024
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.
stijns96 commentedon Oct 24, 2024
What is the status of this?
benlesh commentedon Oct 29, 2024
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.
Alex3917 commentedon Oct 29, 2024
@benlesh Is the idea then that version 8 will eventually be released using a polyfilled version of the Web Platform observable?
benlesh commentedon Oct 29, 2024
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.
wolfmanfx commentedon Jan 22, 2026
@benlesh Hi - what is the actual state on rxjs 8 in 2026?
nhattran998 commentedon Jul 26, 2026
Should we use RxJS in 2026 - 2027 (AI era)? I see the team does not maintain it anymore(1 years)
benlesh commentedon Aug 11, 2026
@nhattran998 yes. Do you see something that is desperate need of a new release? If so, bump the PR or issue. Odds are it's probably not an issue, as every time I see one and think "Oh! This looks important!" I realize quickly after I dig in or stop and think about it that the PR or issue either doesn't have merit or it is centralized around a misunderstanding.
At the end of the day, there's only so many ways to mergeMap an Observable :). And the abstractions are so low-level that they don't require security updates very often, if at all.
Most of the pause on RxJS is the result of waiting for the Web Platform Observable to solidify so we can align to it. There is a 9.0.0-beta release at the moment that is targeting that. But I expect that 9 will remain beta for a long time while the platform settles.