Open wizardnet972 opened 1 year ago
@wizardnet972 the same problem
@wizardnet972 and when i remove package from node_modules everything works
My package is located in the libs directory, rather than the node_modules directory, so this cannot be the solution.
@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.
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
@SebasG22 you can vote in the @wizardnet972 post to promote the issue
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?
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.
@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.
Took a closer look, and the problem is two-fold:
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.
@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.
@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.
@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
Any update here?
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
:
lib1
only lib1
gets rebuilt even though lib2
and app1
depend on it.app1
then lib2
gets rebuilt, then app1
gets rebuilt.You expect it to work the other way. Where:
lib1
then lib1
gets rebuilt, then lib2
gets rebuilt, then app1
gets rebuilt.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.
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?
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?
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.
@jaysoo any suggestions on how to proceed here?
@jaysoo sorry for the ping - is this a known limitation -- dependencies not being rebuilt?
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?
In the options of the serve target: "runBuildTargetDependencies": true
updated from 18.3.3 to 19.6.3 and got this issue.
Current Behavior
I build a repo
nx-swc
withcli
andutils
swc libs (both buildable).When I change this file in
utils
projectcli
doesn't affect by this change.In the cli I add
serve
executor target (@nrwl/js:node
) and I run ityarn 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
packages/utils/src/lib/utils.ts
and then save the file. you can see the cli doesn't rebuild.-- another scenario --
packages/utils/src/lib/utils.ts
and then save the file.Nx Report