Nrwl Nx and monorepo - handle package.json for particular apps

Question

for a frontend architecture I'm evaluating the usage of monorepo with Nrwl Nx.
I understood from the docs that Nx strongly recommends the single-policy for dependencies (a root package.json with all the dependencies used by the apps and libs).

Today's goal is to find out if there is some solution to use for any reason a different dependency version for a specific application (aka more than one package.json inside the monorepo).

The scenario that I'm trying to analyze is the follow:

root package.json contains
[email protected]

This means that every app will use the version 1.2.2. Everything works fine until the day cursedApp needs to use [email protected].

There's any solution for this? I read the docs and this pattern is discouraged and the only proposal that I've found is to remove the cursedApp from the monorepo.

Thanks! D

Lanell

Answer 1

https://nx.dev/packages/node/executors/webpack#generatepackagejson it says:-

Generates a package.json file with the project's node_module dependencies populated for installing in a container. If a package.json exists in the project's directory, it will be reused with dependencies populated.

Maurreen

link seems to be broken now – Packston

I've done further tests on this topic and also had some workshops with Nx experts. At those days, there aren't any Nx official ways to accomplish the behavior. One of the suggested (and tested by us) workaround is to use npm aliases – Lanell

Answer 2

npm already supports installing multiple versions of the same library. I'm not sure the syntax for yarn but I assume it's similar.

"dependencies": {
   "somelib": "npm:somelib@^1.2.2",
   "somelib2": "npm:somelib@^1.1.9"
}

Once you have two versions installed of the library, then you can modify your tsconfig.json file for a specific project to map somelib imports to somelib2.

This isn't an ideal solution, as sublibraries in node_modules will continue to use somelib. Those will need to be fixed by using a resolitions override in the root package.json folder. Both npm and yarn support such overrides.

I'd refer to the above as a hack to workaround a temporary situation where you expect to revert everything back to using the latest version of somelib asap.

Alternatively, nx does support having all projects in a monorepo as having their own package.json files and their own node_modules. This is the default behavior when converting an existing monorepo into a nx workspace. As it's assumed existing monos work that way.

I'm not sure of how to convert a nx workspace with a root node_modules into projects with their own but I'm sure it's possible. You would probably avoid using the builtin project types and just build everything as a NodeJs project.

Pleasant