`run-commands` executor uses wrong working directory
JacobLey opened this issue · comments
Current Behavior
When running commands with the run-commands executor by default the working directory is the root.
Often times it is desired to automatically move to the directorying containing the target project automatically. The cwd
option set to {projectRoot}
(options: {"cwd": "{projectRoot}" }
).
From documentation: https://nx.dev/reference/nx-json#outputs
When defining any options or configurations inside of a target default, you may use the {workspaceRoot} and {projectRoot} tokens. This is useful for defining options whose values are paths.
We have three simple projects, foo
, bar
, and baz
.
All have a project.json
which declares a single print-pwd
target, which, you guessed it, prints the working directory.
It does this via the run-commands
executor, and a command of pwd
.
There are no cached results, other targets defined, or dependencies between these projects.
Both the foo
and the bar
project inherit their target definition from a shared nx.json
definition.
The baz
project redefines the target in project.json
(with the exact same options).
Running the following commands results in following output
nx run bar:print-pwd
-
/workspace/packages/bar
-
nx run baz:print-pwd
-
/workspace/packages/baz
-
nx run foo:print-pwd
-
/workspace/packages/bar
- WRONG!
-
The foo project displays a working directory of bar!
Expected Behavior
nx run bar:print-pwd
-
/workspace/packages/bar
-
nx run baz:print-pwd
-
/workspace/packages/baz
-
nx run foo:print-pwd
-
/workspace/packages/foo
-
GitHub Repo
https://github.com/JacobLey/issue-recreator/tree/nx-working-directory
Steps to Reproduce
- Clone example repo (or setup local files according to README)
pnpm i
nx run foo:print-pwd
- Inspect the console output for path to bar package
Nx Report
Node : 22.4.1
OS : linux-arm64
pnpm : 9.5.0
nx (global) : 19.4.3
nx : 19.5.0-canary.20240713-6f50d9f
@nrwl/tao : 19.4.3
Failure Logs
No failure logs, just unexpected behavior
Package Manager Version
pnpm 9.5.0
Operating System
- macOS
- Linux
- Windows
- Other (Please specify)
Additional Information
This appears to be a regression due to 19.5.0-beta.2
.
I am not able to reproduce in 19.4.3
.
I suspect this is because bar is prior to foo alphabetically (bar is just lucky to end up getting itself).
We do not see the issue re-created with baz
who redefines the defintion.
From what I can see, having bar
redefine the target has no impact on this issue.
Thank you for testing the beta. We noticed this as well and merged a fix: #26941 .
Could you try the latest beta please?
Confirm I am no longer able to reproduce on 19.5.0-beta.5
.
Since this was a beta-only regression, I don't think this issue needs to wait until a proper 19.5.0
release.
Thanks!