A way to require a chain of targets a-la NPM pre- post- scripts
See original GitHub issueDisclaimer
If you think this idea isn’t entirely bananas, I’m willing to take my chances and start working on it. Albeit my time is scarce (young kid to raise) and also I don’t know if I’m just good enough 😃
Description
I’d like to have a way, maybe a property in workspace.json
- to declare targets that must run before or after the current target.
Something similar to what you can have for NPM scripts, or CI pipelines.
Motivation
I can write about why I need it:
Every app in my monorepo needs an autogenerated file to be present when it builds (both in dev and in prod, whenever it builds). The file is imported, so the build fails if it’s not present. And the values in the file need to be freshly minted every time.
So I added a new target using the @nrwl/workspace:run-commands
builder and I run the target every time via a prestart
npm script + a step in the CI pipeline.
This is uglier and less robust than it could be.
@ferdiemmen in the community Slack channel suggested I’d do something like this:
"build": {
"builder": "@nrwl/workspace:run-commands",
"options": {
"commands": [
"nx run app:do-this-first",
"nx run app:build-app"
],
"parallel": false
}
},
"do-this-first": {
"builder": "@nrwl/workspace:run-commands",
"options": {
"commands": [
"node prepare-my-build"
]
}
},
"build-app": {
"builder": "@angular-builders/custom-webpack:browser",
...
}
This can work, but it’s still a workaround 😃
Suggested Implementation
I imagine this could be declared in workspace.json
like this:
"anyTarget": {
"needs": "myApp:myOtherTarget",
"builder": "@nrwl/no-really-any-builder-should-have-this",
"options": {},
"configurations": {}
}
And whenever I run nx myApp:anyTarget
, nx would run myApp:myOtherTarget
first.
Alternate Implementations
Future implementations could:
- Allow for depending on targets from any other app / lib
- Allow for passing options / parameters to the dep targets
Issue Analytics
- State:
- Created 3 years ago
- Reactions:7
- Comments:5 (2 by maintainers)
so indeed dependsOn provides the ‘pre’ part. What about ‘post’ part? Is that going to be handled somehow? (‘runAfter’? 😃 )
It would be nice to have a runAfter so that we don’t have to coddle together a bunch of targets and then a fake build target.