Eliminate @reactivex/rxjs?

[benlesh]

Currently we release two packages:

• @reactivex/rxjs
• rxjs

Right now, the vast, vast majority of users are using rxjs, not @reactivex/rxjs. The major difference between the two used to be that the @reactivex/rxjs one had more builds in it and the original source... however as of 5.5, we have all module build styles in rxjs to support bundlers, and we have the src to support source maps. So they're effectively not that much different anymore.

Should we deprecate @reactivex/rxjs in favor of rxjs?

[kwonoj]

do not forget we have rxjs-es too: #2218

I'm voting to deprecate except main one.

[cartant]

This is kinda related to #2913. That issue mentions package size as a motivator. Something to consider is that if you are going in the direction of multiple, related packages, having them all under the @reactivex scope might have some advantages.

[rgbkrk]

With all the build styles available in the rxjs name, I'm in favor of deprecating @reactivex/rxjs. It's what I use today and teach others to use.

[benlesh]

We want to do deprecate @reactivex/rxjs still. We can do that once the publishing/build changes land.

[benlesh]

cc @kwonoj can you link your build-related PR to this?

[kwonoj]

#5032

[kwonoj]

I'm hoisting this as agenda item to check status quo before closing.

[benlesh]

Core Team Meeting:

• We still need to support this for version 6.x.
• We could change the NPM package README.md for just @reactivex/rxjs to have some big "deprecated" message.
• Optionally: Add Core-JS post install message to the package, so people stop wanting to use it - @kolodny
• We can probably just ignore this, as hardly anyone uses it, and there's no real documentation around using it.