Closed EelcoLos closed 4 weeks ago
@AgentEnder @juristr is there something wrong at my understanding the Mental Model using external dependencies like dotnet
and inputs
? if so, how should the documentation reflect that?
We'd like to generalize the affected
command in our workflows and not needing to use the exclude parameter to work around this issue. That'd defeat the purpose of this whole setup
I've been able to pinpoint it a little more closely for a more real-life scenario at https://github.com/EelcoLos/nx-tinkering .
So, the main branch has nx 19.5.0 . I installed all the packages and ran npx nx run-many -t build test
on there.
Then i created a branch test-package-lock-dotnet, where I first tried the case above. This already showed the projects api-demo
and api-demo.Test
to be affected.
When running npx nx affected -t build test
at that point (which is https://github.com/EelcoLos/nx-tinkering/pull/2/commits/3416d7d52c0df9148bdfbf27e917f7cb035992a1), the items are affected. However, the cache states there is a local cache hit.
So, upon pointing out a more real life scenario, I updated all npm packages today resulting in https://github.com/EelcoLos/nx-tinkering/pull/2 .
This did trigger the cache to be void, even for api-demo
and api-demo.Test
.
My guess at this point (with some testing of my own) is that affecting dependencies
(not devDependencies
) trigger the cache to be void
I'm also hoping to get to know how to create your own hasher with a plugin. I'd like to create a plugin using a language not using node
as well :)
I'm wondering if this is helping or not: What i'm noticing myself upon starting a new repo with adding @nx-dotnet/core
, is that the package itself depends on @nx/js
. That package is dependant on package.json?
this was solved by @AgentEnder at https://github.com/nx-dotnet/nx-dotnet/issues/861#issuecomment-2254671073
This is something that needs to be fixed on the Nx side of things - you can update nx.json with the below to enable smarter package json handling:
{ "pluginsConfig": { "@nx/js": { "projectsAffectedByDependencyUpdates": "auto" } } }
https://nx.dev/ci/features/affected#marking-projects-affected-by-dependency-updates
Current Behavior
Running
affected
on projects should only have projects affected by the hashing concept stated by https://nx.dev/concepts/mental-model#computation-hashing-and-caching. However, when only changing a trivial item at top level lock files (yarn.lock
/package-lock.json
) seem to change the hash/cache of any project, regardless ofinput
exclusion, or basically anything.EDIT: Although the example will show the trivial part, when actually updating packages, this actually affects the cache Updated a slightly more real example in the comment below: https://github.com/nrwl/nx/issues/26915#issuecomment-2235722706
My tests are solely regarding
dotnet
projects in regards to integrated monorepos.Expected Behavior
I would expect some control to state files not affecting
GitHub Repo
https://github.com/nx-dotnet/nx-dotnet
Steps to Reproduce
yarn install
npx nx show projects
. This will show the a project calleddemo-csharp-models
, which is solely adotnet
project.yarn.lock
file with something trivial like adding a '# test'comment on top of the file ie:npx nx show project --affected
. the projectdemo-csharp-models
is affected. This would be problematic already.inputs
to theprojects.json
atdemo\libs\csharp-models\project.json
:npx nx show project --affected
again. Still, the project is affected.Nx Report
Failure Logs
No response
Package Manager Version
1.22.17
Operating System
Additional Information
This is also the case for NX 18+ and project crystal inferred tasks.
I tried addressing this issue at multiple locations, but no actual solution is provided, not information shared on how to at least gain more insight:
I really like nx and try to advocate for using monorepos at my organization. However, there is a huge use of various platforms and languages. I feel though computation caching for monorepos is a must for my endavour to succeed in my organization