feat(core): allow globs in project config to extend atomized targets#30630
Merged
feat(core): allow globs in project config to extend atomized targets#30630
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 1 Skipped Deployment
|
Contributor
|
View your CI Pipeline Execution ↗ for commit 12c74be.
☁️ Nx Cloud last updated this comment at |
AgentEnder
approved these changes
Apr 9, 2025
Contributor
|
This pull request has already been merged/closed. If you experience issues related to these changes, please open a new issue referencing this pull request. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TL;DR;
This PR enabled mapping glob patterns in target names within the project config to match and extend atomized targets.
Problem statement
The project configuration (via project.json or package.json) enables us to override target defaults set via inferred plugins and/or targetDefaults.
However, this is only possible for fixed targets. Overriding atomized/dynamic targets would require listing them all explicitly, which would create a lot of overhead and would break the dynamicity and automation of the atomized targets.
Why not use targetDefaults?
The targetDefaults already support globbing to match a range of targets like e2e-ci-**/* so we can use the same logic on the project level.
We often need to make modifications on project level, rather than the entire monorepo. E.g. all atomized targets running on a feature lib checkout should have an implicit dependency on build target of dependency as stated by "dependsOn": ["^build"] but they also should have a dependency on app:build - the application which e2e tests are serving, although there is no direct or indirect dependency between checkout-e2e and app. This is significant to retain the lean affected graph.
Solution
We can use the same globbing logic from targetDefaults and will apply in mergeProjectConfigurationIntoRootMap function to match glob patterns to range of targets instead of searching for the explicit target name only.
When the glob pattern doesn't match any targets, the fallback is still the existing functionality.
This is possible given the fact that plugins' targets get applied before we start parsing the project configurations, as they have priority over generic plugin definitions and
targetDefaults.Override would look like this:
{ "name": "users-e2e", "implicitDependencies": ["users"], "targets": { "e2e": { "dependsOn": ["^build", { "target": "build", "projects": "app" }] }, "e2e-ci--**/*": { "dependsOn": ["^build", { "target": "build", "projects": "app" }] } } }Current Behavior
Expected Behavior
Related Issue(s)
Fixes #