Quick Fixes for Common Problems

Multiple Versions of RxJS or WebPack

Having multiple versions of RxJS or WebPack in your node_modules can result in hard-to-troubleshoot problems. Example: https://github.com/nrwl/nx/issues/2421.

If you are using the Nx command (e.g., you invoke nx build myproj), even when Nx simply delegates to the Angular CLI, we try to work around the issues, but it’s not a 100% guarantee that they won’t appear. The only guarantee is to have one version of RxJS in node_modules.

1. Make sure your package.json depends on the same version as @nrwl/workspace.
2. If it didn’t help: 2a: If you are using yarn, add the following to your package.json:

"resolutions": {
  "rxjs": "6.4.0" // set to whatever version you want
}

2b: if you are using npm, add the following to your package.json:

"resolutions": {
  "rxjs": "6.4.0" // set to whatever version you want
}

and the following to your devDepencecies:

"npm-force-resolutions": "0.0.3"

And add the following postinstall script:

"scripts": {
  "preinstall": "npx npm-force-resolutions"
}

[edbzn]

@wrslatz The problem is not related to RxJS directly but how NPM/Yarn resolves multiple versions of the same installed package, you can find more details here.

[wrslatz]

Thanks @edbzn! That makes sense from the npm side. I wonder why we run into so many issues with rxjs specifically though (we usually hit tsc compile errors where the types of the two different versions mismatch for the same object, like Observable).

Maybe it has to do with how complex the types in rxjs are. Besides forcing module resolutions, are there any recommended best practices to keep a library you maintain compatible with multiple rxjs versions? Not sure if depenencies vs peerDependencies for rxjs and semver specificity matter.