fix(js): add watchIgnore and runBuildTargetDependencies options to speed up build

[jaysoo]

This PR addresses the slowness issues introduced when we updated the Node executor. Two additional options have been added.

1. watchIgnore - A list of glob patterns to skip rebuilds (when the only changed files are ignored).
2. watchRunBuildTargetDependencies - When set to true, the rebuild will rerun dependency tasks. Default is false.

(1) lets users ignore files they know cannot affect the application. The alternative is to add to .gitignore or .nxignore, but this provides more granular control that is specific to the application.

Instead of (1), users should add files to their .nxignore.

(2) is for advanced usage where the application may not be bundled (thus dependencies must be rebuilt).

Current Behavior

Node executor is slow for everyone.

Expected Behavior

Node executor is fast for the normal use cases, with and advanced option to opt-into the slower but more correct build behavior (rerunning all dependency targets).

Related Issue(s)

Fixes #17070

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
nx-dev	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jul 5, 2023 5:59pm

[nx-cloud]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit 9feff76. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this branch

---

✅ Successfully ran 1 target

• nx affected -t e2e-macos --parallel=1 --base=8c9ad0da69b76def41ef1af615d0795272a0b78f --head=9feff76feefdf1f3d81de791ea68f0b7fef78983

---

Sent with 💌 from NxCloud.

[ndcunningham]

What if we have

• watchIgnore: 'libs/my-lib'
• watchRunBuildTargetDependencies: true
• my-lib is a dependency of the app and I make changes to my app.

Is there a preference since both options can affect the same file?

[kurt-west]

Personally, I think part of the perceived slowness is that the executor now eats the compilation logs. Previously, the user would see the webpack output so they knew it was working, now it just sits there without any feedback until it boots or fails. It would be convenient to have the output from the build task be written to the logger so the user can see what's actually being build/rebuilt.

With the ignore option, it would be nice to have a flag to write the output of the watcher to the console to see what triggered the rebuild.

Edit:
Thank you for your support in resolving this issue.

[urugator]

eats the compilation log

I also use to put console.logs directly to configuration files like webpack.config.js for debugging purposes - knowing whether it's even being used, what env vars it sees, what's already configured and how, plugins, etc...

[jaysoo]

What if we have

• watchIgnore: 'libs/my-lib'
• watchRunBuildTargetDependencies: true
• my-lib is a dependency of the app and I make changes to my app.

Is there a preference since both options can affect the same file?

The build for my-lib will still happen. The watchIgnore option is controlling whether the event triggers in the first place, and the latter controls whether the re-run task dependencies after the event is triggered.

[github-actions]

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.