This PR introduces a new UI in Nx Console designed to assist users with
managing migrations more effectively.
Each migration is now presented with its status and actions, allowing
users to interact directly.
If any issues arise, users can address them in isolation without
disrupting the overall flow. The migrate ui provides a clear overview of
the migration state, helping users track progress and understand what
actions are required at each step.
## Current Behavior
The `convert-to-rspack` generator for `@nx/angular` does not currently
handle SSR Webpack applications correctly.
## Expected Behavior
Ensure that the `convert-to-rspack` generator handles SSR correctly.
## Current Behavior
The `sassImplementation` option for Webpack and Rspack is set to `sass`
by default.
`sass-embedded` offers a faster alternative.
## Expected Behavior
Switch the default `sassImplementation` option to `sass-embedded`.
<!-- 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. -->
## Current Behavior
<!-- This is the behavior we have today -->
This repo uses Nx 20.8.0-rc.0
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses Nx 21.0.0-beta.4
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
… again ourselves
<!-- 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. -->
## Current Behavior
<!-- This is the behavior we have today -->
This article has parts of a youtube video baked into it as mp4 files.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The article points to the youtube video instead of baking in mp4 files.
https://nx-dev-git-fix-docs-nrwl.vercel.app/blog/nx-made-cursor-smarter#lets-see-it-in-action
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- 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. -->
## Current Behavior
<!-- This is the behavior we have today -->
The `registerForcedShutdownCallback` lifecycle hook does not exist if
the TUI is not enabled as it is not on CI. But Nx tries to invoke it
anyways so it causes an error in CI:
https://github.com/nrwl/nx/actions/runs/14471341199/job/40585817051?pr=30710#step:11:31
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The `registerForcedShutdownCallback` is only utilized when the TUI is
enabled so it will not be invoked on CI where it does not exist.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The "Typescript Project Linking" concept page shows package manager
workspaces' patterns like `apps/**`. While this could be correct, it's
not what Nx generators will generate, and it can result in some nested
and non-expected directories being matched (e.g., fixtures).
## Expected Behavior
The "Typescript Project Linking" concept page should show package
manager workspaces' patterns like `apps/*` so it's aligned with what Nx
generators will generate. It would be a safer example, so it doesn't
match potentially undesired directories.
## Related Issue(s)
Fixes #
Currently, we provide `targetDefaults` for atomized targets (e.g.
`e2e-ci`) with a glob pattern that may not match nested paths.
i.e.
```
"e2e-ci--**/*": {
"dependsOn": [
"^build",
],
},
```
The `e2e-ci--**/*` pattern should be `e2e-ci--**/**`.
<!-- 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. -->
## Current Behavior
The generated `e2e-ci` pattern in `nx.json` does not match nested paths
for split tasks.
## Expected Behavior
The generated `e2e-ci` pattern should apply to all split tasks.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#28842
## Current Behavior
The `standaloneConfig` option has long been deprecated as it is the only
behaviour that Nx now provides.
Using it is a no-op.
## Expected Behavior
Remove the `standaloneConfig` option.
## Current Behavior
A couple of unit tests for the `@nx/cypress` graph plugin are failing
due to outdated snapshots.
## Expected Behavior
The `@nx/cypress` graph plugin tests should succeed. The test snapshots
should be updated to match the new behavior.
## Related Issue(s)
Fixes #
<!-- 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. -->
## Current Behavior
<!-- This is the behavior we have today -->
"Printing" the command info before output causes `run-script` to hang
and not run. In addition, the screen was cleared.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The command in run-script runs without issues. The screen is not
cleared.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The Cypress and Playwright graph plugins do not infer tasks configured
to take advantage of continuous tasks (do not add the task they run to
start the app/server as a dependency of the e2e task).
## Expected Behavior
The Cypress and Playwright graph plugins should infer tasks configured
to take advantage of continuous tasks.
## Related Issue(s)
Fixes #
<!-- 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. -->
## Current Behavior
<!-- This is the behavior we have today -->
`git push -u origin HEAD` causes the following panic when the TUI is
enabled on macos:
```
Backtrace (most recent call last):
File "<unknown>:0", in __pthread_cond_wait
File "<unknown>:0", in std::sys::pal::unix:🧵:Thread:🆕:thread_start
File "<unknown>:0", in core::ops::function::FnOnce::call_once{{vtable.shim}}
File "<unknown>:0", in std::sys::backtrace::__rust_begin_short_backtrace
File "<unknown>:0", in tokio::runtime::task::raw::poll
File "<unknown>:0", in tokio::runtime::scheduler::multi_thread::worker::Context::run_task
File "<unknown>:0", in tokio::runtime::task::raw::poll
File "<unknown>:0", in tokio::runtime::task::core::Core<T,S>::poll
File "<unknown>:0", in nx::native::tui::tui::Tui::start::{{closure}}
File "<unknown>:0", in core::option::expect_failed
The application panicked (crashed).
reader source not set
in /Users/jason/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/crossterm-0.29.0/src/event/read.rs:39
thread: tokio-runtime-worker
```
This is due to the fact that crossterm until recently did not use
/dev/tty on mac and thus could not read events correctly when forwarded
from another program such as husky.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This adds the `use-dev-tty` features so that `crossterm` utilizes
`/dev/tty` and works when forwarded from other programs such as husky on
macos.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- 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. -->
## Current Behavior
<!-- This is the behavior we have today -->
Wasm build is broken.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Wasm build is fixed.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- 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. -->
## Current Behavior
<!-- This is the behavior we have today -->
- When a user presses `ctrl+c` to force kill the TUI/Nx, continuous
tasks that are running are not killed, and the terminal can get stuck or
leave the cursor hidden
- The summary is incomplete and messy
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- When a user presses `ctrl+c` to force kill the TUI/Nx, continuous
tasks that are running are appropriately killed and everything in the
user's terminal is restored back to a good state.
- The summary looks good and contains the in progress logs for
continuous tasks that were killed
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- 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. -->
## Current Behavior
<!-- This is the behavior we have today -->
Shared continuous tasks are not shown as running in the TUI
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
There is a special status for Shared continuous tasks for the TUI where
it will say that it is running in a different nx process
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When generating `node` projects with an `e2e` project using Jest, we do
not supply any method for the node application to actually be started
before running the tests.
## Expected Behavior
Using Continuous Tasks, have the e2e project dependOn the serve of the
`node` project such that it is available for the e2e tests to run
against it.
## Current Behavior
When a continuous task is already running, parent tasks are not
scheduled.
## Expected Behavior
When a continuous task is already running, the task orchestrator should
schedule the next tasks and release the waiting threads so parent tasks
can be scheduled.
## Related Issue(s)
Fixes #
<!-- 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. -->
## Current Behavior
<!-- This is the behavior we have today -->
Continuous tasks are not supported in DTE and there is no good API for
Agents to utilize
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
There is an API for agents to utilize to run continuous tasks.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Module Federation Documentation talks about using `--devRemotes`
exclusively for serving remote applications that feature teams are
working on.
With Continuous Tasks this is no longer the case
## Expected Behavior
Add section mentioning Continuous Tasks and the change to the `serve`
flow
## Current Behavior
Continuous tasks are not set up for React Rspack Module Federation
Remote projects.
This is important because `--dev-remotes` is no longer supported with
Crystal Module Federation usage.
## Expected Behavior
Add Continuous Tasks support for React Rspack Module Federation Remote
Projects.
This replaces the need for `nx serve shell --dev-remotes=remote1`.
Instead, the command is simply `nx serve remote1` and continuous tasks
means that the `shell:serve` task is executed correctly.
<!-- 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 is the behavior we have today -->
<!-- This is the behavior we should expect with the changes in this PR
-->
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
<!-- 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. -->
## Current Behavior
<!-- This is the behavior we have today -->
Unit tests are broken after rebase
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Unit tests are passing
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Node applications rely on the `@nx/js:node` executor to handle serving.
Unfortunately, it can not be determined if existing usage of the
executor is used for a continuous or finite task.
## Expected Behavior
Generate new node applications with `continuous: true` for their serve
targets
## Current Behavior
The `@nx/storybook/plugin` does not set `continuous:true` for serve-like
targets.
## Expected Behavior
The plugin should correctly set `continuous: true` for `serve` and
`serve-static`.
## Current Behavior
The `dev`, `serve`, `preview` and `serve-static` targets inferred by the
`@nx/vite/plugin` do not infer `continuous:true` indicating to Nx that
these tasks are continuous.
## Expected Behavior
Infer `continuous: true` for the serve-like targets for Vite.
## Current Behavior
Rspack and Rsbuild Inference Plugins do not infer `continuous` for serve
tasks.
## Expected Behavior
Correctly infer `continuous` true.
## Current Behavior
The `@nx/js` plugin exposes a helper to generate `build-deps` and
`watch-deps` tasks for inference plugins.
It does not currently infer `continuous` for the `watch-deps` task.
## Expected Behavior
Ensure `watch-deps` is infered with `continuous: true`
## Current Behavior
When `serve, dev, start` targets are inferred by the `@nx/remix` plugin,
they are not inferring `continuous`.
## Expected Behavior
When `NX_CONTINUOUS_TASKS_PREVIEW` env var exists, infer the
`continuous` property.
<!-- 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. -->
An RFC about this feature is happening here: #29025. This has the most
information about this feature.
<!-- This is the behavior we have today -->
Nx currently does not explicitly handle tasks which run continuously
until they are terminated.
<!-- This is the behavior we should expect with the changes in this PR
-->
This PR adds the initial support for continuous tasks which run
continuously until they are terminated. This adds the ability to depend
on continuous tasks. There is some more work to be done but this will be
enough as an MVP.
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The `flat/typescript` config contains a config block with the `files`
containing an invalid empty entry.
## Expected Behavior
The `flat/typescript` config should be correct.
## Related Issue(s)
Fixes#30725
<!--
_[Please make sure you have read the submission guidelines before
posting an
PR](https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#submit-pr)_
# Community Plugin Submission
Thanks for submitting your Nx Plugin to our community plugins list. Make
sure to follow these steps to ensure that your PR is approved in a
timely manner.
## Plugin Requirements
Before you submit your plugin to be listed in our registry, it needs to
meet the following requirements:
- Run some kind of automated e2e tests in your repository
- Include `@nx/devkit` as a `dependency` in the plugin's `package.json`
- List a `repository.url` in the plugin's `package.json`
i.e.
```
{
"repository": {
"type": "git",
"url": "https://github.com/nrwl/nx.git",
"directory": "packages/web"
}
}
```
Note: We reserve the right to remove unmaintained plugins from the
registry. If the plugins become maintained again, they can be
resubmitted to the registry.
## Steps to Submit Your Plugin
- Use the following commit message template: `chore(core): nx plugin
submission [PLUGIN_NAME]`
- Update the `community/approved-plugins.json` file with a new entry for
your plugin that includes `name`, `url`, `description`:
Example:
```json
// community/approved-plugins.json
[{
"name": "@community/plugin",
"url": "https://github.com/community/plugin",
"description": "This plugin provides the following capabilities."
}]
```
Once merged, your plugin will be available when running the `nx list`
command, and will also be available in the Plugin Registry on
[nx.dev](https://nx.dev/plugin-registry)
-->
# Community Plugin Submission
## Nx Plugin for AWS (@aws/nx-plugin)
<!--
Describe what your plugin is and what is its goal or issues it
addresses. If you don't provide a description, we will not merge your
PR.
Is it focused on a technology, tooling or behaviour? Does the plugin
provide generators, executors or graph support?
Do you know who is already using the plugin? Mention who is the author
of the plugin.
-->
This plugin is for building cloud-native applications with AWS. At
present it provides the following generators:
- `ts#project` - Generate a new TypeScript library.
- `ts#infra` - Generate a Typescript AWS CDK infrastructure project for
your application.
- `ts#cloudscape-website` - Generate a new Cloudscape/React/Vite based
web application.
- `ts#cloudscape-website#auth` - Add AWS Cognito authentication to your
Cloudscape website.
- `ts#trpc-api` - Generate a tRPC backend service with Amazon API
Gateway/AWS Lambda integration and [AWS
Powertools](https://github.com/aws-powertools/powertools-lambda-typescript)
pre-configured.
- `py#project` - Generate a uv based Python project.
- `py#fast-api` - Generate a FastAPI backend service with [AWS
Powertools](https://github.com/aws-powertools/powertools-lambda-python)
pre-configured.
- `api-connection` - Connect frontend applications to backend APIs.
- `license` - Automatically manage LICENSE files and source code headers
in your workspace.
(Note that the ts/py project generators are our simplified/opinionated
generators for base projects in TypeScript and Python, eg enforcing ESM
for TypeScript etc)
Our prototyping organisation here at AWS uses the plugin to quickly
bootstrap and build prototypes for various AWS customers in different
industries.
The primary authors are Adrian Dimech @agdimech and myself (Jack
Stevenson).
## Current Behavior
Cypress e2e tasks in a workspace with the `customConditions` TypeScript
compiler option set, fail with the error:
```bash
TSError: ⨯ Unable to compile TypeScript:
error TS5098: Option 'customConditions' can only be used when 'moduleResolution' is set to 'node16', 'nodenext', or 'bundler'.
```
This happens because Cypress forces ts-node to use `module: commonjs`
and `moduleResolution: node10`, which is not compatible with the
`customConditions` TypeScript compiler option.
## Expected Behavior
Cypress e2e tasks in a workspace with the `customConditions` TypeScript
compiler option set should work as expected.
## Related Issue(s)
Fixes #
## Current Behavior
The `@nx/rspack` graph plugin reuses the potentially existing
`TS_NODE_COMPILER_OPTIONS` to set the `env` property of the inferred
tasks for a TS config file. This is not correct since the env var could
have a different value (or not exist at all) when running tasks compared
to when the graph plugin runs.
## Expected Behavior
The `@nx/rspack` graph plugin should not reuse any existing
`TS_NODE_COMPILER_OPTIONS` when inferring tasks for a TS config file.
## Related Issue(s)
Fixes #
<!-- 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. -->
## Current Behavior
<!-- This is the behavior we have today -->
currently, the batch process is not being cleanup
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
need to kill the batch process after post run in task orchestrator,
otherwise, when kill it during the post run (store the output to cache),
it will cause the process to hang in DTE
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- 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. -->
## Current Behavior
<!-- This is the behavior we have today -->
This repo uses `20.8.0-beta.2`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses `20.8.0-rc.0`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- 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. -->
## Current Behavior
<!-- This is the behavior we have today -->
When copying the native file out of node_modules into tmp from multiple
processes (aka plugin workers)... this can result in Node deadlocking.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Copying the native file out of node_modules into tmp from multiple
processes will first copy to unique places in `/tmp` but then atomically
rename to the final location where it is still loaded from.
This at least fixes a flaky test in `nx:test` where the explicit
dependencies tests were timing out after 35 seconds
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
