DEV Community

Manage Nx library dependencies with the @nx/dependency-checks ESLint rule

Lars Gyrup Brink Nielsen on July 06, 2023

Cover art by DALL-E. Nx 16.4 introduces the @nx/dependency-checks ESLint rule to the @nx/linter package for verifying, adding, removing, and updat...

Read full post

Vitalii Samofal • Sep 9 '23

Nice write up, thank you for so many details.

I have a question about internal dependencies, by default lint --fix generate internal dependency (if library inside the workspace depends on the same workspace) with just wildcard, and wildcard in general are bad practices.

So do you know what is the best way to manage this?

Attaching an example, all with * are just libraries within this workspace

Lars Gyrup Brink Nielsen • Sep 12 '23

Are they buildable or publishable libraries?

Vitalii Samofal • Sep 12 '23

They are both buildable and publishable libraries

eladhaim22 • Sep 18 '23

Same here.

Edouard Maleix • Jan 10 • Edited

Hopefully not too late to the party and your case might relate to my experience...
I had a rather similar case with lib-a being an internal buildable only lib and lib-b, a publishable library depending on lib-a.
So the generated package.json looked rather similar until I changed :

.eslintrc.json in lib-b to

// ...
    {
        "@nx/dependency-checks": [
          "error",
          {
            "buildTargets": [
              "build"
            ],
            "checkMissingDependencies": true,
            "checkObsoleteDependencies": true,
            "checkVersionMismatches": true,
            "includeTransitiveDependencies": true,
            "ignoredDependencies": [
              "<lib-a-import-path>"
            ]
          }
        ]
      }

project.json under lib-b to include "external": "none", in targets.build.options

The resulting package.json does not include lib-a as a dependency anymore but:

it includes lib-a dependencies
the build output of lib-a is included in lib-b bundle

Vitalii Samofal • Jan 10

cool, thank you, didn't know it,

but my case is a bit different, I want it to set a correct version, and in a discord nx team already answered that the only option to do it, is to implement post target hook that will go by each library and update package.json manually before publishing, they said that they are doing the same for nx

Edouard Maleix • Jan 10

Glad you found your answer.
I would be curious to see an implementation of such post target hook, I was not aware that target hooks existed. Do you have an example to share by any chance ?

Vitalii Samofal • Jan 10

Post target is not a hook in nx, they have an open issue to implement it, but what they are doing I guess, is just run one target and then another

github.com/nrwl/nx/blob/master/pac... - full project json

github.com/nrwl/nx/issues/20799 issue with post target, not a big deal, because you can run one by one, and for tasks that need to be run before you can use dependsOn I think

and I didn't finish my implementation yet, I will post once will do it, won't be super hard I hope

Edouard Maleix • Jan 13

Hey, i just came across the tools provided by Nx to manage releases, it seems like one of the sub command could make your day (or night).
nx release version => the doc.
Seems like it can detect publishable libraries and bump them automatically in your package.json.
It did the trick.
If you plan to also publish your packages, you might need to explicitly declare a nx-release-publish target to provide the package root and registry. Just saying, because i did not find this subtle detail’s documentation.

Vitalii Samofal • Jan 13 • Edited

cool, will take a look, I'm already building and publishing them, and updating version in package json, but I do use a library for this,

github.com/bikecoders/ngx-deploy-npm this one works well for me
and this one for version generation and changelog generation github.com/jscutlery/semver

Zeke Sebulino • Aug 10 '23

I have a question, since it was mentioned that this is replacement for the updateBuildableProjectDepsInPackageJson.

updateBuildableProjectDepsInPackageJson - i use this to make sure that the dependencies for my library will be listed on the package.json of that publishable library, now without that option, it won't list the 3rd party package that my library requires.

Diego Juliao • Aug 12 '23

It will not listed automatically for you.
It will luanch a linting error when you run the linting process, you would need to go and write the right version.

A way to automate the dependencies update is using the --fix option.
nx lint YOUR_PROJECT --fix

Greg • Sep 29 '23

Works as a charm ! Thank you.