Should libraries that depend on rxjs use path-mappings/tree shaking?

👋 This might at first glance seem like an obvious question, but let me explain:

By default in v6 if you import anything it’s going to resolve the files from the project root. e.g. import { Observable } from 'rxjs' is going to come from node_modules/rxjs/Rx.js which re-exports it from node_modules/rxjs/internal/Observable.js.

If a library uses the path-mappings and tree shaking they would use custom resolve overrides. So in that case, Observable would come from node_modules/rxjs/_esm5/index.js which re-exports it from node_modules/rxjs/_esm5/internal/Observable.js. Note the fact that this is inside rxjs/_esm5.

Then let’s say that someone imports my library (e.g. https://redux-observable.js.org) which had done this, but the consumer does not set up their own webpack resolve overrides so they’ll get Observable from node_modules/rxjs/internal/Observable.js and now we have two copies of rxjs in the same project. Observable1 instanceof Observable2 === false. If they use pipeable operators they probably won’t immediately run into errors, if ever, but their bundle size will be silently larger and might later get cases where Observable1 instanceof Observable2 === false, which is quite the hard thing to diagnose for most.

If the library doesn’t use path-mappings, the same problem exists in reverse; if the library consumer do use it, they’ll again get their own copy of RxJS.

---

This was brought up previously when we had rxjs-es (because a redux-observable user hit it) and discussed including the esm5 versions, but I don’t recall a solution ever being found.

Yes, this sucks. AFAIK the only real solution would be have the esm5 version in its own package (or make it the default package and put the other stuff in another). Interestingly, if that was done I think people wouldn’t need to have path-mappings and instead could just alias "rxjs": require.resolve('rxjs-esm5') or whatever it would be called. This could still give you two copies but to me feels like it reduces the likelihood as long as libs set their peerDep correctly.

🔥

[jasonaden]

Yeah, that took a bit of playing with it and a bunch of testing before we were sure it would work. But it’s pretty cool! Probably deserves a blog post somewhere at some point… it’s super useful for libraries.

[jasonaden]

Ah, right. No, it won’t require that. We will to distribute a multiple entry point package.

Take a look at Angular’s common package. The package.json you see in the root is the one you hit when importing from @angular/common. But if you import from @angular/common/http, you’ll get the package.json here. And similarly, you import from @angular/common/http/testing and you’ll get the one [here].

So it will be similar with the rx distribution where there will be multiple package.json files that get distributed, but all will come with a single npm install rxjs.