nx doesn't build the deps projects when they change

[wizardnet972]

trafficstars

Current Behavior

I build a repo nx-swc with cli and utils swc libs (both buildable).

When I change this file in utils project cli doesn't affect by this change.

In the cli I add serve executor target (@nrwl/js:node) and I run it yarn nx serve cli, when I change the file in utils the cli not build again.

The cli is depended on utils by this import I would expect from nx to know that dependency has changed.

Expected Behavior

When repo dependency change, should rebuild the project.

GitHub Repo

https://github.com/wizardnet972/nx-swc

Steps to Reproduce

1. clone the project.
2. run yarn install
3. run yarn nx serve cli
4. make some change in packages/utils/src/lib/utils.ts and then save the file. you can see the cli doesn't rebuild.

-- another scenario --

1. run yarn nx run-many --target build --all
2. run yarn nx serve cli
3. check for the console
4. change the output of the console in packages/utils/src/lib/utils.ts and then save the file.
5. run yarn nx serve cli again and you can see that nothing change.

Nx Report

>  NX   Report complete - copy this into the issue template

   Node : 18.13.0
   OS   : darwin arm64
   npm  : 9.3.0

   nx                      : 15.7.2
   @nrwl/jest              : 15.7.2
   @nrwl/linter            : 15.7.2
   @nrwl/workspace         : 15.7.2
   @nrwl/cli               : 15.7.2
   @nrwl/devkit            : 15.7.2
   @nrwl/eslint-plugin-nx  : 15.7.2
   @nrwl/js                : 15.7.2
   @nrwl/tao               : 15.7.2
   typescript              : 4.8.4

✨  Done in 0.97s.

### Failure Logs

_No response_

### Additional Information

_No response_

[owl-app]

@wizardnet972 the same problem

[pawelkeska]

@wizardnet972 and when i remove package from node_modules everything works

[wizardnet972]

My package is located in the libs directory, rather than the node_modules directory, so this cannot be the solution.

[jon9090]

@FrozenPandaz I am encountering the same issue where Nx fails to rebuild the package even when its library dependencies have changed.

This poses a challenge for utilizing Nx with interconnected multiple packages. This problem is of utmost importance for anyone utilizing Nx.

[SebasG22]

I'm getting the same error on the latest version. It's weird because this was working in previous versions and now the most simple example does not work.

Also, this can be related to #16030.

Any help would be greatly appreciated. @FrozenPandaz @AgentEnder @mandarini

[jon9090]

@SebasG22 you can vote in the @wizardnet972 post to promote the issue

[wizardnet972]

I am encountering an issue where projects that were upgraded to v15.9.2 are experiencing the same problem, as the application fails to re-run after changes are made in the library (node/express). This has resulted in a significant amount of work and frustration. I am curious if this issue is present in other projects as well. @FrozenPandaz @AgentEnder Could you kindly offer your perspective on this matter? Are you familiar with it?

[ikosta]

Yeah... just tried to upgrade from 15.8.5 to 15.9.2 and the build fails. If there are dependencies between two @nrwl:js libs, the lib that depends on the other can't be build: error TS6059: File '/nx/libs/auth/src/index.ts' is not under 'rootDir' 'libs/core-events'. 'rootDir' is expected to contain all source files.

[jaysoo]

@ikosta Can you open a new issue to track that, with a reproduction repo? It's a separate issue.

It looks like file change events are not working for dependencies, which is why the process is not reloaded. We'll look into this.

[jaysoo]

Took a closer look, and the problem is two-fold:

1. File change events are not watching for changes in dependencies (as noted above).
2. When running re-compiling the parent project (cli in the example), dependencies are not re-compiled.

(1) is a relatively simple fix if we ask the Nx daemon to also notify on dependency changes. (2) needs some work to make sure the dependency is also built during watch.

[wizardnet972]

@jaysoo, I greatly appreciate your efforts in looking into this matter. I was wondering if the issue I reported at https://github.com/nrwl/nx/issues/16530 is connected to the current problem we are facing. My suspicion stems from the way nx handles dependency resolution.

[jaysoo]

@wizardnet972 Thats' a different issue. This issue is about the watch mode not rebuilding dependencies and re-launching the process. I'll take a look at the other issue.

[wizardnet972]

@jaysoo Could you please suggest a possible solution for this issue? Additionally, I would appreciate it if you could provide an update on when the resolution is expected

[alxrodav]

Any update here?

[AshHeskes]

I'm seeing this too. It seems the logical order of how commands are ran is backwards from expectation..

e.g. for a project like:

+ app1
+ lib1
+ lib2

Where:

• app1 depends on lib2 and lib1
• lib2 depends on lib1.

Then starting e.g. nx watch --all -- nx run \$NX_PROJECT_NAME:build:

• If you change lib1 only lib1 gets rebuilt even though lib2 and app1 depend on it.
• If you then change app1 then lib2 gets rebuilt, then app1 gets rebuilt.

You expect it to work the other way. Where:

• If you change lib1 then lib1 gets rebuilt, then lib2 gets rebuilt, then app1 gets rebuilt.
• if you then change app1 then only app1 gets rebuilt as nothing depends on it.

In other words the current behaviour seems to run commands on a fan in basis, where people expect it to fan out.

[bobalazek]

I have started experiencing the same issue. For me it seem to have worked fine in v16.5.0, but when I upgraded to v16.7.2 it stopped working. Any solutions for that, besides a downgrade?

[biz812]

We have also begun to experience this issue, like the previous post we went from v16.5.4 to v16.7.4. This issue has been open since well before the release of 16.5.x but we haven't experienced it until now... I wonder if this is a regression somewhere?

[a-c-m]

I'm not sure if I don't have things configured correctly or if this bug is still present in 17.1.3 ?

I seem to be able to have app depend on the build of lib1, but when i change lib1, its not re-triggering the build of lib1.

[erikshestopal]

@jaysoo any suggestions on how to proceed here?

[erikshestopal]

@jaysoo sorry for the ping - is this a known limitation -- dependencies not being rebuilt?

[jonlambert]

Apologies for the ping too, but this is a huge issue to encounter after dedicating time to moving to Nx. I'm noticing this specifically in a release process – when a dependency is updated, I would hope that the dependant would have the new version referenced and be rebuilt/released too?

I thought this was something we were doing wrong with configuration. Is there any acknowledgement of this issue?

[jellebrouwer]

In the options of the serve target: "runBuildTargetDependencies": true

[noelsoong]

updated from 18.3.3 to 19.6.3 and got this issue.

[yossiyedid]

same here, any updates?

[net]

Turborepo doesn't have this issue. I'd like to use Nx, but this bug is a blocker to doing so.

[github-actions[bot]]

This issue has been automatically marked as stale because it hasn't had any activity for 6 months. Many things may have changed within this time. The issue may have already been fixed or it may not be relevant anymore. If at this point, this is still an issue, please respond with updated information. It will be closed in 21 days if no further activity occurs. Thanks for being a part of the Nx community! 🙏

[net]

As far as I'm aware nothing has been done to fix this. Would love to find out I'm wrong.

[monabbous]

I have resolved this

tldr; the fix:

create a file nx.js in your root of your workspace

// DO NOT EDIT THIS FILE !!
// this file is to correct the error when running serve target of "@nx/js:node" where
// it doesn't run the build executor 

const { execSync } = require('child_process');

execSync(`nx ${process.argv.slice(2).join(' ')}`, {
  stdio: 'inherit',
  env: {
    ...process.env,
    NX_CLI_SET: 'true',
  },
});

note that I have nx command installed globally, you may need to do so or replace nx with how you run your targets

Explanation, please fix this nx team

The problem is to do with the way that js:node is running the build executor. within the code that is running the build executor, it is calling the nx command as such

fork([require.resolve('nx'), '<build target>', '<build target options>'])

require.resolve('nx') is expected to resolve the binary file nx.js to execute the command, but since now new projects has the nx.json file in the root level of the workspace, due to how the precedence order of the resolve function work it would resolve this command as:

node nx.json <build target> <build target options>

I'm not sure what is the best way to resolve this by the team, but maybe by using something other than the resolve.require.

I hope this helps.

chears