Version 7 -> 8 Roadmap

[benlesh]

This issue is outlining what needs to be done in version 7 before we can move to version 8 in earnest.

1. Once ALL items in version 7 are complete, we can consider moving the 8.x branch to master, and create a 7.x` branch.
2. Once ALL items in version 8 are finalized and implemented, we can move from 8.x.x-alpha to 8.x.x-beta.

In Version 7

• groupBy config (feat(groupBy): Support named arguments, support ObservableInputs for duration selector #5679)
• share observable resets (feat(share): use another observable to control resets #6169)
• splitBy (Deprecate partition, add splitBy method that multicasts the source sequence #3807)
• 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 MapTo variants (Deprecating MapTo variants. #6399, PR: chore: deprecate MapTo variants #6860)
• Deprecate retryWhen/repeatWhen? (Deprecate retryWhen and repeatWhen #6859)
• Deprecate onErrorResumeNext operator in favor of onErrorResumeNextWith (feat(onErrorResumeNextWith): renamed onErrorResumeNext and exported from the top level #6755)
• Various selectors/arguments should support ObservableInput
  • delayWhen's notifier (feat(delayWhen): delayWhen's delayDurationSelector should support ObservableInput #7049),
  • buffer's closingNotifier (feat(buffer): closingNotifier should support ObservableInput #7073),
  • distinct's flushes (feat(distinct): flush supports ObservableInput #7081),
  • repeatWhen's notifier (feat(repeatWhen): notifier supports ObservableInput #7103),
  • sample's notifier (feat(sample): notifier supports ObservableInput #7104),
  • retryWhen's notifier (feat(retryWhen): notifier supports ObservableInput #7105),
  • sequenceEqual's compareTo (feat(sequenceEqual): compareTo should support ObservableInput #7102),
  • ShareConfig's resetOnError, resetOnComplete and resetOnRefCountZero (feat(share): ShareConfig factory properties should support ObservableInput #7093),
  • skipUntil's notifier (feat(skipUntil): notifier should support ObservableInput #7091) and
  • window's windowBoundaries (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 source parameters 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 any with unknown. (This could likely be non-breaking, FWIW.)
• productize our internals for creating operators (Productize operator creation internals #6803)
• Implement [Symbol.asyncIterator]() on Observable (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 rxjs as "whole package". (It's not going away, ever, really)
  • Publish @rxjs/observable with just Observable.
  • 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.asyncIterator on observable. (Implement Symbol.asyncIterator on Observable #6779)

[kbrilla]

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

[MaximeBernard]

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.

[PowerKiKi]

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 ? 🤔

[alfaproject]

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

[akakira]

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?

[edwardaskew]

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]

@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) ?

[43081j]

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]

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]

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.

[benlesh]

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.

[benlesh]

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.

[benlesh]

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.