The node:execute builder immediately exits after build when --watch=false.

Current Behavior

The node:execute builder immediately exits after build when --watch=false.

Expected Behavior

The node:execute builder wait for the subprocess to exit, or SIGTERM to be received, before exiting. This is how things worked previously.

Steps to Reproduce

npx create-nx-workspace --preset=express
# set app-name to node-test

npm start # works as expected, stays around until you kill it

npm start -- --watch=false # immediately exits after app is started

Failure Logs

Environment

NX Report complete - copy this into the issue template

Node : 16.6.2 OS : darwin x64 pnpm : 6.13.0

nx : Not Found @nrwl/angular : Not Found @nrwl/cli : 12.9.0 @nrwl/cypress : Not Found @nrwl/devkit : Not Found @nrwl/eslint-plugin-nx : 12.9.0 @nrwl/express : 12.9.0 @nrwl/jest : 12.9.0 @nrwl/linter : 12.9.0 @nrwl/nest : Not Found @nrwl/next : Not Found @nrwl/node : 12.9.0 @nrwl/nx-cloud : Not Found @nrwl/react : Not Found @nrwl/schematics : Not Found @nrwl/tao : 12.9.0 @nrwl/web : Not Found @nrwl/workspace : 12.9.0 @nrwl/storybook : Not Found @nrwl/gatsby : Not Found typescript : 4.3.5

[nartc]

@dpchamps I think it’s complex enough to warrant a separate issue with a clear use-case and explanation. I personally don’t truly understand the use-case just yet so it’s hard for mecto respond responsibly (I’ll follow up with Jack internally to see if he has any idea). That said, please feel free to open a new issue (and feel free to reference as many issues/PRs as you can in the new issue) and we’ll track that as a feature request. Sounds good?

[AgentEnder]

@dpchamps @llwt Hey! Sorry for letting this linger so long, lets discuss this a bit and see what we think would be the best path forward.

For some additional context, we are in the middle of moving a ton of logic out of @nrwl/node and @nrwl/workspace and into @nrwl/js. Part of this move will involve the executors from @nrwl/node being moved into @nrwl/js, and the build logic being rethought to introduce potential support for other tooling like SWC.

I agree with @FrozenPandaz’s thoughts in the PR, that the solution there seems overly complex for the description of the issue. The second code suggestion provided by @llwt seems much more lightweight, though it doesn’t emit all subprocess events I’d argue that the executor doesn’t need to do so… If you want that much control its probably best to write a minimal custom executor. I do agree that the current executor shouldn’t exit until the subprocess concludes, and that’s a much simpler problem to tackle.

Thoughts? I’m about to be on leave for the next 6 weeks, so I’m going to pull @nartc in on this discussion too, more perspectives shouldn’t hurt 😄.