<!-- 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 -->
wasm build is broken, blocking releases.
<!-- This is the behavior we should expect with the changes in this PR
-->
wasm build is not broken.
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit d47d41cd53)
<!-- 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 help tooltip for an example using `args` is misleading. It states
that `args` are CLI positional arguments, but they can also be CLI
flags.
Additionally, the fallback example shows an example using `options`,
which has a few caveats.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The help tooltip for an example using `args` should state that `args`
are CLI flags or positional arguments.
The fallback example should show only an example using `args` to reduce
the likelihood of users bumping into any of the caveats of using
`options`, which could be frustrating.
Note: a separate change to the docs will be made to explicitly call out
these caveats. Users would still be able to use `options`, but it
shouldn't be the recommended way of providing args unless they are well
aware of the caveats.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit 27b8649f5c)
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Newly generated `ci-workflow` setups should use the latest GH package +
v9 PNPM version
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit 1a4e663c5f)
<!-- 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 -->
There is a race condition in the `@nx/eslint/plugin` causing projects to
be missing lint.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The `@nx/eslint/plugin` creates a map of lintable files up front before
analyzing any particular project and there is no race condition.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit 035b40620b)
<!-- 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
- Nonexistant outputs are considered globs
- Glob outputs are walked from workspace root, which is slow on large
repos
[NX Daemon Server] - 2024-09-06T19:44:39.674Z - Done responding to the
client outputsHashesMatch
[NX Daemon Server] - 2024-09-06T19:44:39.674Z - Handled
OUTPUTS_HASHES_MATCH. Handling time: 94. Response time: 0.
[NX Daemon Server] - 2024-09-06T19:44:39.775Z - [REQUEST]: Responding to
the client. recordOutputsHash
[NX Daemon Server] - 2024-09-06T19:44:39.775Z - Done responding to the
client recordOutputsHash
[NX Daemon Server] - 2024-09-06T19:44:39.775Z - Handled
RECORD_OUTPUTS_HASH. Handling time: 100. Response time: 0.
[NX Daemon Server] - 2024-09-06T19:44:39.818Z - [REQUEST]: Responding to
the client. PROCESS_IN_BACKGROUND
[NX Daemon Server] - 2024-09-06T19:44:39.818Z - Done responding to the
client PROCESS_IN_BACKGROUND
[NX Daemon Server] - 2024-09-06T19:44:39.818Z - Handled
PROCESS_IN_BACKGROUND. Handling time: 14. Response time: 0.
## Expected Behavior
- Nonexistant outputs are only globs if they should be
- Globs are a bit faster
[NX Daemon Server] - 2024-09-06T19:43:36.899Z - Handled
OUTPUTS_HASHES_MATCH. Handling time: 0. Response time: 0.
[NX Daemon Server] - 2024-09-06T19:43:36.900Z - [REQUEST]: Responding to
the client. recordOutputsHash
[NX Daemon Server] - 2024-09-06T19:43:36.900Z - Done responding to the
client recordOutputsHash
[NX Daemon Server] - 2024-09-06T19:43:36.900Z - Handled
RECORD_OUTPUTS_HASH. Handling time: 0. Response time: 0.
[NX Daemon Server] - 2024-09-06T19:43:36.944Z - [REQUEST]: Responding to
the client. PROCESS_IN_BACKGROUND
[NX Daemon Server] - 2024-09-06T19:43:36.944Z - Done responding to the
client PROCESS_IN_BACKGROUND
[NX Daemon Server] - 2024-09-06T19:43:36.944Z - Handled
PROCESS_IN_BACKGROUND. Handling time: 13. Response time: 0.
[NX Daemon Server] - 2024-09-06T19:43:36.949Z - Uploading file artifacts
[NX Daemon Server] - 2024-09-06T19:43:36.949Z - Done uploading file
artifacts
> Note timings are from Nx repo, close enough to be comparable. No real
improvement was expected here, mainly checking that things didn't get
worse.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: FrozenPandaz <jasonjean1993@gmail.com>
(cherry picked from commit ac9da418bd)
It updates the link to Bill's website and adds the Amplify icon to the nx-dev site for better clarity and branding.
(cherry picked from commit d0293b28c0)
- Add a new flag `--skipSync` to the run commands to skip running
syncing when running tasks.
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
<!-- Fixes NXC-946 -->
Fixes #
(cherry picked from commit ccda7f9f00)
This PR updates the tsconfig paths plugin for Vite such that it resolves
paths with file extensions as well.
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#22868
(cherry picked from commit eb7ac2c57a)
- fix(module-federation): SSR should work correctly
- fix(module-federation): ssr-dev-servers should wait for remotes before
starting final executor
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit f17e5efc08)
It updates the animations to make them more performant, using variaous techniques to reduce the number of renders.
(cherry picked from commit e516fd12d7)
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit 963a1c5621)
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: FrozenPandaz <jasonjean1993@gmail.com>
(cherry picked from commit c4c8b0150d)
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- 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>
(cherry picked from commit c30415e892)
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit d46edc4ff2)
<!-- 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 -->
With plugin isolation turned on, it works on CI but doesn't on slow
laptops due to corporate software.
We currently run nx with the following patch to figure out why it happen
:
```patch
diff --git a/src/project-graph/plugins/isolation/plugin-pool.js b/src/project-graph/plugins/isolation/plugin-pool.js
index b10ee0d28c994db4e39c4f650dd47496c22cdb60..5a4dfb015906de8a0f9028e09140c6a3f543ca28 100644
--- a/src/project-graph/plugins/isolation/plugin-pool.js
+++ b/src/project-graph/plugins/isolation/plugin-pool.js
@@ -266,6 +266,7 @@ async function startPluginWorker() {
const id = setInterval(async () => {
const socket = await isServerAvailable(ipcPath);
if (socket) {
+ console.log('Managed to start the worker after', attempts, 'attempts.')
socket.unref();
clearInterval(id);
resolve({
@@ -273,10 +274,10 @@ async function startPluginWorker() {
socket,
});
}
- else if (attempts > 1000) {
+ else if (attempts > 10000) {
// daemon fails to start, the process probably exited
// we print the logs and exit the client
- reject('Failed to start plugin worker.');
+ reject('Failed to start plugin worker after ' + attempts + ' attempts.');
}
else {
attempts++;
```
With the added logging, we can see the following:
On ci (nx agents, or circleci)
```
Managed to start the worker after 17 attempts.
Managed to start the worker after 20 attempts.
Managed to start the worker after 23 attempts.
Managed to start the worker after 26 attempts.
Managed to start the worker after 27 attempts.
Managed to start the worker after 27 attempts.
Managed to start the worker after 28 attempts.
Managed to start the worker after 39 attempts.
Managed to start the worker after 47 attempts.
Managed to start the worker after 34 attempts.
Managed to start the worker after 36 attempts.
Managed to start the worker after 40 attempts.
Managed to start the worker after 47 attempts.
Managed to start the worker after 52 attempts.
Managed to start the worker after 54 attempts.
Managed to start the worker after 54 attempts.
Managed to start the worker after 55 attempts.
Managed to start the worker after 41 attempts.
Managed to start the worker after 53 attempts.
Managed to start the worker after 59 attempts.
Managed to start the worker after 46 attempts.
Managed to start the worker after 60 attempts.
Managed to start the worker after 52 attempts.
Managed to start the worker after 67 attempts.
```
On local (Mac, silicon m1)
```
Managed to start the worker after 59 attempts.
Managed to start the worker after 112 attempts.
Managed to start the worker after 166 attempts.
Managed to start the worker after 221 attempts.
Managed to start the worker after 274 attempts.
Managed to start the worker after 160 attempts.
Managed to start the worker after 269 attempts.
Managed to start the worker after 436 attempts.
Managed to start the worker after 390 attempts.
Managed to start the worker after 480 attempts.
Managed to start the worker after 427 attempts.
Managed to start the worker after 655 attempts.
Managed to start the worker after 754 attempts.
Managed to start the worker after 745 attempts.
Managed to start the worker after 200 attempts.
Managed to start the worker after 158 attempts.
Managed to start the worker after 854 attempts.
Managed to start the worker after 852 attempts.
Managed to start the worker after 1011 attempts.
Managed to start the worker after 373 attempts.
Managed to start the worker after 1180 attempts.
Managed to start the worker after 628 attempts.
Managed to start the worker after 789 attempts.
Managed to start the worker after 747 attempts.
```
We even got to numbers as high as 2000 on some laptops.
For the reference, we have the following plugins on our `nx.json`
```json
{
"plugins": [
{
"name": "tsc",
"plugin": "./tools/nx-tools/src/plugins/tsc.ts",
"options": {
"targetName": "type-check"
}
},
{
"name": "eslint",
"plugin": "./tools/nx-tools/src/plugins/eslint.ts",
"options": {
"targetName": "lint"
}
},
{
"plugin": "@nx/vite/plugin",
"options": {
"buildTargetName": "build",
"previewTargetName": "preview",
"testTargetName": "test",
"serveTargetName": "dev",
"serveStaticTargetName": "serve-static"
}
},
{
"plugin": "./tools/nx-tools/src/plugins/jest.ts",
"options": {
"targetName": "test"
}
},
{
"plugin": "./tools/nx-tools/src/plugins/tsup.ts",
"options": {
"targetName": "build"
}
},
{
"plugin": "./tools/nx-tools/src/plugins/storybook.ts",
"options": {
"buildStorybookTargetName": "build-storybook",
"serveStorybookTargetName": "storybook",
"testStorybookTargetName": "test-storybook",
"staticStorybookTargetName": "static-storybook"
}
}
]
}
```
One thing we managed to find out is the more plugin on the project, the
bigger the number.
So for now, the current workaround is to bump to 10000 instead of 1000
tries
_Debugged in pair with @AgentEnder_
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Plugin worker should work and nx should be working with plugin isolation
(cherry picked from commit 9039e5e0a6)
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit 18e5535940)
<!-- 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
Parallelism is part of the project schema but not `targetDefaults`. This
means it's highlighted as a warning in `nx.json`
## Expected Behavior
There should be no warning.
(cherry picked from commit 4abcf61748)
<!-- 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 create an app with `--appName <app name in camel case>`, it
currently has an error. it is caused by line:
```
const { root: appRoot } = readProjectConfiguration(
host,
names(options.appProject).fileName
);
```
it should not convert appProject to fileName, it should just take the
appProject as it is:
```
const { root: appRoot } = readProjectConfiguration(host, options.appProject);
```
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes https://github.com/nrwl/nx/issues/24080
(cherry picked from commit 79b75ad140)
This PR fixes an issue with `nx import` where multiple directories
cannot be imported from the same repo. We now use `git filter-repo` (if
installed) or `git filter-branch` (fallback) to prepare the repo for
import so anything not in the subdirectory will be ignored (i.e. cleaner
history).
Note: `filter-repo` is much faster but requires the user to install it
first via their package manager (e.g. `brew install git-filter-repo` or
`apt install git-filter-repo`). We fallback to `git filter-branch` since
it comes with git, but it is slower, so the process may take 10+ minutes
on really large monorepos (e.g. next.js).
Also:
- Use `await` before returning a promise to Node can maintain correct
stacktrace
- Remove logic for `if (relativeSourceDir === '')` since using
`filter-branch` moves all the files to the root (`.`)
- Default destination project location to be the same as source (e.g.
importing `packages/a` will go to `packages/a` unless user types in
something else)
- Add `--depth` option if users don't want to clone with full history
(default is full history)
- Fix issues with special characters causing `git ls-files` + `git mv`
to since `mv` doesn't work with escaped names
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit ab408ab30c)
<!-- 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 -->
expo tends to cache the output if there is no change in metro.config.js
we don't need to explicitly set the args --clear when
https://github.com/expo/expo/issues/30930 is fixed
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes https://github.com/nrwl/nx/issues/27392
(cherry picked from commit 925672e20b)
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes https://github.com/nrwl/nx/issues/27367
(cherry picked from commit f64aa9a915)
<!-- 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 running sync generators in the background (daemon) to cache the
results for when needed, they are isolated from each other (each run
with its own `Tree`). This is done because there's no guarantee which
sync generator will be run together since that would depend on each
specific task graph being run. When a task is run, a task graph is
constructed, and sync generators are collected from it and run/retrieved
from the cache.
Currently, when we run a task and ask the daemon to run the relevant
generators, if there are cached results for a generator that ran in
isolation, we return it. We don't check if its file changes conflict
with those of another generator included in the task graph. This results
in the changes for those conflicting files of the first generator
getting overwritten by the changes of the second generator.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When running tasks for which there are conflicting file changes between
generators in the daemon, the conflicting generators should be re-run
sequentially using the same `Tree` to guarantee that file changes are
not overwritten and lost.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
<!-- Fixes NXC-903 -->
Fixes #
(cherry picked from commit 3562131820)
Tabs are not displaying correctly on the second page that is viewed.
Should be able to select the `project.json` tab on `Run Tasks` and then
switch to `Cache Task Results` and have the `Nx >= 17` tab shown.
(cherry picked from commit a7b2787069)
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes https://github.com/nrwl/nx/issues/22631
(cherry picked from commit 81acdedb18)
This PR fixes an issue with `node:test` not being recognized as a
built-in Node module, and since it is not in `node_modules` with a
resolvable `package.json`, it hits an infinite loop.
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit e28de09c40)
This PR fixes and issue when `watch: false` and
`runBuildTargetDependencies: true` results in the server process
restarting, but no build happens.
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#20963
(cherry picked from commit d1c901df1e)
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit adcefcc6da)
The test to ensure we don't bundle secrets/tokens is causing an error
like this:
```
NX Connection to Nx Cloud failed with status code ERR_BAD_REQUEST
```
e.g. https://staging.nx.app/runs/0IjxPh53dK
Likely due to validation errors now in place. We shouldn't be hitting Nx
Cloud from the test project, so I've renamed the variables to be
something that isn't used to connect to Cloud.
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit be37c35351)
<!-- 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
When you specify the `envFile` property on a `nx:run-commands` executor,
values in that file don't override values from other loaded env files
(like `.env` and others that are loaded by the task runner).
## Expected Behavior
`envFile` contents should take precedence. The properties specified in
the `env` option should still override this.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit 3fbaf7f873)
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit 6cb0720009)
<!-- 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 vite plugin's typecheck target is not using the tsconfig.lib.json
project when running typecheck for libs
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
It should use the correct tsconfig
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27501
(cherry picked from commit 564834462e)
- feat(devkit): add util for determining the e2e web server info
- feat(vite): add util for determining the e2e web server info
- feat(webpack): add util for determining the e2e web server info
- fix(webpack): allow port override
- fix(devkit): e2e web server info util should handle target defaults
- feat(webpack): export the e2e web server info utils
- fix(vite): rename util
- fix(devkit): util should determine the devTarget for cypress
- fix(react): improve accuracy of e2e project generation
<!-- 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 logic for finding the correct targets and web addresses to use when
setting up e2e projects is flawed and missing some key considerations.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The logic is accurate and usage is simplified across plugins
Projects:
- [x] Angular
- [x] Expo
- [x] Next
- [x] Nuxt
- [x] Vue
- [x] Web
- [x] Remix
- [x] React
- [x] React Native
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit 320d9f223f)
## Current Behavior
<!-- This is the behavior we have today -->
When the name of a gradle project is overwritten by a different plugin,
the plugin throws an error creating dependencies.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The plugin uses the `CreateDependenciesContext` to get the name of a
project at the project root and uses that to create the dependency.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit 036e5fcf3e)
<!-- 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 -->
--e2eTestRunner option is not working when create-nx-workspace with
preset react native
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
--e2eTestRunner option should be working when create-nx-workspace with
preset react native
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit f02e2fc76e)
## Current Behavior
<!-- This is the behavior we have today -->
Output is still streamed sometimes when `--outputStyle static` is used.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Output is not streamed when `--outputStyle static` is used.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit 45e088e066)
## Current Behavior
<!-- This is the behavior we have today -->
Imperatively running tasks does not return task results.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Imperatively running tasks returns task results along with the overall
status and the task graph
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit 6fff9b5e81)
<!-- 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 pnpm `9.2.0`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses pnpm `9.8.0`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit f0e419b04f)
<!-- 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 -->
We check the CLI property exists and if it's not `nx` we will use the ng
compat layer to run the migration.
If the CLI property does not exist, we check both if the migration is in
the `schematics` object on the `migrations.json` and if the contents of
the migration implementation contains an import from `@angular-devkit`.
The problem with the fallback is that if only types are imported from
`@angular-devkit` the import is stripped from the migration
implementation completely.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
We had planned already to remove the fallback of reading the file
contents.
We had also planned to remove using the `cli` property to determine if
the migration needed the `ng compat layer`.
However, as the `cli` property is still useful for now for package's
that needed some manner to circumvent the flawed fallback logic, let's
continue to use it until v21.
Log a warning however if the `cli !== 'nx'` and it is placed in the
`generators` section of the `migrations.json` to provide ample time for
plugin developers to move them to the `schematics` property.
Fallback has been updated to whether or not the migration lives in
`schematics` and not flawed read file logic.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#20282
(cherry picked from commit 62c651272c)
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes https://github.com/nrwl/nx/issues/26889
(cherry picked from commit ec53f315b9)
… - update to yarn 2+
Closes#27588
## Current Behavior
See #27588
## Expected Behavior
See #27588
## Related Issue(s)
See #27588
Fixes #
Co-authored-by: @NgDaddy Paweł Twardziak <contact@ngdaddy.com>
(cherry picked from commit 15b8d49c4b)
<!-- 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 pnpm v8
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses pnpm v9
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: “JamesHenry” <james@henry.sc>
(cherry picked from commit 088a95b7e5)
Remove:
- Automatically update Nx
- Monorepo World Conference Speakers Announced
From changelog page, since those are not new features in 19.5
(cherry picked from commit 51ecd54ea1)
<!-- 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 order of the CI providers prompt does not match their popularity
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The order of the CI providers prompt matches their popularity
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit 77cbfa0e87)
Webpack-dev-server v5 changed the proxy config to only accept arrays.
This PR adds a migration for JSON proxy config files to automatically do
the conversion for users. If it's not a JSON format, then we log a
warning and point them to the v5 migration page.
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit f9bb3082b7)
<!-- 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 -->
React, Tailwind and Rspack is not working out of the box
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
It works out of the box.
In tandem with nrwl/nx-labs#415
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27028
(cherry picked from commit add4183d0a)
<!-- 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 -->
Nx build native isn't working correctly on windows, stating that
`window` is not a correct option for `cfg!`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Use the `windows` option for `cfg!` as stated by the error message
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit 692504f1c9)
<!-- 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 using incremental builds with `@nx/angular:webpack-browser` the
dependent libraries need to be built.
However, there is no target default to force a build to build
dependents.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Add a targetDefault and update docs to reflect this requirement
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#26483
(cherry picked from commit d9fed4b832)
<!-- 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 failing due to failing snapshots
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Snapshots are updated appropritately.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit 1824267788)
Updated doc:
https://nx-dev-git-docs-dependency-checks-lock-file-callout-nrwl.vercel.app/nx-api/eslint-plugin/documents/dependency-checks
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#22442
(cherry picked from commit 35899e3a25)
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit 3d940c8884)
## Current Behavior
<!-- This is the behavior we have today -->
This repo uses Nx `19.6.0-beta.6`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses Nx `19.7.0-beta.1`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit 2ccf0d27c2)
<!-- 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
The daemon is hard-disabled in docker, even if you try to explicilty
enable it using the `NX_DAEMON` env var.
## Expected Behavior
We should disable the daemon by default in docker but allow users to
opt-in using the env var. There might be issues that come with that but
since it's opt-in, it will be at their own risk.
## Related Issue(s)
Fixes https://github.com/nrwl/nx/issues/14126
(cherry picked from commit eeb60b64af)
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes https://github.com/nrwl/nx/issues/27357
(cherry picked from commit c0ebc16089)
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes https://github.com/nrwl/nx/issues/26850
(cherry picked from commit cc322eb01e)
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Fixes login issue with nx Cloud due to switch to new nxCloudId auth
method
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit adf9f2e444)
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes https://github.com/nrwl/nx/issues/27135
(cherry picked from commit 00710b9187)
Current behavior:
`nx g create-package create-my-plugin --project my-plugin` fails because
`e2eProject` defaults to the root project.
Expected behavior:
`nx g create-package create-my-plugin --project my-plugin` succeeds.
(cherry picked from commit ecbd2cba04)
We already do this for esbuild apps (e.g. express, fastify, koa), but we
don't do it for webpack (nest).
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27389
(cherry picked from commit ca89950920)
## Current Behavior
The [docs](https://nx.dev/nx-api/next/generators/library#unittestrunner)
say that you can use vitest as a unitTestRunner option. It also worked
when I tested with the following command:
```sh
nx g @nx/next:library shared --dir=modules/shared --style none --dry-run --projectNameAndRootFormat as-provided --component false --unitTestRunner vitest
```
But types say otherwise:
## Expected Behavior
Types will allow 'vitest' option for a unitTestRunner
## Related Issue(s)
none
Co-authored-by: Emily Xiong <xiongemi@gmail.com>
(cherry picked from commit 73f12a322d)
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#19911Fixes#27421
(cherry picked from commit 0f3120712f)
<!-- 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 `withVerbose` util is only used in a few places.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The `withVerbose` util is used throughout and also contains middleware
to default to the value in `process.env.NX_VERBOSE_LOGGING === 'true'`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit 9269de7763)
<!-- 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 types that are generated for esbuild packages are not placed into
the correct folder structure in the built package and is very dependent
of the CWD.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The declaration files should be generated correctly to match the package
and not dependent on CWD
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#26261#26376
(cherry picked from commit c427717fc1)
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27470
(cherry picked from commit 2ffec0aa3f)
## Current Behavior
It's not possible to import `setRemoteDefinition` from `@nx/angular/mf`.
## Expected Behavior
Export `setRemoteDefinition` in `@nx/angular/mf`
(cherry picked from commit a08e2adda6)
<!-- 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 -->
Nx Cloud uses the nxCloudAccessToken to authenticate and provide
permissions access the cache.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Users who want to use Nx Cloud locally with a read-write token will need
to run `nx-cloud login` to generate a personal access token and have
`nxCloudId` in their nx.json. These two pieces of identification are
needed together to provide permissions to access nx cloud features.
By default users who do not have a personal access token/do not have an
Nx Cloud account will have 'read' permissions.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit 20650334e7)
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit 7e158385fd)
This PR adds a section to the `Adding Images, Fonts, and Files` React
recipe to show how to use SVGR with Vite.
With our Vite setup, we're keeping the configuration minimal so we don't
want SVGR out of the box.
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#19282
(cherry picked from commit 046abc4938)
## Currently
When we installed swc from the Next.js generator it installed an older
version that expected version of swc this caused the node & build
generator to not work.
## Expected
With these changes the version will be in sync with what the
`@nx/js:swc` executor is expecting. With that in mind the build should
now work as expected and by extension the serve target for custom server
as well.
fixes: #27222
(cherry picked from commit 554e979abf)
<!-- 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 -->
https://nx.dev/getting-started/tutorials/gradle-tutorial#running-tasks
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
https://nx-dev-git-feat-graph-add-expand-targets-nrwl.vercel.app/getting-started/tutorials/gradle-tutorial#running-tasks
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Max Kless <maxk@nrwl.io>
(cherry picked from commit 66ff751f0d)
fixes: #22450
<!-- 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, if you run any next target outside of nx the build will fail
because we only fallback for graph creation of if running prod server.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Targets should work if they are run outside of the Nx cli
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit 31c5745126)
This PR adds `sourceMap` option to `@nx/rollup:rollup` executor and the
`withNx` util (for Project Crystal). The same option is used for
Webpack.
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#9199
(cherry picked from commit fdb488b394)
This PR adds `skipPackageManager` option to several build executors in
order to disable generating the `packageManager` field in the resulting
`package.json` file. This field may be problematic on different
platforms so we want a way to work around it.
Affected executors:
- `@nx/webpack:webpack`
- `@nx/vite:build`
- `@nx/next:build`
- `@nx/remix:build`
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27027
(cherry picked from commit 83237a8670)
<!-- 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 -->
Vite intentionally does not run typechecking on projects. They recommend
running `tsc --noEmit` separately.
The `@nx/vite/plugin` could make this easier by adding a `typecheck`
when it detects a `tsconfig` file in the `projectRoot`.
This can then be added to the build pipeline on CI. Or users can add it
to a `dependsOn` for the `build` target if they wish.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The `@nx/vite/plugin` could make this easier by adding a `typecheck`
when it detects a `tsconfig` file in the `projectRoot`.
This can then be added to the build pipeline on CI. Or users can add it
to a `dependsOn` for the `build` target if they wish.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27501
(cherry picked from commit 6d963fd21d)
<!-- 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 -->
Stories generation for React components only handles components
receiving a `props` argument typed with an `Interface`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Stories generation for React components should handle receiving the
props with any name or as a destructured object and typed with an
`Interface`, a type literal definition, or an inline type literal. In
case it's a destructured object, it also supports having no type, in
which case the story args will have those properties with type
`unknown`.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#22053
(cherry picked from commit fd74969367)
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit 6d6c3515fd)
Allows consumers to use vitest 2 with the @nx/vite plugin.
closed#27259
<!-- 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 -->
Users cannot use Vitest 2 with @nx/vite.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Users can use Vitest 2 with @nx/vite.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27259
(cherry picked from commit 186e4c7606)
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes https://github.com/nrwl/nx/issues/27160
(cherry picked from commit 7c45589a71)
We should be consistent about how options are defined in our plugins.
Currently, there are some options that use `enum`s and some that use
typed strings. I think typed strings are preferable because someone
extending a generator only needs to import the main generator that
they're extending, not all the transitive dependencies of that
generator.
Current extending code:
```
// ...
import { applicationGenerator as reactApplicationGenerator } from '@nx/react';
import { Linter } from '@nx/eslint';
export async function applicationGenerator(
tree: Tree,
options: ApplicationGeneratorSchema
) {
reactApplicationGenerator(tree, {
...options,
linter: Linter.EsLint,
});
}
```
Desired extending code:
```
// ...
import { applicationGenerator as reactApplicationGenerator } from '@nx/react';
export async function applicationGenerator(
tree: Tree,
options: ApplicationGeneratorSchema
) {
reactApplicationGenerator(tree, {
...options,
linter: 'eslint',
});
}
```
The problem is not just an extra line of code, the person extending the
`reactApplicationGenerator` has to dig into the implementation details
of the generator itself in order to know where to find the `Linter`
enum. The `e2eTestRunner` is already a typed string and is easily
extended.
The solution I'm proposing in this PR would define a typed string in the
same file as the existing enum. None of the implementations need to
change. No community plugin code will be broken.
(cherry picked from commit 839dc1585b)
<!-- 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 -->
Files which have special characters in the path cannot be imported.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Files which have special characters in the path can be imported.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27468
(cherry picked from commit a5b93b8e83)
This PR expands the recipe for [Set Up App
Proxies](https://nx.dev/recipes/node/application-proxies). There is no
way for us to add proxy config automatically since `proxy.json` is
specific to our executor, and users should use the underlying tools'
proxy support instead.
Also adds an info for users using `--frontendProject` option in
crystalized workspaces.
Note: The proxy feature from Webpack and Vite allow more advanced use
cases, so it's preferred to the old `proxy.json` support anyway.
Preview:
https://nx-dev-git-docs-node-proxy-config-nrwl.vercel.app/recipes/node/application-proxies#set-up-application-proxies
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27321, #23158
(cherry picked from commit d8d57c862b)
We're showing `.cts` and `.mts` files as supported, but Webpack CLI will
not load them.
The language support is outlined here:
https://webpack.js.org/configuration/configuration-languages/#typescript
This PR removes those extensions to match what our plugin actually
infers from.
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27438
(cherry picked from commit aa59a69af2)
This PR ensures that we pass Vite config file to the programmatic
`startTest` API from Vitest. It fixes the issue with plugins not loading
as well as other issues with the config file not being used.
This mainly affects a custom `configFile` option being passed to the
executor. The previous fix to additionally load in `plugins` via
overrides is causing plugins to load twice when the Vite config file is
picked up by Vitest (e.g. #27500).
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27500, #22001
(cherry picked from commit 402bae2ce1)
<!-- 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 -->
Vite Plugin was originally only checking if the `lib` option was defined
in a vite config, and using that to avoid inferring serve targets.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Some libraries may still need a serve target, and if they have a server
config defined, the serve target should be inferred
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27370
(cherry picked from commit 08fc13de5f)
<!-- 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 host application is never set as a candidate to share packages from.
Particularly in angular, this causes issues with the injection context
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Host application should be a valid option for sharing packages
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27162
(cherry picked from commit 813770862e)
<!-- 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 -->
With the introduction of App Router by NextJs, components may not live
in a `components` directory. Storybook config should reflect this.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Stories path should be a glob from project root
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27233
(cherry picked from commit afe83b4b07)
Bump the NgRx package versions to ensure the `@ngrx/signals` package is
migrated correctly. That package version was out of sync with the rest
of the NgRx packages. Starting on v18.0.2, the package version is in
sync with the rest.
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit 54f70c7587)
… `launch-templates`
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit b91d78809e)
## Current Behavior
When you use esbuild in 'browser' mode you have to provide all 'define'
attributes as environment variables and only with "NX_PUBLIC_" prefix
## Expected Behavior
Esbuild configuration has to work as it is described in docs. And prefix
feature has to work as an additional functionality
## Related Issue(s)
This issue will be fixed: https://github.com/nrwl/nx/issues/19106
Co-authored-by: Dmitrii Kamenskikh <dkamenskikh@devexperts.com>
(cherry picked from commit 4941be6197)
<!-- 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 the application are received a shutdown signal, the application
doesn't execute before shutdown functions and directly shutdown whole
application. The situation cannot execute before shutdown functions like
[NestJS Lifecycle
Events](https://docs.nestjs.com/fundamentals/lifecycle-events) and
custom shutdown hooks.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The application can run shutdown hooks like below output:
NX Successfully ran target build for project nest-test (5s)
Debugger listening on
ws://localhost:9229/e4bd44c0-9a6a-468a-8b46-b6fef1cef1c7
For help, see: https://nodejs.org/en/docs/inspector
```
NX Successfully ran target build for project nest-test (4s)
Debugger listening on ws://localhost:9229/75c8449b-43a4-4d8b-88c0-231761d7248c
For help, see: https://nodejs.org/en/docs/inspector
To exit the process with SIGINT, press Ctrl+C
[Nest] 393107 - 08/09/2024, 6:31:26 PM LOG [NestFactory] Starting Nest application...
[Nest] 393107 - 08/09/2024, 6:31:26 PM LOG [InstanceLoader] AppModule dependencies initialized +10ms
[Nest] 393107 - 08/09/2024, 6:31:26 PM LOG [RoutesResolver] AppController {/api}: +7ms
[Nest] 393107 - 08/09/2024, 6:31:26 PM LOG [RouterExplorer] Mapped {/api, GET} route +3ms
[Nest] 393107 - 08/09/2024, 6:31:26 PM LOG [NestApplication] Nest application successfully started +2ms
[Nest] 393107 - 08/09/2024, 6:31:26 PM LOG 🚀 Application is running on: http://localhost:3000/api
[Nest] 393107 - 08/09/2024, 6:31:29 PM LOG onModuleDestroy
onModuleDestroy: 5.001s
[Nest] 393107 - 08/09/2024, 6:31:34 PM LOG beforeApplicationShutdown SIGINT
beforeApplicationShutdown: 5.004s
[Nest] 393107 - 08/09/2024, 6:31:39 PM LOG onApplicationShutdown SIGINT
onApplicationShutdown: 5.005s
NX Process exited with code 130, waiting for changes to restart...
```
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#9237 and #18037
---------
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
(cherry picked from commit b5a93364c5)
Integrate a new Monorepo World banner with animations in the hero section using framer-motion. Updated the UI icons library to include Monorepo World icon and relevant SVG file.
(cherry picked from commit 289b23bfdf)
Link the parallelism blog post to the actual reference document.
Currently the blog post shows up in a search for `parallelism` but the
actual reference does not. This link can help while we work on the
search.
(cherry picked from commit 15bc7ac69b)
This PR adds events to track engagement in our docs. Since we use a
scrollable `<div>` in our docs, the normal `scroll` events in GA do not
work.
A new `<ScrollableContent>` component is added that will do two things:
- Send `scroll_25`, `scroll_50`, `scroll_75`, and `scroll_90` events
whenever the user scrolls to 25%, 50%, 75%, of 90% of the content
- Optionally reset scroll top to zero whenever router changes (existing
behavior)
All of the places where we have content in a scrollable `<div>` is
replaced with `<ScrollableContent>`.
Note: 90% means user has reached the bottom, since it's not usually
possible to get to 100%.
(cherry picked from commit 9dca7c7025)
<!-- 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 `@nx/dependency-checks` rule sometimes doesn't apply all identified
fixes and wrongly succeeds. ESLint performs multiple passes to try to
apply fixes, and in each pass the rule receives the updated source code
with the previously applied fixes. This allows merging different fixes,
but the `@nx/dependency-checks` rule always reads the `package.json`
file from the filesystem, caches it globally, and mutates it. It never
uses the updated source code provided in the rule context.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The `@nx/dependency-checks` rule should apply all identified fixes [as
long as they don't
conflict](https://eslint.org/docs/latest/extend/custom-rules#conflicting-fixes).
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27412
(cherry picked from commit b699207070)
<!-- 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 re-mapping a TS path mapping like `"@foo/lib1/plugins/some-file":
["packages/lib1/src/plugins/some-file.ts"]`, it results in:
```json
"@foo/lib1/plugins/some-file": [
"dist/packages/lib1/plugins/some-file",
"dist/packages/lib1/src/plugins/some-file.ts"
]
```
The first path is wrong because it's missing the `src` directory, and
the second one has a file extension that's not in the output.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When re-mapping a TS path mapping like `"@foo/lib1/plugins/some-file":
["packages/lib1/src/plugins/some-file.ts"]`, it should result in:
```json
"@foo/lib1/plugins/some-file": [
"dist/packages/lib1/plugins/some-file",
"dist/packages/lib1/src/plugins/some-file",
"dist/packages/lib1/src/plugins/some-file.ts"
]
```
In this case, the second path would correctly point to the output. It
doesn't have an extension, which allows the compiler to pick up the
correct one.
Note that while the first and third paths are still not valid for this
specific use case, they could still be valid for other use cases, and in
any case, they're still kept for backward compatibility. The util to
re-map these paths is currently very generic and generates potentially
valid paths. The invalid paths for a given use case won't throw an error
as long as there's one that's valid.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#21699
(cherry picked from commit 89f6ad4d8d)
<!-- 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 -->
Target Defaults set up for the Module Federation builds is incorrect or
missing.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Target Defaults for Module Federation builds is set up correctly
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27448
(cherry picked from commit 396a5deea9)
## Current Behavior
see #27433
## Expected Behavior
see #27433
## Related Issue(s)
see #27433
Fixes #
- if compiler is `swc`, `@vitejs/plugin-react-swc` is being imported;
otherwise `@vitejs/plugin-react` is being imported
Co-authored-by: Emily Xiong <xiongemi@gmail.com>
(cherry picked from commit 7f2c5565de)
<!-- 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 -->
`module-federation-ssr-dev-server` is calling `dev-server` builder
instead of `ssr-dev-server` builder
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`module-federation-ssr-dev-server` calls the correct builder
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit 829f5fa758)
<!-- 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 -->
New workspaces are generated with `@nx/angular` as a production
dependency even though the generated code does not use any runtime
helper from it.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
New workspaces should be generated with `@nx/angular` as a development
dependency. When generating a new MF host or dynamic MF application
(host or remote), the `@nx/angular` package should be moved to the
production dependencies because the generated code uses some runtime
helpers from it.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27333
(cherry picked from commit 1ae3c2d8f9)
Corrects a minor formatting issue by removing an unnecessary period in
the explanation text for failed task outputs.
(cherry picked from commit 0b2f4527d9)
## Current Behavior
running `nx test js` fail on windows
## Expected Behavior
running `nx test js` succeed
## side notes
1. I was skipping `packages/js/src/plugins/typescript/plugin.spec.ts`
because it makes all tests fail, and even in wsl it's very flaky, it
fail 90% of the times, but I couldn't figure out why
I think it's worth looking at from someone with more experience with the
repo
2. for some of the cases that I fixed I'm not sure if I should change
the code to always return `/` or should change the test to adapt `/` in
linux and `\` in windows, so please if I mistaken one of them let me
know and I will do it the other way around but I believe it should be
fine since in windows `foo/bar` does work as a path still
(cherry picked from commit 69c989ed9b)
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit f7eab14f6b)
<!-- 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 -->
`nx:build-native` updates the typings which `graph-client:build-client`
uses. Not running it in the right order could result in a compilation
error.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`nx:build-native` updates the typings which `graph-client:build-client`
uses so it depends on `nx:build-native`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit 01985c11db)
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit 4f1db3e07a)
<!-- 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 og images for the blogs are not being generated.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The og images for all blogs should be generated.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
(cherry picked from commit 2e48ebf433)
<!-- 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
Custom reporters are not usable because we enforce an enum on the schema
## Expected Behavior
Custom reporters can be specified
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Craigory Coppola <craigorycoppola@gmail.com>
(cherry picked from commit 8c7e3619a9)
<!-- 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 -->
Version plans, stable in the imminent `19.6.0` release, is undocumented.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Version plans is a documented feature.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Isaac Mann <isaacplmann@users.noreply.github.com>
(cherry picked from commit f1ecad0a8e)
This commit integrates the "Explain with AI" feature into the Enterprise
and Pro plans for providing detailed explanations and insights for
failed task outputs. It also remove the Nx Workflows mention of the
pricing page. It also updates various links within the Hobby plan and
modifies plan table descriptions to reflect the accurate feature names.
(cherry picked from commit 96b8133d85)
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit d8de0cd792)
This PR adds a recipe for converting executor-based configuration to
inferred configuration.
The goal of the recipe is to guide users on what commands to run,
understand what changes were applied, and how to verify the migrations.
Preview:
https://nx-dev-git-docs-inferred-migration-recipe-nrwl.vercel.app/recipes/running-tasks/convert-to-inferred
[x] Link to this from Project Crystal concept page
[x] Mark recipe as related to Migration feature page
<!-- 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 -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Isaac Mann <isaacplmann@gmail.com>
(cherry picked from commit 99b0557fb9)
this code is needed in a version-independent way in Nx Console and right
now there's no good place to share it.
So for now we will duplicate it
(cherry picked from commit cf5dd4da08)
<!-- 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 -->
Current docs chat uses `gpt-3.5-turbo`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Docs are now using `gpt-4o-mini`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
(cherry picked from commit 5cd08e2828)
2024-08-19 10:19:18 -04:00
678 changed files with 38294 additions and 26365 deletions
Nx is a build system with built-in tooling and advanced CI capabilities. It helps you maintain and scale monorepos, both locally and on CI.
Nx is a build system, optimized for monorepos, with plugins for popular frameworks and tools and advanced CI capabilities including caching and distribution.
"description":"Nx plugin for Cloudflare, in particular Cloudflare workers. It allows to generate build and run Cloudflare workers in your Nx workspace.",
A disclosure can be used for less important information that is initially collapsed.
These are special callouts that are collapsed with the intention of containing more deep-dive information about the topic which isn't required to understand right away.
@@ -54,7 +54,7 @@ With Nx Replay, you can see significant speed improvements in your CI pipelines
[Nx Agents](/ci/features/distribute-task-execution) represent the pinnacle of task distribution optimization, ensuring that tasks are executed as efficiently as possible based on the specific requirements of each change. Some features that make up this effort are:
- [Easy integration with existing providers](/ci/features/distribute-task-execution#cicd-guides)
- [Easy integration with existing providers](/ci/recipes/set-up)
- Distribution is handled on the Nx Cloud infrastructure and all you need is a single line. What’s more, all results are played back to your original CI provider script which triggers the Nx Cloud distribution, so that you can make use of the resulting artifacts
The proverbial slow and flaky CI isn’t the failure of the developers or even the testing tools. It’s the failure of the CI execution model we relied on for the last 20 years.
In this episode, Zack DeRose from Nx chats with Hicham El Hammouchi, a veteran in enterprise software. Hicham dives into his background, sharing his career journey and the wealth of experience he's gathered along the way.
They tackle the tough challenges that companies face in software development. Hicham offers practical insights and real-life examples from his own career, making complex issues easier to understand. He also shares some tried-and-true strategies for overcoming these hurdles, emphasizing the importance of teamwork and effective project management.
As the chat continues, Zack and Hicham explore the latest tech trends and innovations that are shaking up the industry. Hicham's forward-thinking views provide a sneak peek into the future of enterprise software. They also discuss detailed case studies of successful projects, highlighting the importance of staying focused on customer needs and feedback.
In this episode, welcome Nx Champion and Nx Expert, Tine Kondo. Our discussion highlights how Nx is poised to make an impact in the Java space.
We touch on the difficulties larger organizations face when merging PRs in a timely manner, emphasizing how a monorepo alleviates the headache of coordinating multiple PRs across various repositories, and share firsthand experiences and frustrations with traditional multi-repo setups, underscoring the benefits of a unified approach.
In particular, Nx's new plugin: [@nx/gradle](/nx-api/gradle) is of interest, and Tine provides some valuable insight on the impact this plugin can make, as well as the importance for Maven support.
It's Friday, and you absolutely, positively have to deploy to production. But you can't get CI to pass your PR. What do you do? It's an inevitable part of your life as a developer, and you've built a collection of tools to deal with it: Google, MDN, Discord, ChatGPT. We've got one more tool for your toolbox: **"Explain with AI" for [Nx Cloud](/nx-cloud)**.
## Your ticket to fast error debugging
"Explain with AI" is a new feature for all Nx Cloud Pro users that is going to help you troubleshoot those pesky failing tasks. Whenever you get an error message on CI, look for the "Explain with AI" button on the upper right-hand corner:
"[Explain with AI](/ci/features/explain-with-ai)" is a new feature for all Nx Cloud Pro users that is going to help you troubleshoot those pesky failing tasks. Whenever you get an error message on CI, look for the "Explain with AI" button on the upper right-hand corner:
@@ -20,6 +22,8 @@ Once you hit that button, we collect the terminal output and other Nx task infor
No more switching back and forth between a dozen tabs with different solutions. No more providing the right context for your masterfully written chat prompt. **Get your suggested fix and get back to work.**
Also make sure [to check out our docs](/ci/features/explain-with-ai) for more information.
## How can I start using this today?
- [Monorepo World Conference Speakers Announced!!](#monorepo-world-conference-speakers-announced)
- [Learn more](#learn-more)
## Video Summary
@@ -142,7 +145,7 @@ To accommodate port collisions in end-to-end tests, we've long adjusted our gene
Unfortunately, this approach is more imperative, as it instructs how to run and order your CI rather than defining what should be run. Additionally, these instructions cause `lint`, `test`, and `build` targets to run first and wait until they all complete before running `e2e-ci`, leading to inefficiencies.
To address this, all tasks now support a `parallelism` property. By setting this property to `false`, you can instruct the Nx task runner not to run a specific task in parallel. This allows us to define parallelism as a task property, making our CI configuration more declarative.
To address this, all tasks now support a [`parallelism` property](/reference/project-configuration#parallelism). By setting this property to `false`, you can instruct the Nx task runner not to run a specific task in parallel. This allows us to define parallelism as a task property, making our CI configuration more declarative.
Both our `@nx/playwright` and `@nx/cypress` plugins will now automatically set `targetDefaults` for atomized tests to disable parallelism:
In this episode we welcome Nx Champion and creator of [noodle](https://noodle.run) and [OrbitKit](https://orbitkit.dev/): Ahmed Elsakaan.
As a monorepo enthusiast, we explore Ahmed's thoughts on monorepos and how these tools can add value to developers - both in the space of setting up your monorepo (like Nx does) and in the space of creating reusable customizable modules (like OrbitKit is attempting).
In this edition of the Nx Enterprise Podcast, Zack sits down with a panel of Platform Architects from the event platform company, [Cvent](https://www.cvent.com/).
The panel, featuring Youssef Taghlabi, Kevin O'Brien, Josh Lartz, and Ladi Kobiti, dives into their approach to platform engineering—focusing on how they empower teams across their organization and the critical role Nx plays in achieving those goals.
Whenever we talk about Nx Cloud, speed is often a major focus—and for good reason. However, Nx Cloud isn't just about speed. Similar to Nx itself, it's about making work within monorepos more pleasant and efficient. A key part of that is continuously **optimizing developer ergonomics**.
Structuring your log output is one example. In a polyrepo setup, this isn't a big deal since you typically run tasks for a single project. However, in a monorepo setup, you might be running hundreds of tasks in parallel across multiple projects. **Quickly finding a failed task in this context can be challenging.**
## New Table Log View
Today, we released an update that improves how logs are displayed on your CI provider when using Nx Cloud. Instead of streaming all logs directly into your CI provider's pipeline, **we now render a structured table view**. This table shows all tasks, their status (success or failure), timing, and whether they had a cache hit or miss.
At the end of the log output, you'll also see aggregated stats about executed tasks, cache hits, and a link to the Nx Cloud dashboard with full details of the run.
If you prefer the previous log view in your CI, you can opt-out of the new table view. Simply go to your Nx Cloud workspace settings and enable the "Display live terminal outputs in CI pipeline log" option.
If you're not on Nx Cloud yet, you can **connect your Nx workspace** by running:
```shell
npx nx connect
```
This command will guide you through the setup. We recently introduced a [new Hobby plan](/pricing), which lets you experiment with all the Nx Cloud features for free. This is a great way to see if it's a good fit for your team.
## Learn More
- [Nx on CI](/ci)
- [Task Distribution with Nx Agents](/ci/features/distribute-task-execution)
- [Automated e2e Test Splitting](/ci/features/split-e2e-tasks)
In this episode of Nx Live, Zack sits down with David from [Trunk.io](https://trunk.io) to explore hands-on examples of how to fast-track your PRs using Nx and Trunk Merge Queues. They also discuss the latest [first-class support for Nx](https://docs.trunk.io/merge-queue/parallel-queues/nx) recently added to Trunk, demonstrating how these tools can streamline your development workflow.
[Monorepo World](https://monorepo.world) is our two-track conference bringing together experts in developer tooling and of course, monorepos. We’re thrilled to share some of this year's speakers, including folks from Zephyr Cloud, Atlassian, GitHub, and HeroDevs. Without further ado, let’s meet your first round of speakers!
### Hacking Bundlers in Nx
[Lois Zhao](https://x.com/zmzlois), Zephyr Cloud
Want to know how builders work and how they can impact your projects? Let’s look at various bundlers and see how they affect the build time and output while also potentially saving organizations millions of dollars.
### What's In Your Dependency Graph
[Josh VanAllen](https://x.com/JVAsays), HeroDevs
Ever ask yourself “why is this build taking so long?” You’re not alone. With monorepos, managing your workspace’s dependency graph can make the difference between spending countless hours waiting to see if your simple changes fixes your apps. Learn how to find the hidden bottlenecks in your dependency graphs and make them efficient!
### How To Use Git - The Right Way - For Monorepos
[Scott Arbeit](https://x.com/ScottArbeit), GitHub
We all use git in our day to day, and it’s great! Until you have to clone a large repository, like potentially a monorepo. Thankfully, there are some tips and tricks you can use to work with large repositories and git that can greatly improve your user experience.
### Atlassian Frontend's Journey To The Monorepo
Manoraj K & Sourav Shaw, Atlassian
Adopting a monorepo for an organization can be a transformative experience. Learn from the folks at Atlassian to hear how they migrated to a monorepo and what strategies they employ to merge multiple repositories into one unified structure.
## Get Your Tickets Today
We hope you’re excited to see these amazing sessions! We’ll have more to share soon about what other speakers you can expect to see at Monorepo world! Don’t forget to register and get your ticket before prices go up September 6th 😱!
We updated `webpack-dev-server` to v5 in `@nx/webpack`, which comes with some breaking changes. See their [migration guide](https://github.com/webpack/webpack-dev-server/blob/master/migration-v5.md) for more details.
"description":"The Nx Plugin for Angular contains executors, generators, and utilities for managing Angular applications and libraries within an Nx workspace. It provides: \n\n- Integration with libraries such as Storybook, Jest, ESLint, Tailwind CSS, Playwright and Cypress. \n\n- Generators to help scaffold code quickly (like: Micro Frontends, Libraries, both internal to your codebase and publishable to npm) \n\n- Single Component Application Modules (SCAMs) \n\n- NgRx helpers. \n\n- Utilities for automatic workspace refactoring.",
@@ -86,7 +86,7 @@ The `targetName`, `ciTargetName`, `componentTestingTargetName`, and `open-cypres
### Splitting E2E tasks by file
The `@nx/cypress/plugin` will automatically split your e2e tasks by file. You can read more about this feature [here](/ci/features/split-e2e-tasks).
The `@nx/cypress/plugin` will automatically split your e2e tasks by file. You can read more about the Atomizer feature [here](/ci/features/split-e2e-tasks).
To enable e2e task splitting, make sure there is a `ciWebServerCommand` property set in your `cypress.config.ts` file. It will look something like this:
@@ -6,6 +6,10 @@ The rule uses the project graph to collect all the dependencies of your project,
We use the version numbers of the installed packages when checking whether the version specifier in `package.json` is correct. We do this because this is the only version for which we can "guarantee" that things work and were tested. If you specify a range outside of that version, that would mean that you are shipping potentially untested code.
The `@nx/dependency-checks` rule requires the presence of an up-to-date lock file in the workspace root to detect installed packages and their versions correctly. If the `package.json` file has changes that are not reflected in the lock file, make sure to perform a package installation.
{% /callout %}
## Usage
Library generators from `@nx` packages will configure this rule automatically when you opt-in for bundler/build setup. This rule is intended for publishable/buildable libraries, so it will only run if a `build` target is detected in the configuration (this name can be modified - see [options](#options)).
The `@nx/enforce-module-boundaries` ESLint rule enables you to define strict rules for accessing resources between different projects in the repository. Enforcing strict boundaries helps to prevent unplanned cross-dependencies.
The `@nx/enforce-module-boundaries` ESLint rule enables you to define strict rules for accessing resources between
different projects in the repository. Enforcing strict boundaries helps to prevent unplanned cross-dependencies.
## Usage
@@ -28,19 +29,22 @@ You can use the `enforce-module-boundaries` rule by adding it to your ESLint rul
| allow | _Array<string>_ | _[]_ | List of imports that should be allowed without any checks |
| allowCircularSelfDependency | _boolean_ | _false_ | Disable check for self circular dependency when project imports from itself via alias path |
| banTransitiveDependencies | _boolean_ | _false_ | Ban import of dependencies that were not specified in the root or project's `package.json` |
| checkDynamicDependenciesExceptions | _Array<string>_ | _[]_ | List of imports that should be skipped for `Imports of lazy-loaded libraries forbidden` checks. E.g. `['@myorg/lazy-project/component/*', '@myorg/other-project']` |
| checkNestedExternalImports | _boolean_ | _false_ | Enable to enforce the check for banned external imports in the nested packages. Check [Dependency constraits](#dependency-constraits) for more information |
| enforceBuildableLibDependency | _boolean_ | _false_ | Enable to restrict the buildable libs from importing non-buildable libraries |
| depConstraints | _Array<object>_ | _[]_ | List of dependency constraints between projects |
| allow | _Array<string>_ | _[]_ | List of imports that should be allowed without any checks |
| allowCircularSelfDependency | _boolean_ | _false_ | Disable check for self circular dependency when project imports from itself via alias path |
| banTransitiveDependencies | _boolean_ | _false_ | Ban import of dependencies that were not specified in the root or project's `package.json` |
| ignoredCircularDependencies | _Array<[string, string]>_ | _[]_ | List of project pairs that should be skipped from `Circular dependencies` checks, including the self-circular dependency check. E.g. `['feature-project-a', 'myapp']`. Project name can be replaced by catch all `*` for more generic matches. |
| checkDynamicDependenciesExceptions | _Array<string>_ | _[]_ | List of imports that should be skipped for `Imports of lazy-loaded libraries forbidden` checks. E.g. `['@myorg/lazy-project/component/*', '@myorg/other-project']` |
| checkNestedExternalImports | _boolean_| _false_ | Enable to enforce the check for banned external imports in the nested packages. Check [Dependency constraits](#dependency-constraits) for more information |
| enforceBuildableLibDependency | _boolean_ | _false_ | Enable to restrict the buildable libs from importing non-buildable libraries |
| depConstraints | _Array<object>_ | _[]_ | List of dependency constraints between projects |
### Dependency constraints
The `depConstraints` is an array of objects representing the constraints defined between source and target projects. A constraint must include `sourceTag` or `allSourceTags`. The constraints are applied with **AND** logical operation - for given `source` project the resulting constraints would be **all** that match its tags.
The `depConstraints` is an array of objects representing the constraints defined between source and target projects. A
constraint must include `sourceTag` or `allSourceTags`. The constraints are applied with **AND** logical operation - for
a given `source` project the resulting constraints would be **all** that match its tags.
@@ -68,7 +68,8 @@ The `@nx/gradle` is configured in the `plugins` array in `nx.json`.
"options": {
"testTargetName": "test",
"classesTargetName": "classes",
"buildTargetName": "build"
"buildTargetName": "build",
"ciTargetName": "test-ci"
}
}
]
@@ -77,6 +78,23 @@ The `@nx/gradle` is configured in the `plugins` array in `nx.json`.
Once a Gradle configuration file has been identified, the targets are created with the name you specify under `testTargetName`, `classesTargetName` or `buildTargetName` in the `nx.json` `plugins` array. The default names for the inferred targets are `test`, `classes` and `build`.
### Splitting E2E Tests
The `@nx/gradle` plugin will automatically split your e2e tasks by file if you provide a `ciTargetName`. You can read more about the Atomizer feature [here](/ci/features/split-e2e-tasks). This will create a target with that name which can be used in CI to run the tests for each file in a distributed fashion.
To view inferred tasks for a project, open the [project details view](/features/explore-graph#explore-projects-in-your-workspace) in Nx Console or run `nx show project my-project --web` in the command line.
@@ -65,6 +65,24 @@ The `@nx/playwright/plugin` is configured in the `plugins` array in `nx.json`.
The `targetName` and `ciTargetName` options control the name of the inferred Playwright tasks. The default names are `e2e` and `e2e-ci`.
### Splitting E2E Tests
The `@nx/playwright/plugin` will automatically split your e2e tasks by file if you provide a `ciTargetName`. You can read more about the Atomizer feature [here](/ci/features/split-e2e-tasks). This will create a target with that name which can be used in CI to run the tests for each file in a distributed fashion.
```json {% fileName="nx.json" %}
{
"plugins": [
{
"plugin": "@nx/playwright/plugin",
"options": {
"targetName": "e2e",
"ciTargetName": "e2e-ci"
}
}
]
}
```
### Splitting E2E tasks by file
The `@nx/playwright/plugin` will automatically split your e2e tasks by file. You can read more about this feature [here](/ci/features/split-e2e-tasks).
"description":"Reporter to use, comma-separated, can be 'list', 'line', 'dot', 'json', 'junit', 'null', 'github', 'html', 'blob'. To configure reporter options, use the playwright configuration."
"description":"Common Reporter values to use, comma-separated, 'list', 'line', 'dot', 'json', 'junit', 'null', 'github', 'html', 'blob'. To configure reporter options, use the playwright configuration."
"description":"Generates a `package.json` and pruned lock file with the project's `node_module` dependencies populated for installing in a container. If a `package.json` exists in the project's directory, it will be reused with dependencies populated."
},
"skipPackageManager":{
"type":"boolean",
"description":"Do not add a `packageManager` entry to the generated package.json file. Only works in conjunction with `generatePackageJson` option."
},
"transformers":{
"type":"array",
"description":"List of TypeScript Compiler Transfomers Plugins.",
"description":"Learn how to efficiently distribute tasks across machines to take full advantage of parallelization. Nx Agents make this a trivial task.",
Nx Cloud AI offers a suite of features designed to **enhance your development workflow with AI-driven capabilities**. These tools assist in troubleshooting, optimizing resource allocation, and improving your overall development process.
- **[Explain with AI](/ci/features/explain-with-ai)** - This feature uses AI to provide detailed explanations about failed tasks.
- **Automatic Resource Allocation** (Coming Soon) - This upcoming feature will use custom AI/ML models to dynamically allocate resources based on your project’s specific needs. It optimizes performance by efficiently assigning Nx Agents to achieve target durations for main and PR branches.
## Enable Nx Cloud AI Features
To enable AI features for your organization, go to your organization's settings on [Nx Cloud](https://cloud.nx.app/orgs?utm_source=nx.dev&utm_campaign=ai) and select the organization where you want to enable AI.
In the **settings** menu, find the "AI Features" section and toggle it to "On".
Ensure that you **accept the AI terms** to start using the AI features.
{% callout type="info" title="AI Features Availability" %}
AI features are available only for the [Nx Cloud Pro plan](/pricing). If you are on the Hobby plan, you can start a free trial to test AI features in your workspace.
{% /callout %}
### Enable AI Features for Enterprise On-Prem Installations
To enable AI features for enterprise on-prem installations, add the following configuration to your `helm-values.yaml` file:
```yaml
nxApi
deployment:
env:
- name:NX_CLOUD_AI_ENABLED
value:'true'
frontend
deployment:
env:
- name:OPENAI_SECRET_KEY
valueFrom:
secretKeyRef:
name:open-ai-secrets
key:OPENAI_SECRET_KEY
- name:NX_CLOUD_AI_ENABLED
value:'true'
```
Ensure your OpenAI secret key is correctly configured to provide the necessary credits for `gpt-3.5-turbo` and `gpt-4`.
### Regional Availability
This feature is not available for the EU cluster in public cloud installations due to regional restrictions. However, on-prem customers in the EU can still use this feature by providing their own OpenAI secret key and enabling the required environment variables.
@@ -251,7 +251,7 @@ If we don't use the `nx affected` command in CI, no matter how our repo is struc
Note that the 50% chance of any project being modified is an arbitrary number. If we had picked a lower chance of being modified all the expected values would decrease as well. Every repository is different, but this illustrates that a flatter structure will help speed up your CI pipeline.
{% disclosure title="The Math Behind the Expected Number of Affected Projects" %}
{% callout title="The Math Behind the Expected Number of Affected Projects" type="deepdive" %}
**Definitions:**
@@ -290,7 +290,7 @@ Note that the 50% chance of any project being modified is an arbitrary number. I
To use AI in Nx Cloud, you need to enable AI features in your organization settings. This will unlock advanced capabilities designed to enhance your development workflow.
### How to Enable AI Features
1.**Navigate to Organization Settings**:
- Go to your [Nx Cloud dashboard](https://cloud.nx.app/orgs?utm_source=nx.dev&utm_campaign=ai).
- Select your organization from the list.
- Access the settings by clicking on the settings icon.
2.**Enable AI Features**:
- In the settings menu, locate the **AI Features** section.
- Toggle the setting to **On**.
3.**Accept AI Terms**:
- Once the AI features are enabled, a terms and conditions prompt will appear.
- Review and accept the terms and conditions related to AI usage to proceed.
### AI Driven Capabilities
Once AI features are enabled, you gain access to several powerful tools designed to optimize your development process:
#### Explain with AI
This feature leverages AI to provide detailed explanations and insights about failed tasks. [Learn more about "Explain with AI" here.](/ci/troubleshooting/explain-with-ai)
#### Automatic Resource Allocation (Coming Soon)
This feature leverages custom AI/ML models to dynamically allocate resources based on your project’s specific needs. It optimizes performance by efficiently assigning Nx Agents to achieve target durations for main and PR branches.
### Transform Your Workflow
By enabling AI features in Nx Cloud, you’re setting your organization up for a more intelligent and efficient development workflow. Stay tuned for the release of these powerful AI driven tools and take your development process to the next level.
...which always runs tasks on the same amount of machines, you can also have Nx Cloud scale the number of agents based on the size of your PR. Specify the number and type of agents to use for small, medium and large changesets by creating a yaml file like this:
This works great but may not be the most cost-effective way to run your tasks. The goal is to **balance cost and speed**. For example, you might want to run a small PR on a few agents to save costs, but use many agents for a large PR to get the fastest possible build time.
## Configure Dynamic Agents based on PR size
Instead of using a static configuration of agents (like the one shown above), you can also configure to use a different number and type of agents based on the size of your PR.
Create a file called `dynamic-changesets.yaml` in the `.nx/workflows` directory of your repo.
{% callout type="note" title="How is the size of the PR determined?" %}
{% callout type="deepdive" title="How is the size of the PR determined?" %}
To determine the size of the PR, Nx Cloud calculates the relationship between the number of [affected projects](/ci/features/affected) and the total number of projects in the workspace. It then assigns it to one of the three categories: small, medium, or large.
{% /callout %}
You can then reference it in your CI pipeline configuration:
Now PRs that affect a small percentage of the repo will run on 3 agent, mid-size PRs will use 6 agents and large PRs will use 10 agents. This feature helps save costs on the smaller PRs while maintaining the high performance necessary for large PRs.
Now, PRs that affect a small percentage of the repo will run on 3 agents, mid-size PRs will use 6 agents, and large PRs will use 10 agents. This feature helps save costs on smaller PRs while maintaining the high performance necessary for large PRs.
"Explain with AI" helps you understand complex errors more quickly by providing AI-powered error resolution steps. This is made possible by using additional context from Nx targets and metadata, allowing for more accurate and relevant responses.
## Enable Explain with AI
To use the "Explain with AI" feature, you need to [enable AI features for your organization](/ci/concepts/nx-cloud-ai#enable-nx-cloud-ai-features). In the **settings** menu, locate the "AI Features" section and toggle it to "On".
AI features are available only for the [Nx Cloud Pro plan](/pricing). If you are on the Hobby plan, you can start a free trial to test AI features in your workspace.
Sometimes there are tasks in CI that can fail or succeed without any related code changes. These tasks are called flaky tasks. Because the cause of the flakiness can be difficult to determine, developers will typically re-run CI in the hopes that another run will cause the task to succeed and allow them to merge their PR. Every time a developer has to do this, it is harming their productivity and the productivity of the company as a whole.
Tasks that fail only sometimes and only in certain environments are called "flaky tasks". They are enourmously time consuming to identify and debug. Nx Cloud can **reliably detect flaky tasks** and **automatically schedule them to be re-run** on a different agent.
Nx is perfectly positioned to detect which tasks are flaky and automatically re-run the flaky task in a different agent so that developers can have confidence that a failed CI pipeline is a real failure.
Ideally as a developer you don't even notice flaky tasks any more as they're automatically re-run and solved for you.
## Identify Flaky Tasks
## Enable Flaky Task Detection
Nx creates a hash of all the inputs for a task whenever it is run. If Nx ever encounters a task that fails with a particular set of inputs and then succeeds with those same inputs, Nx knows for a fact that the task is flaky. Nx can't know with certainty when the task has been fixed to no longer be flaky, so if a particular task has no flakiness incidents for 2 weeks, the `flaky` flag is removed for that task.
Flaky Task Detection is enabled by default if your workspace is connected to Nx Cloud and leverages [Nx Agents](/ci/features/distribute-task-execution).
To connect your workspace to Nx Cloud run:
```shell
npx nx connect
```
See the [connect to Nx Cloud recipe](/ci/intro/connect-to-nx-cloud) for all the details.
## How Nx Identifies Flaky Tasks
Nx leverages its cache mechanism to identify flaky tasks.
- Nx creates a **hash of all the inputs** for a task whenever it is run.
- If Nx ever encounters a task that fails with a particular set of inputs and then succeeds with those same inputs, Nx **knows for a fact that the task is flaky**.
Nx can't know with certainty when the task has been fixed to no longer be flaky, so if a particular task has **no flakiness incidents for 2 weeks**, the `flaky` flag is removed for that task.
In this image, the `e2e-ci--src/e2e/app.cy.ts` task is a flaky task that has been automatically retried once. There is a `1 retry` indicator to show that it has been retried and, once expanded, you can see tabs that contain the logs for `Attempt 1` and `Attempt 2`. With this UI, you can easily compare the output between a successful and unsuccessful run of a flaky task.
## Automatically Re-run Flaky Tasks
When a flaky task fails in CI with [distributed task execution](/ci/features/distribute-task-execution) enabled, Nx will **automatically send that task to a different agent** and run it again (up to 2 tries in total). Its important to run the task on a different agent to ensure that the agent itself or the other tasks that were run on that agent are not the reason for the flakiness.
## Manually Mark a Task as Flaky or Not Flaky
If you suspect that a task is flaky, but Nx has not confirmed it yet, you can manually mark it as `likely flaky` from the run details screen. Failed tasks that are not flaky will have a button that says `Mark task as likely flaky`.
If you suspect that a task is flaky, but Nx has not confirmed it yet, you can manually **mark it as likely flaky** from the run details screen. Failed tasks that are not flaky will have a button that says **"Mark task as likely flaky"**.
Once you've resolved the issue that caused a task to be flaky, you can immediately mark the task as not flaky by clicking on `Mark task as no longer flaky` on the same run details screen.
Once you've resolved the issue that caused a task to be flaky, you can immediately mark the task as not flaky by clicking on **"Mark task as no longer flaky"** on the same run details screen.
## Re-run Flaky Tasks
When a flaky task fails in CI with [distributed task execution](/ci/features/distribute-task-execution) enabled, Nx will automatically send that task to a different agent and run it again (up to 2 tries in total). Its important to run the task on a different agent to ensure that the agent itself or the other tasks that were run on that agent are not the reason for the flakiness.
In almost every codebase, e2e tests are the largest portion of the CI pipeline. Typically, e2e tests are grouped by application so that whenever an application's code changes, all the e2e tests for that application are run. These large groupings of e2e tests make caching and distribution less effective. Also, because e2e tests deal with a lot of integration code, they are at a much higher risk to be flaky.
End-to-end (e2e) tests are often large, monolithic tasks that can take a considerable amount of time to execute. As a result, teams often push them to a nightly or even weekly build rather than running them for each PR. This approach is suboptimal as it increases the risk of merging problematic PRs.
You could manually address these problems by splitting your e2e tests into smaller tasks, but this requires developer time to maintain and adds additional configuration overhead to your codebase. Or, you could allow Nx to automatically split your e2e tests by file. Doing this will split your large e2e tasks into smaller, atomized tasks.
Manually splitting large e2e test projects can be complex and require ongoing maintenance. Nx's Atomizer solves this by **automatically generating runnable targets for e2e tests for each spec file**. Instead of one large e2e task, you get multiple smaller e2e tasks that can be run individually. This allows for:
## Set up
- parallelization across multiple machines with [Nx Agents](/ci/features/distribute-task-execution)
- faster [flakiness detection & retries](/ci/features/flaky-tasks) by isolating and re-running only the failed tests
To enable atomized tasks, you need to turn on [inferred tasks](/concepts/inferred-tasks#existing-nx-workspaces) for the [@nx/cypress](/nx-api/cypress#splitting-e2e-tasks-by-file), [@nx/playwright](/nx-api/playwright#splitting-e2e-tasks-by-file), [@nx/jest](/nx-api/jest#splitting-e2e-tests) or [@nx/gradle](/nx-api/gradle) plugins. Run this command to set up inferred tasks:
## Enable Automated e2e Task Splitting
### Step 1: Connect to Nx Cloud
To use **automated e2e task splitting**, you need to connect your workspace to Nx Cloud (if you haven't already).
```shell
npx nx connect
```
See the [connect to Nx Cloud recipe](/ci/intro/connect-to-nx-cloud) for all the details.
### Step 2: Add the Appropriate Plugin
Run this command to set up inferred tasks and enable task splitting for each plugin:
{% tabs %}
{% tab label="Cypress" %}
@@ -39,7 +54,17 @@ nx add @nx/jest
This command will register the appropriate plugin in the `plugins` array of `nx.json`.
## Manual Configuration
If you upgraded Nx from an older version, ensure that [inferred tasks](/concepts/inferred-tasks#existing-nx-workspaces) are enabled in `nx.json`:
```json {% fileName="nx.json" %}
{
...
// turned on by default; just make sure it is not set to false
useInferencePlugins: true
}
```
## Update an Existing e2e Project to use Automated Task Splitting
If you are already using the `@nx/cypress`, `@nx/playwright`, or `@nx/jest` plugin, you need to manually add the appropriate configuration to the `plugins` array of `nx.json`. Follow the instructions for the plugin you are using:
@@ -47,15 +72,21 @@ If you are already using the `@nx/cypress`, `@nx/playwright`, or `@nx/jest` plug
@@ -365,39 +396,49 @@ nx show project myproject-e2e --web
{% /project-details %}
You'll see that there are tasks named `e2e`, `e2e-ci` and a task for each e2e test file.
{% /tab %}
{% /tabs %}
Developers can run all e2e tests locally with the `e2e` target:
If you configured Nx Atomizer properly, you'll see that there are tasks named `e2e`, `e2e-ci` and a task for each e2e test file.
During local development, you’ll want to continue using `e2e` as it is more efficient on a single machine.
```shell
nx e2e my-project-e2e
```
You can update your CI pipeline to run `e2e-ci`, which will automatically run all the inferred tasks for the individual e2e test files. Run it like this:
The `e2e-ci` task truly shines when configured and run on CI.
```shell
nx e2e-ci my-project-e2e
## Configure Automated Task Splitting on CI
Update your CI pipeline to run `e2e-ci`, which will automatically run all the inferred tasks for the individual e2e test files. Here's an example of a GitHub Actions workflow:
With more granular e2e tasks, all the other features of Nx become more powerful. Let's imagine a scenario where there are 10 spec files in a single e2e project and each spec file takes 3 minutes to run.
### Improved Caching
[Nx's cache](/ci/features/remote-cache) can be used for all the individual e2e tasks that succeeded and only the failed tasks need to be re-run. Without e2e task splitting, a single spec file failing would force you to re-run all the e2e tests for the project, which would take 30 minutes. With e2e task splitting, a single spec file that fails can be re-run in 3 minutes and the other successful spec file results can be retrieved from the cache.
### Better Distribution
[Distributed task execution](/ci/features/distribute-task-execution) allows your e2e tests to be run on multiple machines simultaneously, which reduces the total time of the CI pipeline. Without e2e task splitting, the CI pipeline has to take at least 30 minutes to complete because the one e2e task needs that long to finish. With e2e task splitting, a fully distributed pipeline with 10 agents could finish in 3 minutes.
### More Precise Flaky Task Identification
Nx Agents [automatically re-run failed flaky e2e tests](/ci/features/flaky-tasks) on a separate agent without a developer needing to manually re-run the CI pipeline. Leveraging e2e task splitting, Nx identifies the specific flaky test file - this way you can quickly fix the offending test file. Without e2e splitting, Nx identifies that at least one of the e2e tests are flaky - requiring you to find the flaky test on your own.
## Nx Cloud is Required to Run Atomized Tasks!
Running a group of atomized tasks on a single machine takes longer than running the large e2e task.
Nx Cloud [distributes](/ci/features/distribute-task-execution) the atomized tasks across multiple Nx agents in parallel.
When running locally or if you cannot use Nx Agents, it's better to use the non-atomized target instead (`e2e` in the example above).
Learn more about configuring your [CI provider by following these detailed recipes](/ci/recipes/set-up).
The permissions and membership define what developers can access on nx.app. They don't affect what happens when you run Nx commands locally or on CI. To manage that, you need to provision access tokens. To do that, go to Workspace Options / Manage Access Tokens.
The permissions and membership define what developers can access on [Nx Cloud](https://nx.app). They don't affect what happens when you run Nx commands locally or on CI. To manage that, you need to provision access tokens. To do that, go to Workspace Options / Manage Access Tokens.
"Explain with AI" in Nx Cloud leverages artificial intelligence to provide detailed explanations and insights for failed task outputs.
This feature helps developers understand complex errors quickly and offers suggestions for improvements, making the debugging process more efficient.
With the power of Nx Cloud, all explanations will be provided with additional context from Nx targets and metadata. This ensures that the AI responses have the correct context related to your failed task. This means that if you're trying to debug failed Gradle tasks, the AI will know to help you specifically with Gradle.
## What You Need to Enable This Feature
To use the "Explain with AI" feature, you need to [enable AI features for your organization](/ci/features/nx-cloud-ai).
- For enterprise on-prem customers, this feature is not enabled by default. You need to explicitly [enable AI features through environment flags](#how-to-enable-ai-features-for-enterprise-onprem-installations).
- For public cloud users, the AI feature is enabled automatically, [except for those in the EU due to regional restrictions](#regional-availability).
- This feature is not available for hobby (free) plans on Nx Cloud.
- Go through the AI-generated suggestions carefully.
- Apply the recommended changes to your codebase.
5.**Verify the Fix**:
- After making the changes, rerun the task to see if the issue is resolved.
6.**Mark answer as not helpful** (optional):
- If the suggested changes did not help you, click on "Set answer as not helpful". This allows us to continuously improve the responses.
## How to Enable AI Features for Enterprise On-Prem Installations
To enable AI features for enterprise on-prem installations, add the following configuration to your `helm-values.yaml` file:
```yaml
nxApi
deployment:
env:
- name:NX_CLOUD_AI_ENABLED
value:'true'
frontend
deployment:
env:
- name:OPENAI_SECRET_KEY
valueFrom:
secretKeyRef:
name:open-ai-secrets
key:OPENAI_SECRET_KEY
- name:NX_CLOUD_AI_ENABLED
value:'true'
```
Make sure your OpenAI secret key is correctly configured to provide the necessary credits for `gpt-3.5-turbo` and `gpt-4o`.
### Regional Availability
This feature is not available for the EU cluster in public cloud installations due to regional restrictions. However, on-prem customers in the EU can still use this feature by providing their own OpenAI secret key and enabling the required environment variables.
@@ -224,7 +224,7 @@ The affected command and Nx Replay help speed up the average CI time, but there
The Nx Agents feature
- takes a command (e.g. `run-many -t build lint test e2e-ci`) and splits it into individual tasks which it then distributes across multiple agents
- takes a command (e.g. `nx affected -t build lint test e2e-ci`) and splits it into individual tasks which it then distributes across multiple agents
- distributes tasks by considering the dependencies between them; e.g. if `e2e-ci` depends on `build`, Nx Cloud will make sure that `build` is executed before `e2e-ci`; it does this across machines
- distributes tasks to optimize for CPU processing time and reduce idle time by taking into account historical data about how long each task takes to run
- collects the results and logs of all the tasks and presents them in a single view
@@ -261,7 +261,7 @@ jobs:
# Prepend any command with "nx-cloud record --" to record its logs to Nx Cloud
# - run: pnpm exec nx-cloud record -- echo Hello World
The [`nx affected` command](/ci/features/affected) will run the specified tasks only for projects that have been affected by a particular PR, which can save a lot of time as repositories grow larger.
@@ -189,7 +189,7 @@ The affected command and Nx Replay help speed up the average CI time, but there
The Nx Agents feature
- takes a command (e.g. `run-many -t build lint test e2e-ci`) and splits it into individual tasks which it then distributes across multiple agents
- takes a command (e.g. `nx affected -t build lint test e2e-ci`) and splits it into individual tasks which it then distributes across multiple agents
- distributes tasks by considering the dependencies between them; e.g. if `e2e-ci` depends on `build`, Nx Cloud will make sure that `build` is executed before `e2e-ci`; it does this across machines
- distributes tasks to optimize for CPU processing time and reduce idle time by taking into account historical data about how long each task takes to run
- collects the results and logs of all the tasks and presents them in a single view
@@ -208,9 +208,9 @@ jobs:
with:
fetch-depth: 0
- uses: pnpm/action-setup@v2
- uses: pnpm/action-setup@v4
with:
version: 8
version: 9
# This enables task distribution via Nx Cloud
# Run this command as early as possible, before dependencies are installed
@@ -229,7 +229,7 @@ jobs:
# Prepend any command with "nx-cloud record --" to record its logs to Nx Cloud
# - run: pnpm exec nx-cloud record -- echo Hello World
# Nx Affected runs only tasks affected by the changes in this PR/commit. Learn more: https://nx.dev/ci/features/affected
@@ -54,11 +54,11 @@ For more information on the different types of inputs and how to configure input
## What is Cached
Nx works on the process level. Regardless of the tools used to build/test/lint/etc.. your project, the results are cached.
Nx cache works on the process level. Regardless of the tools used to build/test/lint/etc.. your project, the results are cached. This includes:
It collects terminal output when running tasks. All the terminal output is cached and then replayed during a cache hit.
Nx can also cache the files generated by a task. The list of files/folders is listed in the `outputs` property of the project's `package.json` or `project.json`:
- **Terminal output:** The terminal output generated when running a task. This includes logs, warnings, and errors.
- **Task artifacts:** The output files of a task defined in the [`outputs` property of your project configuration](/recipes/running-tasks/configure-outputs). For example the build output, test results, or linting reports.
- **Hash:** The hash of the inputs to the computation. The inputs include the source code, runtime values, and command line arguments. Note that the hash is included in the cache, but the actual inputs are not.
@@ -74,15 +74,13 @@ More details about how to override task configuration is available in these reci
## Existing Nx Workspaces
If you have an existing Nx Workspace and upgrade to Nx 18, the migration generator will automatically add `NX_ADD_PLUGINS=false` to your `.env` file. This environment variable allows you to continue to use Nx without inferred tasks. Alternatively, you can set the `useInferencePlugins` property to `false` in `nx.json`.
If you have an existing Nx Workspace and upgrade to the latest Nx version, a migration will automatically set `useInferencePlugins` to `false` in `nx.json`. This property allows you to continue to use Nx without inferred tasks.
We are working on creating migrations for existing workspaces to start switching to inferred tasks, where desired.
When `NX_ADD_PLUGINS` or `useInferencePlugins` is `false`:
When `useInferencePlugins` is `false`:
1. A newly generated project will have all targets defined with executors - not with inferred tasks.
2. Running `nx add @nx/some-plugin` will not create a plugin entry for `@nx/some-plugin` in the `nx.json` file. (So that plugin will not create inferred tasks.)
If your `.env` file is ignored by git, ensure that everyone in your organization sets `NX_ADD_PLUGINS=false`. This could be done by updating a shared `.env` file or setting the environment variable in everyone's `.bashrc` file.
If you want to **migrate** your projects to use inferred tasks, follow the recipe for [migrating to inferred tasks](/recipes/running-tasks/convert-to-inferred).
Even once a repository has fully embraced inferred tasks, `project.json` and executors will still be useful. The `project.json` file is needed to modify inferred task options and to define tasks that can not be inferred. Some executors perform tasks that can not be accomplished by running a tool directly from the command line (i.e. [TypeScript batch mode](/recipes/tips-n-tricks/enable-tsc-batch-mode)).
@@ -23,5 +23,5 @@ For example, plugins can accomplish the following:
{% cards %}
{% card title="Official Plugins" description="The API documentation for Nx Plugins maintained by the Nx core team" type="documentation" url="/nx-api" /%}
{% card title="Community Plugins" description="Browse the plugin registry to discover plugins created by the community" type="documentation" url="/plugin-registry" /%}
{% card title="Build Your Own Plugin" description="Build your own plugin to use internally or share with the community" type="documentation" url="/extending-nx/tutorials/create-plugin" /%}
{% card title="Build Your Own Plugin" description="Build your own plugin to use internally or share with the community" type="documentation" url="/extending-nx/tutorials/organization-specific-plugin" /%}
Keeping your tooling up to date is crucial for the health of your project. Tooling maintenance work can be tedious and time consuming, though. The **Nx migrate** functionality provides a way for you to
- automatically update your **`package.json` dependencies**
- migrate your **configuration files** (e.g. Jest, ESLint, Nx config)
- **adjust your source code** to match the new versions of packages (e.g., migrating across breaking changes)
{% youtube src="https://youtu.be/o-6jb78uuP0" title="Remote Caching with Nx Replay" /%}
Rebuilding and retesting the same code repeatedly is costly. Nx offers a sophisticated and battle-tested computation caching system that ensures **code is never rebuilt twice**. This:
- drastically **speeds up your task execution times** while developing locally and even more [in CI](/ci/features/remote-cache)
**Nx Agents** let you distribute your CI across many machines with minimal configuration. It also comes with the following features:
Nx Agents is a **distributed task execution system that intelligently allocates tasks across multiple machines**, optimizing your CI pipeline for speed and efficiency. While using [Nx Affected](/ci/features/affected) and [remote caching (Nx Replay)](/ci/features/remote-cache) can significantly speed up your CI pipeline, you might still encounter bottlenecks as your codebase scales. Combining affected runs and remote caching with task distribution is key to maintaining low CI times. Nx Agents handles this distribution efficiently, avoiding the complexity and maintenance required if you were to set it up manually.
- [Dynamically allocate the number and size of agents](/ci/features/dynamic-agents) based on the size of the PR
- [Re-run flaky tasks](/ci/features/flaky-tasks) automatically whenever they fail in CI
- Automatically [split large e2e tasks](/ci/features/split-e2e-tasks) into smaller tasks that can be distributed more efficiently
## Making a Distributed CI Pipeline Is Hard
Nx Agents offer several key advantages:
The only way to speed up your CI pipeline while still running all the necessary tasks is to distribute those tasks across multiple machines. Unfortunately, doing distribution right is hard to set up and hard to maintain. These are just some concerns you have to account for:
-Choose how many machines to set up
-Set up each machine so that it is ready to execute tasks
-Ensure that tasks are run in the correct order
-Copy the output of certain tasks to the machines where those outputs are needed
- Shut down machines when there are no more tasks to run
- Shut down all the machines when the whole pipeline hits an error
- Make sure sensitive information is being handled securely on all machines
And each of these concerns will need to be reconsidered whenever the codebase changes. It would actually be best if they were reconsidered for every PR, because small PRs may not need as much distribution as large PRs.
## Nx Agents Make Distributing Tasks Simple
Nx Agents take care of all these concerns with a small initial configuration that does not need to be modified as your codebase changes. Your CI pipeline sends your tasks to be run on agent machines that Nx Cloud creates for you. All you need to do is specify how many agents and the type of agent. Then, when the pipeline is finished, your initial CI pipeline will contain all the logs and artifacts as if the tasks all ran on your main CI machine - but completed in a fraction of the time.
For a more thorough explanation of how Nx Agents optimizes your CI pipeline, read this [guide to parallelization and distribution in CI](/ci/concepts/parallelization-distribution).
- **Declarative Configuration:** No maintenance is required as your monorepo evolves, thanks to a declarative setup.
- **Efficient Task Replay:** By leveraging [remote caching](/ci/features/remote-cache), tasks can be replayed efficiently across machines, enhancing distribution speed.
-**Intelligent Task Distribution:** Tasks are distributed based on historical run times and dependencies, ensuring correct and optimal execution.
-**Dynamic Resource Allocation:** Agents are [allocated dynamically based on the size of the PR](/ci/features/dynamic-agents), balancing cost and speed.
-**Seamless CI Integration:** Easily adopt Nx Agents with your [existing CI provider](/ci/recipes/set-up), requiring minimal setup changes.
-**Simple Activation:** Enable distribution with just a [single line of code](#enable-nx-agents) in your CI configuration.
## Enable Nx Agents
To enable task distribution with Nx Agents, there are two requirements:
To enable task distribution with Nx Agents, make sure your Nx workspace is connected to Nx Cloud. If you haven't connected your workspace to Nx Cloud yet, run the following command:
1. Enable version control system integration. The integrations currently available are [GitHub](/ci/recipes/source-control-integration/github), [GitLab](/ci/recipes/source-control-integration/gitlab), [Bitbucket](/ci/recipes/source-control-integration/bitbucket) and [Azure DevOps](/ci/recipes/source-control-integration/azure-devops). These integrations can be enabled from your [Nx Cloud dashboard](https://nx.app).
2. Add a single line to your CI pipeline configuration.
Add the `start-ci-run` command to your CI pipeline configuration after checking out the repository and before installing `node_modules`:
# Run any nx commands as if running on a single machine
```shell
npx nx connect
```
The `--distribute-on` flag instructs Nx Cloud to distribute tasks across 8 agents of type `linux-medium-js`. `linux-medium-js` is the name of the launch template that will be used to provision the agent. Use on of the [default launch templates](https://github.com/nrwl/nx-cloud-workflows/blob/main/launch-templates/linux.yaml) or create your own [custom launch template](/ci/reference/launch-templates).
Check out the [connect to Nx Cloud recipe](/ci/intro/connect-to-nx-cloud) for more details.
Then, adjust your CI pipeline configuration to **enable task distribution**. If you don't have a CI config yet, you can generate a new one using the following command:
```shell
npx nx g ci-workflow
```
The key line in your CI config is the `start-ci-run` command:
# Nx Affected runs only tasks affected by the changes in this PR/commit. Learn more: https://nx.dev/ci/features/affected
- run: pnpm exec nx affected -t lint test build
```
This command tells Nx Cloud to:
- Start a CI run (`npx nx-cloud start-ci-run`)
- Collect all Nx commands that are being issued (e.g., `pnpm exec nx affected -t lint test build`) and
- Distribute them across 3 agents (`3 linux-medium-js`) where `linux-medium-js` is a predefined agent [launch template](/ci/reference/launch-templates).
### Configure Nx Agents on your CI Provider
Every organization manages their CI/CD pipelines differently, so the guides don't cover org-specific aspects of CI/CD (e.g., deployment). They mainly focus on configuring Nx correctly using Nx Agents and [Nx Replay](/ci/features/remote-cache).
_**Nx Agents are declarative**_ in that you only specify the number of agents and the type of agent you want to use. Nx Cloud then picks up the Nx commands that are being issued on your CI and distributes them automatically. This results in **low maintenance and a much more efficient distribution strategy**. A non-declarative approach would be one where you define which tasks or projects get executed on which machine, requiring you to adjust the configuration as your codebase changes.
_**Nx Agents use a task-centric approach**_ to distribution. Current CI systems use VM-centric approaches, where tasks must be predefined for specific machines, often leading to inefficiencies as your codebase grows. Instead of defining which tasks run on which machine upfront, Nx Agents dynamically process tasks based on availability and task dependencies/ordering. Tasks are picked up by agents based on the task's required processing time (from historical data) and task dependency/ordering (from the Nx graph). This results in a faster and resource efficient processing, and is also more resilient to failures since any other agent can pick up work if one agent fails during bootup. Read more [on our blog post](/blog/reliable-ci-a-new-execution-model-fixing-both-flakiness-and-slowness).
_**Nx Agents are cost and resource-efficient**_ as the tasks are automatically distributed - **optimizing for speed while also ensuring resource utilization is high** and idle time is low. You can also [dynamically adjust the number of agents](/ci/features/dynamic-agents) based on the size of the PR, and we're working on [some more AI-powered features](/ci/concepts/nx-cloud-ai) to optimize this even further. In addition, [remote caching](/ci/features/remote-cache) guarantees tasks are not run twice, and artifacts are shared efficiently among agents.
_**Nx Agents are non-invasive**_ in that you don't need to completely overhaul your existing CI configuration or your Nx workspace to use them. You can start using Nx Agents with your existing CI provider by adding the `nx-cloud start-ci-run...` command mentioned previously. In addition, all artifacts and logs are played back to the main job so you can keep processing them as if they were run on the main job. Hence, your existing post-processing steps should still keep working as before.
For a more thorough explanation of how Nx Agents optimize your CI pipeline, read this [guide to parallelization and distribution in CI](/ci/concepts/parallelization-distribution).
## Nx Agents Features
@@ -66,21 +107,10 @@ The `--distribute-on` flag instructs Nx Cloud to distribute tasks across 8 agent
{% /cards %}
## CI/CD Guides
Every organization manages their CI/CD pipelines differently, so the guides don't cover org-specific aspects of
CI/CD (e.g., deployment). They mainly focus on configuring Nx correctly using Nx Agents and [Nx Replay](/ci/features/remote-cache).
Note that only cacheable operations can be distributed because they have to be replayed on the main job.
## Relevant Repositories and Examples
By integrating Nx Agents into your CI pipeline, you can significantly reduce build times, optimize resource use, and maintain a scalable, efficient development workflow.
- [Reliable CI: A New Execution Model Fixing Both Flakiness and Slowness](/blog/reliable-ci-a-new-execution-model-fixing-both-flakiness-and-slowness)
- [Nx: On how to make your CI 16 times faster with a small config change](https://github.com/vsavkin/interstellar)
Code generators are like automation scripts designed to streamline your workflow. Essentially, they are TypeScript functions that accept parameters and help boost your productivity by:
- Allowing you to **scaffold new projects** or **augment existing projects** with new features, like [adding Storybook support](/nx-api/storybook#generating-storybook-configuration)
By default Nx [caches task computations locally](/features/cache-task-results). However, to benefit from the cache across your team and in particular on CI, the computation cache can also be distributed across multiple machines.
{% youtube
src="https://youtu.be/NF1__N_snog"
title="Remote Caching with Nx Replay"
/%}
The **Nx Replay** feature of Nx Cloud is a fast, secure and zero-config implementation of remote caching.
Repeatedly rebuilding and retesting the same code is costly — not just in terms of wasted resources, but also in terms of developer time. To solve this, Nx includes a sophisticated computation caching system that ensures **code is never rebuilt twice**, saving you both time and resources.
In this diagram, Teika runs the build once on his machine, then CI, Kimiko and James can use the cached artifact from Teika instead of re-executing the same work.
By default, Nx [caches task computations locally](/features/cache-task-results), but the biggest benefit comes from **sharing this cache across your team and in CI**.
## Setting Up Nx Cloud
- **Zero config** and **secure** by default
- Drastically **speeds up task execution times** during local development, and more critically in CI
- **Saves money on CI/CD costs** by reducing the number of tasks that need to be executed (we observed 30-70% faster CI & half the cost)
To use **Nx Replay** you need to connect your workspace to Nx Cloud. See the [connect to Nx Cloud recipe](/ci/intro/connect-to-nx-cloud).
Nx **restores terminal output, along with the files and artifacts** created from running the task (e.g., your build or dist directory). If you want to learn more about the conceptual model behind Nx's caching, read [How Caching Works](/concepts/how-caching-works).
## See Remote Caching in Action
## Configure Remote Caching
To see the remote cache in action, run:
To use **Nx Replay**, you need to connect your workspace to Nx Cloud (if you haven't already).
NX Successfully ran target build for project header (664ms)
Nx read the output from the cache instead of running the command for 1 out of 1 tasks.
Nx Cloud made it possible to reuse header: https://nx.app/runs/P0X6ZGTkqZ
```shell
npx nx connect
```
## Benefits of Nx Replay
See the [connect to Nx Cloud recipe](/ci/intro/connect-to-nx-cloud) for all the details.
There are two ways that Nx Replay directly benefits your organization.
## Why use Remote Caching (Nx Replay)?
### 1. Speed Up CI Pipelines for Modified PRs
Nx Replay directly benefits your organization by:
The first time a PR goes through the CI pipeline, the [affected](/ci/features/affected) command provides most of the time savings. The `affected` command compares the PR against the `main` branch and only runs tasks for projects that could have been affected by the code changes. Unfortunately, all the projects affected by the first CI pipeline for a PR will continue to be affected by all future commits to that PR. This is because `affected` compares the current commit with the `main` branch every time.
- **Speeding up CI pipelines:** With Nx Replay, tasks that have already been executed in a PR’s initial CI pipeline run can **reuse cached results in subsequent runs**. This reduces the need to re-run unaffected tasks, significantly speeding up the CI process for modified PRs. This benefit complements the [affected command](/ci/features/affected), which optimizes pipelines by only running tasks for projects that could be impacted by code changes.
With Nx Replay enabled, any tasks that were run during the first pipeline and not affected by the second commit would reuse the cached results from the first pipeline instead of re-running the task. This gives subsequent pipeline runs a mechanism similar to affected that will [reduce the wasted time in CI](/ci/concepts/reduce-waste).
- **Boosting local developer efficiency:** Depending on [how cache permissions](/ci/recipes/security/access-tokens) are set for your workspace, developers can reuse cached results from CI on their local machines. As a result, tasks like builds and tests can complete instantly if they were already executed in CI. This accelerates developer workflows without any extra steps required.
### 2. Reuse Cached Results from CI on Developer Machines
- **Enabling Nx Agents:** Nx Replay is crucial for [Nx Agents](/ci/features/distribute-task-execution) to function efficiently. Nx Agents leverage remote caching as a **transport mechanism** for transferring task artifacts between machines as it distributes tasks. When a task depends on another task that may have been executed on a different agent, Nx Replay ensures the necessary artifacts are transferred seamlessly. This allows each agent to execute only its assigned tasks while relying on cached results for dependencies, ensuring tasks run only once and are shared across all agents. [Learn more about Nx Agents](/ci/features/distribute-task-execution).
If a task has been executed in CI, a developer running that same task locally can reuse the task result instead of actually running the task. Here are a couple common scenarios where this happens:
## What gets stored?
1. A developer pulls the latest code from `main` and rebuilds an application. The build finishes instantly and they're ready to start working.
2. A developer checks out someone else's PR branch to help troubleshoot a problem. They run the tests and all the successful tests finish instantly. They can focus their debugging time on the few tests that are still failing.
Nx Cloud stores the following:
The best part about Nx Replay is that developers will experience the benefits of it without needing to remember to use it. Some of their tasks will just finish much faster than they normally do.
- **Terminal output:** The terminal output generated when running a task. This includes logs, warnings, and errors.
- **Task artifacts:** The output files of a task defined in the [`outputs` property of your project configuration](/recipes/running-tasks/configure-outputs). For example, the build output, test results, or linting reports.
- **Hash:** The hash of the inputs to the computation. The inputs include the source code, runtime values, and command line arguments. Note that the hash is included in the cache, but the actual inputs are not.
## Nx Replay Enables Nx Agents
Learn more about [how caching works](/concepts/how-caching-works#what-is-cached).
One more indirect benefit of Nx Replay is that it is critical to the way [Nx Agents](/ci/features/distribute-task-execution) is built. Nx Agents relies heavily on the remote cache in order to ensure that all task artifacts are present on the agent machines where they are needed. Each agent can naively run the dependencies for the tasks it is assigned and rely on Nx Replay to retrieve the cached tasks results for those tasks. Nx Replay ensures that each task will only run on one agent and the results of that task will be shared with every agent that needs them.
## Security in Remote Caching
## Skipping Cloud Cache
Since we work with many large corporations (including banks, insurance companies, and governments), we take security very seriously. Nx Cloud provides several features to ensure your data remains safe and secure:
Similar to how `--skip-nx-cache` will instruct Nx not to use the local cache, passing `--no-cloud` will tell Nx not to use the remote cache from Nx Cloud.
- **Immutability:** Each cache entry is immutable, meaning once an entry is created, it cannot be altered. This ensures that cached results cannot be tampered with by malicious parties, preventing the injection of vulnerabilities into your build process.
- **Access Control via Tokens:** Nx Cloud allows you to [control who can read from and write to the cache](/ci/recipes/security/access-tokens). For example, you can configure these settings to restrict cache write access to your CI pipeline while allowing all developers to only read.
- **End-to-End Encryption:** Nx Cloud supports end-to-end encryption to protect your data. Task artifacts are encrypted before being sent to the remote cache and decrypted when retrieved. This ensures that even if someone gains access to Nx Cloud servers, they cannot view your stored artifacts. For more details, visit the [encryption documentation](/ci/recipes/security/encryption).
- **Nx Enterprise (Self-Hosting and EU Regions):** For organizations with specific compliance or data residency requirements, Nx Enterprise offers the option to self-host Nx Cloud on your own infrastructure. Additionally, you can choose to host in EU regions, ensuring that your data complies with regional data protection laws. This is available to our [Nx Enterprise customers](/enterprise).
- **SOC Certification:** Nx and Nx Cloud are SOC Type 1 and Type 2 certified, providing an additional layer of assurance that your data is handled according to industry-standard security practices. For more details, you can visit our [security page](https://security.nx.app).
### Configure Caching Access
Caching access can be restricted in terms of read/write access. You can configure this in your [Nx Cloud dashboard](https://nx.app). Learn more about it [here](/ci/recipes/security/access-tokens).
## FAQ
### What if the remote cache is offline?
Nx Replay automatically syncs the remote cache to the local cache folder. As such, if the remote cache is not available, it will automatically fall back to the local cache or just run the task if it is not cached.
### Skipping Cloud Cache
To learn more about how to temporarily skip task caching, head over to [our corresponding docs page](/recipes/running-tasks/skipping-cache#skip-remote-caching-from-nx-cloud).
{% youtube src="https://youtu.be/aEdfYiA5U34" title="Run tasks with Nx" /%}
In a monorepo setup, you don't just run tasks for a single project; you might have hundreds to manage. To help with this, Nx provides a powerful task runner that allows you to:
- easily **run multiple targets** for multiple projects **in parallel**
@@ -9,7 +9,7 @@ Nx is a powerful open-source build system that provides tools and techniques for
- **Cache Locally & Remotely**: With [local](/features/cache-task-results) and [remote caching](/ci/features/remote-cache), Nx prevents unnecessary re-runs of tasks, saving you valuable dev time.
- **Split E2E Tests and Rerun Flaky Tests**: Nx [automatically splits](/ci/features/split-e2e-tasks) large e2e tests to distribute them across VMs. Nx can also automatically [identify and rerun flaky e2e tests](/ci/features/flaky-tasks).
- **Automate Dependency Updates**: if you leverage [Nx plugins](/concepts/nx-plugins) you gain additional features such as [code generation](/features/generate-code) and tools to [automatically upgrade](features/automate-updating-dependencies) your codebase and dependencies.
- **Make it Your Own**: Nx is highly customizable and extensible. Fine-tune it by [creating your own plugins](/extending-nx/intro/getting-started) and optionally [share them with the community](/extending-nx/tutorials/publish-plugin#publish-your-nx-plugin).
- **Make it Your Own**: Nx is highly customizable and extensible. Fine-tune it by [creating a plugin for your organization](/extending-nx/tutorials/organization-specific-plugin) or [creating a tooling plugin](/extending-nx/tutorials/tooling-plugin).
<!-- - **Monorepo and Single Projects**: Nx supports both, monorepos as well as single-project (standalone) workspaces. -->
This method of import allow you to work with the SVG the same way you would with any other React component. You can style it using CSS, styled-components, etc. The SVG component accepts a `title` prop, as well as any other props that the `svg` element accepts.
This method of import allow you to work with the SVG the same way you would with any other React component. You can style it using CSS, [styled-components](https://styled-components.com/), [TailwindCSS](https://tailwindcss.com/), etc. The SVG component accepts a `title` prop, as well as any other props that the `svg` element accepts.
Note that if you are using Next.js, you have to opt into this behavior. To import SVGs as React components with Next.js, you need to make sure that `nx.svgr` value is set to `true` in your Next.js application's `next.config.js` file:
{% callout type="note" title="Additional configuration may be required" %}
Note that SVGR is enabled by the `@nx/webpack` plugin by default. For other plugins, you will need to enable it on your own.
{% /callout %}
```javascript
module.exports=withNx({
### SVGR for Next.js
To import SVGs as React components with Next.js, you need to make sure that `nx.svgr` value is set to `true` in your Next.js application's `next.config.js` file:
3. Click the upload button and open the `profile.json` that was created. (Or drag the file into the window)
4. Expand each group to see the names of the tasks which were run
## Optimizing the Performance of Running Tasks
### Optimizing the Performance of Running Tasks
Now that you have visualized how the tasks were run, you can try tweaking things to make the process faster. Generate profiles after each tweak and compare the results.
1. Are there tasks that you did not expect to be necessary? Sometimes, more tasks are captured by a command than expected. Excluding them could free up workers for other tasks.
2. Try adding more workers. Did the new workers handle tasks while other workers were busy? This will likely result in faster runs.
3. Are a lot of the tasks waiting on a single task to be completed? Splitting that project into smaller projects may allow fewer projects and therefore tasks to depend on a single project/task. This will allow for more room to parallelize the tasks.
Nx offloads much of the heavy lifting to the [Nx Daemon](/concepts/nx-daemon), which helps speed up task execution. However, you might still encounter slowdowns, not during the task execution itself, but in the moments leading up to it when invoking tasks through Nx. This can often happen when you're using a large number of [Nx Plugins](/plugin-registry), whether they come from the core team or the community.
To investigate and optimize these slowdowns, you can use the `NX_PERF_LOGGING` [environment variable](/reference/environment-variables). This will give you detailed performance logs and more precise timings, allowing you to pinpoint where the delays occur.
Here's an example of running the `build` of the `admin` project with performance logging enabled:
@@ -61,6 +61,7 @@ executor to `@nx/angular:dev-server` as shown below:
...
"targets":{
"build":{
"dependsOn":["^build"],
"executor":"@nx/angular:webpack-browser",
"outputs":[
"{options.outputPath}"
@@ -91,6 +92,19 @@ executor to `@nx/angular:dev-server` as shown below:
},
```
{% callout type="note" title="Add Executor to Target Defaults" %}
If you'd like to avoid adding `"dependsOn": ["^build"]` to every application in your workspace that uses `@nx/angular:webpack-browser` you can add it to the `"targetDefaults"` section of the `nx.json`:
```json
"targetDefaults":{
"@nx/angular:webpack-browser":{
"dependsOn":["^build"]
}
}
```
{% /callout %}
## Running and serving incremental builds
To build an application incrementally use the following command:
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Jason Jean
