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

[Vitalii Samofal]

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 Playful Programming]

Are they buildable or publishable libraries?

[Vitalii Samofal]

They are both buildable and publishable libraries

[eladhaim22]

Same here.

[Edouard Maleix Playful Programming]

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 :

1. .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>"
            ]
          }
        ]
      }

1. 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]

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 Playful Programming]

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]

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 Playful Programming]

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]

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