-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nx executes targets out of order when overriding target in project.json
#26929
Comments
This appears to have been introduced in 19.1.1 |
I suspect its caused by this #26033 |
it is actually expected behaviour that dependsOn in project.json overriding the one in nx.json. For the repo, in project.json, for report-impl, since there is no dependsOn specified, it will take that value. So it would consider report-impl does not have any dependencies, hence it runs first. |
Sure, if I specify
Do you have any documentation to support that? I have not seen anything on those lines, and in fact explicitly see the opposite behavior when testing. Omission of a field is exactly what should trigger inheritance, otherwise how is it ever possible to inherit the default? I extended my example repo with trivial ( {
"$schema": "./node_modules/nx/schemas/nx-schema.json",
"cli": { "packageManager": "pnpm" },
"targetDefaults": {
"a": {
"executor": "nx:noop"
},
"b": {
"executor": "nx:noop",
"dependsOn": ["a"]
}
}
} {
"$schema": "../../node_modules/nx/schemas/project-schema.json",
"name": "foo",
"targets": {
"a": {
"executor": "nx:noop"
},
"b": {
"executor": "nx:noop"
}
}
} |
i think the task graph is wrong |
If literally everything (including nothing) overrides the default dependencies, what is the point of having them? I still believe the expected behavior is to inherit
|
I submitted a PR to fix the graph issue: https://github.com/nrwl/nx/pull/28542/files. After merging this PR, the task graph should reflect the order in which tasks are run. The issue with the target in project.json overrides the one in nx.json, not merging these two because the command is different from these two. from logic:
These two are not compatible targets. For compatible targets, both the executor and command have to be the same. Your project.json target looks like:
and nx.json is like:
They have same executor but different command. There are use cases where the commands are completely different (not a simple echo), so merging the options does not make sense.
|
) <!-- Please make sure you have read the submission guidelines before posting an PR --> <!-- https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr --> <!-- Please make sure that your commit message follows our format --> <!-- Example: `fix(nx): must begin with lowercase` --> <!-- If this is a particularly complex change or feature addition, you can request a dedicated Nx release for this pull request branch. Mention someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they will confirm if the PR warrants its own release for testing purposes, and generate it for you if appropriate. --> this pr is a follow up to #26033. for function `createTaskGraph`, it should not accept `defaultDependencyConfigs`, it should be `extraTargetDependencies`. ## Current Behavior <!-- This is the behavior we have today --> this caused an issue where the task graph shows that 2 tasks depend on each other; however, when actually running, it does not. ## Expected Behavior <!-- This is the behavior we should expect with the changes in this PR --> ## Related Issue(s) <!-- Please link the issue being fixed so it gets closed when this is merged. --> Fixes #26929
) <!-- Please make sure you have read the submission guidelines before posting an PR --> <!-- https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr --> <!-- Please make sure that your commit message follows our format --> <!-- Example: `fix(nx): must begin with lowercase` --> <!-- If this is a particularly complex change or feature addition, you can request a dedicated Nx release for this pull request branch. Mention someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they will confirm if the PR warrants its own release for testing purposes, and generate it for you if appropriate. --> this pr is a follow up to #26033. for function `createTaskGraph`, it should not accept `defaultDependencyConfigs`, it should be `extraTargetDependencies`. ## Current Behavior <!-- This is the behavior we have today --> this caused an issue where the task graph shows that 2 tasks depend on each other; however, when actually running, it does not. ## Expected Behavior <!-- This is the behavior we should expect with the changes in this PR --> ## Related Issue(s) <!-- Please link the issue being fixed so it gets closed when this is merged. --> Fixes #26929
This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context. |
Current Behavior
When defining a task graph that has tasks defined in both
nx.json
andproject.json
, it is expected that thedependsOn
is inherited by thenx.json
implemention if not otherwise overridden byproject.json
.In fact, this is consistent with the task graph displayed by
nx graph
.However, when overriding targets in
project.json
, the dependency order is not always respected. This conflicts with the graph which claims it still is.Create two "meta-targets"
build
andtest
. These are simplynx:noop
executors that point to a series of real targets for user convenicence.Building is bound to a single target
build-impl
.Testing is bound to two targets
test-impl
andreport-impl
. These both depend onbuild
being complete.For simplicity, these default implementations are a 1 second wait, then logging their name.
report-impl
is overwritten inproject.json
to just immediately log the name.Inspect the task graph
nx graph
appears to confirm that a test command would:Running
nx run foo:test
actually results in the following logs:The report step is executed immediately, despite the dependency graph claiming otherwise.
Expected Behavior
Running
nx run foo:test
should result in the following logs:GitHub Repo
https://github.com/JacobLey/issue-recreator/tree/nx-task-dependency-order
Steps to Reproduce
pnpm i
nx graph
report-impl
task has bothbuild-imp
andtest-impl
as dependenciesnx run foo:test
REPORT
beforeBUILD
(andTEST
), meaning that it did not properly block on a dependency.Nx Report
Failure Logs
No failure logs, just unexpected execution order. This _can_ easily induce unrelated failure logs, like in the example above trying to execute tests before the build even starts.
Package Manager Version
pnpm 9.5.0
Operating System
Additional Information
I've tried reducing the example case and don't always see it, but definitely experiencing it 10-fold in my live repo.
Attached is image of
nx graph
. While the dependency explanation above may seem a bit unclear, hopefully it is fairly obvious here that a fairly linear execution of tasks is expected here. I agree with the output provided bynx graph
, it is the actual execution ofrun
that is out of order.The text was updated successfully, but these errors were encountered: