Nx: Using different versions of a lib or a package

[raczroland]

I want to start my next Angular project using Nrwl Nx, because I need to write multiple apps for one client. But:

1. I read this: 'An upgrade to a lib requires a change to all implementors.' Is there any solution (bypass) to use different versions of a lib or an NPM package in different apps? There is only one node_modules, but this is critical for my apps.

2. How can I specify different version numbers for the different apps? Usually I give a version number in package.json, but with Nx there are only one package.json for all of my apps. Should I put it in the environment files? Or in the .angular-cli.json file? I want to display the version number for the users in my apps somewhere.

I know, I should ask these questions on StackOverflow, but they want to close it, and I don't know where to ask it.

Thank you.

[ThomasBurleson]

@raczroland - IMO, these are good questions that we should document in a Wiki.

[noelmace]

I'm currently testing the use of lerna to address this, given that I should also use ng-packagr in order to permit to publish and use some libraries outside our Nx monorepository. You should be able to also use yarn worspaces for that.
Linking : https://github.com/nrwl/nx/issues/87

[raczroland]

@noelmace: First of all, thank you for your comment. I checked that issue (lerna, workspaces) and followed this article too but still not sure how to use multiple versions of a package for different apps in one repo, if I want to use Nx too. Do you have any advice? Any results with your testing?

[noelmace]

@raczroland You're welcome.

In fact, after a lot of tests, both with lerna and workspaces, my conclusion is that we don't need such tools, even if we have package.json files for the libs we build with ng-packagr and publish on our npm repository.

Here is why : lerna is, in my opinion, thinked as a tools to manage different projects in a monorepository, namely with each project having is own build process and dependencies. Given such, it will create a node_modules for each workspace. This is why it is logical with lerna to have diferent dependency versions : each project could be used in a entirely different way than the others. I now think using it with Nx doesn't make sense, since Nx provide all the tools we need to have a consistent build system for every workspace.

On the other side, yarn workspaces is only a solution wich aim to manage different dependencies in a coherent way. Using it with Nx is relevant if you also use ng-packagr and have different dependencies between your projects, but there is a big cons to this : Angular don't support having two different versions of angular definitions in the same compilation.

With all this stuff in mind, I ran into a much more simple solution : as we only use libs/*/package.json to manage the ng-packagr build process, and as we want coherent dependencies versions in our monorepo, we add dependencies and peerDependencies for our libs in this package.json files, and then add them to the root package.json file, wich is used by the build process (namely Nx and some node scripts). As we use a specific node script to build and publish this specific libs, we also test that every dependency and peerDependency in this package.json files is coherent with the ones in the root package.json file before the build, and throw an exception if not.

Given the amont of work on this, I will look deeper in Nx and see if this could lead to some PRs. @vsavkin (and others), any guidance / opinion on this would be really appreciate.

[noelmace]

FYI @raczroland the "specific node script" I mentionned is now available, and you can see wath I talked about when I said "we also test that every dependency and peerDependency in this package.json files is coherent with the ones in the root package.json file before the build, and throw an exception if not." here : https://github.com/noelmace/packagr-for-nx/blob/v0.2.0/src/libs.js#L56

[brunano21]

@noelmace @vsavkin @jschwarty Hi, I have a similar question on this topic. I have posted it on ng-packagr here in order to understand what's the best strategy. Would you mind to give your inputs, please?

[jpremkumar]

Any update or workaround for having a separate package.json for apps?

[vsavkin]

Folks, I'm going to close this issue.

We strongly discourage your having multiple versions of package.json for your packages. Single-version policy, although comes with its own problems, is one of the reasons why monorepos provide the benefits they provide.

Both npm and yarn allow you to use multiple versions of the same library. It can be useful in rare situations. It works with Nx.

You could also use Lerna or Yarn Workspaces in combination with Nx if you have to.