<!-- 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 #
<!-- 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 -->
In Yarn and PNPM Workspaces, the `nxViteTsPaths`'s `resolveId` is not
called because Vite has already tried to resolve the module.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Ensure the `nxViteTsPath`'s logic is run before vite's internal
resolver.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#20520
<!-- 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 setups using `/*` wildcards in ts path mappings error
out as they cannot resolve the module.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`/*` ts path mappings should still allow modules to be resolved
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#26765
<!-- 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#20003
<!-- 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. -->
"Hence we can easily import them into other libraries and our Angular
application. As an example, let's use the pre-generated
ProductsComponent component from our libs/products library."
It's a tutorial providing a React project example, I think "Angular" is
typing wrong
## Current Behavior
Hence we can easily import them into other libraries and our **Angular**
application. As an example, let's use the pre-generated
ProductsComponent component from our libs/products library.
## Expected Behavior
Hence we can easily import them into other libraries and our **React**
application. As an example, let's use the pre-generated
ProductsComponent component from our libs/products library.
This PR ensures that all dependencies are built before serving the Node
app.
<!-- 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
If users don't manually run `nx build <app>` first, then the
dependencies won't build because when `@nx/js:node` executor runs, it
uses `runExecutor` which skips dependencies.
## Expected Behavior
Set `dependsOn` on the `serve` target so run `<app>:build` first, which
would ensure dependencies are all built. Also add
`runBuildTargetDependencies: false` to the target options for
visibility, so users could toggle it on if they want to re-build deps
whenever there is a change (during watch). The option will slow things
down, so we still want it to be `false` by default.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#18964
<!-- 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 #
The current `@nx/react:app` generator does not take the `--js` option
into account. There are two problems:
1. `index.html` includes `main.tsx` not `main.jsx`.
2. `.js` files with JSX are invalid in Vite, and must be named `.jsx`.
This PR adds a new option to the `toJS` devkit util to preserve `.jsx`
rather than renaming them to `.js`. The vast majority of non-Vite React
projects will use `.js` and not `.jsx` (e.g. Next.js, Expo, Remix, etc.)
so we just want to apply this change to Vite only for now.
In the future we could enhance React generators to support `--jsx`, for
example.
## 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#20810
Introduced a new AI section with dark/light image support. Refactored component exports from arrow functions to named functions for better readability and consistency. Included minor adjustments to class names and style properties.
This PR fixes an issue where our `withNx` function for Next.js is
compiled with inlined `workspaceRoot` (to support container
environments). On Windows, we write the `.nx-helpers/with-nx.js` with
the following:
```js
workspaceRoot: 'C:\Users\user\projects\app',
```
The `\u` character result in a Node error: `Invalid Unicode escape
sequence`.
The fix is to escape `\` as `\\`, so when the file is written, the path
is valid and does not cause unicode errors.
<!-- 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#18824
<!-- 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
No docs for new config flag
## Expected Behavior
Docs 🎉
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#22259
<!-- 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
Some plugin docs don't make sense after project name and root changes
## Expected Behavior
They've been touched up
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#25191
<!-- 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
`documentation` is not cacheable. It is reran everytime someone tries to
push, including the following flow:
- git push, fails as docs changes found
- git commit -am "chore(repo): add docs"
- git push, runs full docs cycle again in pre-push hook
## Expected Behavior
`documentation` is cacheable, and avoids rerunning when no fs changes
are made
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
The package manager is detected based off of the relative `cwd` which in
most cases is `''`. This incorrectly goes off of the `cwd` of the
command rather than the location of the `package.json` file being
modified.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The package manager is detected based off the absolute path of the
directory containing the `package.json` file being modified. So if this
is the root, it will detect the package manager at the root rather than
the `cwd`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes https://github.com/nrwl/nx/issues/19831
<!-- 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 -->
having some command without npx before
````
nx .....
````
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Have npx on all command
````
npx nx .....
````
Co-authored-by: pikooli <>
<!-- 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 #
Taken from: https://github.com/nrwl/nx/pull/26560
## Currently
When you enter a space in the idea form it gets trimmed so users are
unable to add a proper sentence when submitting an idea.
## Expected
Users should be able to add spaces as they feel is necessary without
being restricted.
---------
Co-authored-by: Sarthak <130341942+Sarthak0085@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
agents.yaml are currently using a pinned version of v3.6
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
agents.yaml are using v4 of the workflow steps
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Plugins were not being loaded by vitest executor when calling
`startVitest` when using a vite config file with a custom name.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Correctly load the plugins found in the resolved config file, regardless
of the config file name
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#22001
<!-- 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 -->
`time` crate is locked to a version which fails to compile.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`time` crate is updated to a version which does not fail to compile.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## 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#23519
<!-- 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` and `remote` generators do not have an option to skip package
install.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Add the `skipPackageJson` flag to the remote and host generators
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## 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#8928
## Current Behavior
<!-- This is the behavior we have today -->
`axios@^1.6.0` is used.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`axios@^1.7.2` is used
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#26538
<!-- 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#23579
<!-- 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#26694
<!-- 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 -->
ESLint found too many warnings (maximum: -1).
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Nothing should be logged if maximum is set to -1
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
…dependency
<!-- 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 -->
A unhelpful error is thrown when someone specifies a local project as an
external dependency input.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
A helpful error is thrown when someone specifies a local projecft as an
external dependency input.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes https://github.com/nrwl/nx/issues/27088
<!-- 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#25122
Remove an old workaround added in https://github.com/nrwl/nx/pull/5807.
The issue it was addressing was fixed in the Angular CLI shortly after,
but the workaround was never removed.
<!-- 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 #
<!-- 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#26599
<!-- 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 -->
Populating the local registry for e2e tests is not dependent on the
builds but runs them. It sometimes gets cache misses for some builds
thus making that inconsistent.
https://staging.nx.app/runs/FxIwbj6UQo/task/%40nx%2Fnx-source%3Apopulate-local-registry-storage
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Populating the local registry for e2e tests is dependent on the builds
and does not run them within itself. In the CI pipeline, this ensures
that the build tasks are run first.
https://staging.nx.app/runs/NUrFeUBbQk/task/%40nx%2Fnx-source%3Apopulate-local-registry-storage
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
Plugin worker's socket path includes a hash digest of the workspace
root. This is not needed, as the socket path already includes the
process pid in it which is unique. The hash digest adds an additional 20
characters to the path and as the path is too long on some unix systems
the uniqueness is dropped, causing the plugin transactions to get hit
inappropriately.
## Expected Behavior
The plugin socket path doesn't contain extra characters, so it should be
unique.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Possibly related #27040
<!-- 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` -->
## Current Behavior
<!-- This is the behavior we have today -->
`nx reset` doesn't remove marker files used by nx cloud.
## Expected Behavior
`nx reset` removes marker files from nx cloud
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #https://github.com/nrwl/nx/issues/23308
It is possible for users to define multiple duplicate outputs in their
project.json. This is leading to fs related issues like `ENOTEMPTY:
directory not empty, rmdir`. The reason this occurs is that the src will
tried to be copied to the cached directory in parallel for all output
paths (even duplicated ones) and is the reason why these errors are seen
sporadically. By ensuring output paths are unique, we only ever copy one
path which resolves this issue.
Note: There may still be an issue present if there is a glob that is
overlapping another directory i.e: `cdk.out/*` and `cdk.out`, however
have not been able to reproduce a fs error while testing.
fixes#17277, #16337
## Current Behavior
If you have a project.json which has duplicate output entires, it is
possible to receive fs related errors when the cache is being written to
disk.
## Expected Behavior
each output should only be copied once into the caches directory.
## Related Issue(s)
#17277, #16337Fixes#17277, #16337
<!-- 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` -->
## Current Behavior
<!-- This is the behavior we have today -->
the code for the `nx list` command has unused and duplicated code.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
no unused code and code duplication
## 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>
<!-- 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 there are workspace libraries with the following import paths:
```
@org/core
@org/core/db
@org/core/acme
```
They need to be sorted for the manifest such that matching finds the
most specific first.
The logic for this is currently based off whether an `*` exists, which
doesn't work when the paths are specific.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Try to use `*` first and fallback to `/` to determine package prefix
length.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#20817
* Prioritized remotes in the order: `origin`, `upstream`, `base`, and
then the first remote found, when trying to determine if repo uses
GitHub.
* Implemented fallback to a default GitHub onboarding URL
(`/setup/connect-workspace/github/select`) if no remotes are found.
* Added corresponding unit tests to verify the new remote priority order
and fallback behavior.
Co-authored-by: Colum Ferry <cferry09@gmail.com>
Co-authored-by: katsanva <1161259+katsanva@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## 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#20324#20325
Co-authored-by: katsanva <1161259+katsanva@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
The `@nx/vite:build` executor is always overwriting the
`packageJson.type` field when generating a packageJson.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The `@nx/vite:build` executor should respect the existing type in
packageJson
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27057
<!-- 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 -->
`cache.dir` is still generating when it shouldn't be.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`cache.dir` option should not be generating
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27039
<!-- 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 only method available to manage remotes is `setRemoteDefinitions`
method, that overwrite the previous state, as expected. The problem is
that in some cases, when it needed to add more remotes dynamically, this
API replace it current state, removing the previous remotes.
## Expected Behavior
Expose a new API called `setRemoteDefinition(remoteName: string,
remoteUrl: string)` that adds or replace a new remote definition in the
remotes map, without overwrite the remotes map.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#27050
---------
Co-authored-by: Guilherme Prezzi <guilherme.prezzi@totvs.com.br>
## Current Behavior
When running `nx serve` for a module federation application, if one of
the static remotes fail you get output that looks as such
```
> nx run shell:serve:development
NX Starting module federation dev-server for shell with 13 remotes
NX Building 13 static remotes...
/<user-path>/node_modules/@nx/react/src/executors/module-federation-dev-server/module-federation-dev-server.impl.js:140
throw new Error(`Remote failed to start. A complete log can be found in: ${remoteBuildLogFile}`);
^
Error: Remote failed to start. A complete log can be found in: /<user-path>/.nx/workspace-data/2024-06-26T21_21_37_744Z-build.log
at ChildProcess.<anonymous> (/<user-path>/node_modules/@nx/react/src/executors/module-federation-dev-server/module-federation-dev-server.impl.js:140:23)
at Object.onceWrapper (node:events:632:26)
at ChildProcess.emit (node:events:517:28)
at Process.ChildProcess._handle.onexit (node:internal/child_process:292:12)
Node.js v18.20.3
——————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————
NX Running target serve for project shell failed
```
The cause of the failure is not immediately obvious. The output is
cryptic and seems like a fatal error occurred, not one from the project
source code. The failure could happen for many reasons such as updating
a package that is not compatible with all remotes.
## Expected Behavior
With the changes proposed in this PR, we get a much more improved output
that's easier to read and much more obvious what happened in the project
source code.
1. Replace the `throw` statement with a promise rejection which outputs
a clean Nx Error
2. When an error is detected from webpack, output that snippet directly
into the console. No need to open and scroll through the entire log file
searching for the error.
```
NX Starting module federation dev-server for shell with 13 remotes
NX Building 13 static remotes...
m (id hint: vendors) 134 KiB [rendered] reused as split chunk (cache group: defaultVendors)
chunk (runtime: mover) 8762.js 13.4 KiB [rendered]
chunk (runtime: mover) 8798.js 14.9 KiB [rendered]
chunk (runtime: mover) 8802.js (id hint: vendors) 20.1 KiB [rendered] reused as split chunk (cache group: defaultVendors)
chunk (runtime: mover) 8930.js (id hint: vendors) 121 KiB [rendered] split chunk (cache group: defaultVendors)
chunk (runtime: mover) 8974.css, 8974.js 150 KiB (javascript) 252 bytes (consume-shared) 25.6 KiB (css/mini-extract) [rendered]
chunk (runtime: mover) 42 bytes reused as split chunk (cache group: default)
chunk (runtime: mover) 9199.js 17.4 KiB [rendered]
chunk (runtime: mover) 9227.js 7.02 KiB [rendered]
chunk (runtime: mover) 9241.js 10.7 KiB [rendered]
chunk (runtime: mover) 9279.js (id hint: vendors) 209 KiB [rendered] split chunk (cache group: defaultVendors)
chunk (runtime: mover) 9289.js (id hint: vendors) 228 KiB [rendered] reused as split chunk (cache group: defaultVendors)
chunk (runtime: mover) 9354.js 15 bytes [rendered]
chunk (runtime: mover) 9356.js 14.5 KiB [rendered]
chunk (runtime: mover) 9426.js (id hint: vendors) 26.8 KiB [rendered] reused as split chunk (cache group: defaultVendors)
chunk (runtime: mover) 9500.js 1.05 KiB [rendered]
chunk (runtime: mover) 9637.js 78.1 KiB (javascript) 84 bytes (consume-shared) [rendered] reused as split chunk (cache group: default)
chunk (runtime: mover) 9716.js (id hint: vendors) 59.5 KiB [rendered] split chunk (cache group: defaultVendors)
chunk (runtime: mover) 9807.js 16.2 KiB [rendered]
chunk (runtime: mover) 9888.js 7.42 KiB [rendered]
ERROR in ./apps/app1/src/../../../index.tsx:20:20
TS2322: Type '"foo"' is not assignable to type 'Tones'.
18 | return (
19 | <div data-component-id="Banner">
> 20 | <ComponentA tone={'foo'} >
| ^^^^
21 | <div className="space-y-2">
22 | <div className="pr-2">
webpack compiled with 1 error (bd60f37cf54db8e4)
NX Remote failed to start. A complete log can be found in: /<user-path>/.nx/workspace-data/2024-06-26T21_27_40_438Z-build.log
——————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————
NX Running target serve for project shell failed
```
## Related Issue(s)
N/A
Co-authored-by: Hancock, Matthew <Matthew_Hancock@comcast.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
`nx watch` throws an error saying the daemon is not running when the
daemon is indeed running.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`nx watch` does not throw an error saying the daemon is not running when
the daemon is indeed running.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
There is no summary of distributed task runs
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
There is a summary of distributed task runs on CI
https://app.circleci.com/pipelines/github/nrwl/nx/53764/workflows/208f1b92-909b-489d-9144-58444e1b3c43/jobs/429693
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Pin the MF package versions to a minor range that works. There was a
release today that is causing failures:
https://staging.nx.app/runs/h1eVO5d9D7/task/e2e-angular%3Ae2e-ci--src%2Fmodule-federation.test.ts.
<!-- 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 #
<!-- 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
Nx allows running atomized tasks (like `e2e-ci`) anywhere.
## Expected Behavior
Nx allows running atomized tasks (like `e2e-ci`) only in distributed
environments like Nx Agents or DTE. We'll leave that actual check to nx
cloud but in the default runner, we'll throw an error.
It's possible to escape from this with an env var.
Currently, the following warning is output when using GitHub Actions.
> Node.js 16 actions are deprecated. Please update the following actions
to use Node.js 20: actions/setup-node@v3. For more information see:
https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/.
<!-- 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 `actions/setup-node` GitHub Action is installed in version 3.x
which uses the deprecated Node.js 16 runtime for GitHub Actions
## Expected Behavior
- The `actions/setup-node` GitHub Action is installed in version 4.x
which uses the supported Node.js 20 runtime for GitHub Actions
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Miroslav Jonaš <missing.manual@gmail.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## 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: Miroslav Jonaš <missing.manual@gmail.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## 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 #
<!-- 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 #
<!-- 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#26770
… version
<!-- 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 #
<!-- 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 #
<!-- 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 #
<!-- 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` -->
## Current Behavior
<!-- This is the behavior we have today -->
Typechecking of Vue Projects with Vite is not functioning correctly
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Typechecking of Vue projects should type check the .vue files and not
error in TS files importing .vue files
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#20242
We'd like to use shared cypress commands, but that's currently not
working because vite cannot resolve the import.
By allowing to pass options to the vite config we have the possibility
to add an alias or a plugin to fix this.
This adds support for an **optional** `viteConfigOverrides` object.
## Current Behavior
cypress.config.ts:
```ts
import { nxE2EPreset } from '@nx/cypress/plugins/cypress-preset';
import { defineConfig } from 'cypress';
export default defineConfig({
e2e: {
...nxE2EPreset(__filename, { cypressDir: 'cypress', bundler: 'vite' }),
},
});
```
## Expected Behavior
cypress.config.ts:
```ts
import { nxE2EPreset } from '@nx/cypress/plugins/cypress-preset';
import { defineConfig } from 'cypress';
const viteConfigOverrides = {
resolve: {
alias: {
'@cypress-shared-commands': '../../../shared-cypress-commands',
},
},
};
export default defineConfig({
e2e: {
...nxE2EPreset(__filename, { cypressDir: 'cypress', bundler: 'vite', viteConfigOverrides }),
},
});
```
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## 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@users.noreply.github.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## 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 #
<!-- 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 -->
Converting a root project to inferred results in the plugin registration
to have the `includes` option set to `./**/*`. This is invalid and
causes no project to be inferred.
Additionally, the eslint `convert-to-inferred` generator:
- keeps a redundant `config` option, which is not needed because
inferred tasks only work with default/known ESLint config files, so
there's no need to specify it in the options
- converts all `lintFilePatterns` to `args`, which is correct, but it
keeps the patterns that are already inferred by the plugin, which leads
to duplicated patterns when running the task
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Converting a root project to inferred should work as expected and result
in the `lint` task being inferred for the project.
Also, default inferred options should be removed from the target
options.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#26775
<!-- 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#26926
<!-- 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 cypress plugin overview lists `cypress.config.mts` and
`cypress.config.cts` filenames, which are not configuration filenames
supported by Cypress by default.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The cypress plugin overview only lists valid configuration filenames
supported by Cypress.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## 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 #
<!-- 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#26906
<!-- 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 was changed in the generated ci workflow but not on the docs.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This is changed in the docs as well so it's not confusing.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Stats are not recorded for `nx connect`, `nx view-logs`, and `nx init`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Stats are recorded for those commands and they get sent to the right URL
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
There is a missing closing bracket in the
[cache-task-result](https://nx.dev/features/cache-task-results#finetune-caching-with-inputs-and-outputs)
<img width="696" alt="Screenshot 2024-07-21 at 2 22 01 PM"
src="https://github.com/user-attachments/assets/4a798a3a-3869-46e9-bd0b-cb762034a70f">
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Add the missing closing bracket: change `{projectName` to
`{projectName}`.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
N/A!
<!-- 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#26722
Update the github actions tutorial:
- Removes content that focuses on GitHub Actions itself
- Updates for the new `nx connect` onboarding flow
---------
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## 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/26853
<!-- 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` -->
## Current Behavior
nx/nest documentation contains no deployment information.
## Expected Behavior
Deployment information is present, as it is a common question in
Discord.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
---------
Co-authored-by: MilanKovacic <9189985+MilanKovacic@users.noreply.github.com>
Enhanced the typography styles to improve text scaling across various
screen sizes. Adjusted the hero component to include responsive line
breaks and optimized the SVG element for better alignment and sizing.
We're making an enhancement to `nx g ci-workflow` such that when the
workspace is already connected to Nx Cloud, we'll enable distribution in
the workflow file, rather than having them commented out. For the flow
of the tutorial, it makes more sense to do `nx connect` first so things
are set up correctly without user intervention.
Note: I left the "Make sure the following line is uncommented" for
distribution because older versions will still leave it uncommented.
Example:
https://nx-dev-git-docs-tutorials-update-nrwl.vercel.app/getting-started/tutorials/angular-monorepo-tutorial
---------
Co-authored-by: Isaac Mann <isaacplmann@gmail.com>
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## 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/26975
We're currently caching files for an hour when serving the host with
static remotes. This PR fixes the issue by setting `cacheSeconds: -1` on
the static server (disables cache).
This affects development only.
<!-- 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 #
Revised meta descriptions and adjusted layout styles to improve visual
consistency and accessibility. Enhanced card layout by refining padding
and icon handling for different screen sizes.
<!-- 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 -->
Remotes that are served for a host are usually served from a single file
server running on a single port.
We perform some mapping logic during the build of the host application
to update the locations the remotes can be found at to point to the
single file server.
This works, but it's also wrong, as it breaks the flow that users
expect.
It also breaks dynamic remotes.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Continue to serve the remotes from a single file server, as this helps
reduce the amount of resources used on developers machines.
Use express to create proxy servers that will proxy requests from the
original remote location to the single file server.
This allows applications to continue to work without us having to
interfere and map any remote locations.
It also solves the issue with dynamic remotes.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#26318
<!-- 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 -->
Resolving the package for delegated executor definitions doesn't take
into account that the package could be nested inside the parent package.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Resolving the package for delegated executor definitions should work
correctly.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#26896
2024-07-18 16:41:26 +02:00
443 changed files with 974 additions and 16748 deletions
@@ -90,7 +90,7 @@ Learn more at [enterprise](/enterprise).
Nx Cloud has evolved a lot since we first released it in 2020, and is changing even more in 2023. To better adapt to Nx Cloud being a critical CI tool, we changed our pricing model to be more consistent and predictable for CI workloads.
Nx Cloud’s previous pricing was based on time savings from Nx Cloud, which made sense when Nx Cloud was strictly a distributed caching service. The [new pricing model](/pricing) is based entirely on the number of CI pipeline executions per calendar month. We believe this is a simpler and more transparent model that should help you predict your costs far more easily.
Nx Cloud’s previous pricing was based on time savings from Nx Cloud, which made sense when Nx Cloud was strictly a distributed caching service. The [new pricing model](https://nx.app/pricing) is based entirely on the number of CI pipeline executions per calendar month. We believe this is a simpler and more transparent model that should help you predict your costs far more easily.
@@ -100,7 +100,7 @@ Finally, the **Enterprise plan** is for companies that want full control over wh
All these changes should allow developers to choose the plan that best suits their needs and budget more easily, ensuring a seamless and transparent experience regarding pricing and subscription management.
Learn more at [https://nx.dev/pricing](/pricing).
Learn more at [https://nx.app/pricing](https://nx.app/pricing).
- [Monorepo World Conference Speakers to Be Announced Soon!!](#monorepo-world-conference-speakers-to-be-announced-soon)
## StackBlitz Support!!
Nx now has support for Stackblitz. This means that you can create a StackBlitz with a whole Nx Workspace inside of it and run all Nx capabilities from their embedded terminal.
[](https://stackblitz.com/edit/stackblitz-webcontainer-api-starter-cwruaw?file=apps%2Freact-app%2Fsrc%2Fapp%2Fapp.tsx)
[Check out the example](https://stackblitz.com/edit/stackblitz-webcontainer-api-starter-cwruaw?file=apps%2Freact-app%2Fsrc%2Fapp%2Fapp.tsx) above - you can use the standard command in the terminal:
```shell
> nx serve react-app
```
to develop your application inside of the stackblitz.
We're excited for this as it opens up many interesting use-cases, including easier ways of sharing examples, better opportunities for reproduction of issues or bugs, and potential for us to use embedded examples in our documentation in the future.
Web Assembly (or WASM) is the underlying technology being used here, so in addition to stackblitz any other tools built on a node context should now work as well.
## NEW: Pattern Support for `targetDefaults`
When using the Atomizer features of plugins like [`@nx/playwright`](/nx-api/playwright) and [`@nx/cypress`](/nx-api/cypress), you end up creating tasks with dynamic but predictable names.
Notice how the `e2e-ci--src/example.spec.ts` and `e2e-ci--src/test.spec.ts` tasks here are created by the `@nx/playwright` plugin based on the playwright spec files present in your workspace.
We've now added pattern matching to `targetDefaults` task names as a way to target these dynamic tasks.
The following will set all such tasks to depend on their `build` task:
```json
{
"targetDefaults":{
"e2e-ci--**/*":{
"dependsOn":["build"]
}
}
}
```
Note that our plugins will set sensible configurations here out of the box when creating new workspaces using our generators.
Read more about [reducing configuration with `targetDefaults`](/recipes/running-tasks/reduce-repetitive-configuration#reduce-configuration-with-targetdefaults) and [how you can define task pipelines with `targetDefaults`](/features/run-tasks#defining-a-task-pipeline).
## NEW: Individual Targets Can Now Opt Out of Parallelism
One of our goals in changing the landscape of CI is to make CI more declarative - defining the what rather than the how.
Unfortunately, to accomodate for port collisions on end-to-end test, we've long adjusted our generated ci script to look like this:
```yml
- run:npx nx affected -t lint test build
- run:npx nx affected --parallel 1 -t e2e-ci
```
This is unfortunately more imperative, as we are starting to give instructions on how to run and order your CI, rather than defining what to run in our CI. In addition, these instructions will still run `lint`, `test`, and `build` targets first and wait until they all complete before then running `e2e-ci` - which leaves some inefficiencies on the table.
To address this, all tasks now support a `parallelism` property. By setting this property to `false`, you can now inform the Nx task runner to not attempt to run a certain task in parallel. This way we can define parallelism as a property of a task, and move our task running to be more declarative again.
Both our `@nx/playwright` and `@nx/cypress` plugins will now set `targetDefaults` for atomized tests to turn off `parallelism` from now on:
```json
{
// ...
"targetDefaults":{
"e2e-**/*":{
// ...
"parallelism":false
}
}
}
```
This way we can simply run the command:
```shell
> nx run-many --targets=lint,test,e2e-ci,build
```
And in CI, Nx Agents will allow all tasks to run in parallel on the same machine, except for the atomized end-to-end tasks, which will only run in isolation.
Learn more about how you can [Parallelize Tasks Across Multiple Machines Using Nx Agents](/ci/intro/tutorials/github-actions#parallelize-tasks-across-multiple-machines-using-nx-agents):
{% youtube
src="https://youtu.be/0YxcxIR7QU0"
title="Faster e2e Tests!"
width="100%" /%}
## Experimental: Gradle Test Atomization
Our new [`@nx/gradle` plugin](/nx-api/gradle) now supports Test Atomization out of the box.
This means that as you add tests in your gradle projects, we'll automatically create a new task for each test class, allowing you to distribute the execution of these tasks in your CI pipeline, just like with our `@nx/playwright` and `@nx/cypress` plugins.
## Support for React 19 (rc) and Angular 18.1
Nx 19.5 adds support for the React 19 release candidate and updated our Angular package to support the latest Angular minor version: 18.1.
When using our `@nx/angular` package, we'll automatically update you to the latest angular version when you run our migration. Using the `--interactive` flag you can choose to opt in or out of the latest Angular version:
```shell
> nx migrate latest --interactive
✔ Do you want to update to TypeScript v5.5? (Y/n) · true
✔ Do you want to update the Angular version to v18.1? (Y/n) · true
Fetching @angular/core@18.1.2
NX The migrate command has run successfully.
```
Our `@nx/react` package will now create new React applications using version 18.3, and we now support the new experimental `reactCompiler`. Users can install the [`babel-plugin-react-compiler` package](https://www.npmjs.com/package/babel-plugin-react-compiler) and you can follow [this guide for how to enable it with Nx](/recipes/react/react-compiler#react-compiler-with-nx).
Note that due to the extent of breaking changes coming with React 19, we will not be providing a automated migration to React 19 via [`nx migrate`](/nx-api/nx/documents/migrate).
## Automatically Update Nx
As always - updating Nx and its plugins is easy as we ship an [automated migration command](/features/automate-updating-dependencies).
```shell
npx nx migrate latest
```
After updating your dependencies, run any necessary migrations.
```shell
npx nx migrate --run-migrations
```
## NEW: Nx Cloud Hobby Tier
Our new expanded Hobby Tier now adds trial support for all features AND includes credits to run Nx Agents.
Sample the entire suite of features to see its impact on your organization. Start with everything, scale when you need more.
The [Monorepo World conference](https://monorepo.world) is coming up soon on October 7, 2024 at the Computer History museum in Mountain View, California.
[Get your tickets now](https://ti.to/nx-conf/monorepoworld2024), consider [requesting access to the invite-only Enterprise Summit on October 8](https://ti.to/nx-conf/monorepoworld2024), and be sure to stay tuned as we'll be announcing speakers soon!
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:
Once you hit that button, we collect the terminal output and other Nx task information and sprinkle some AI on top of it to give you a suggested fix. That should help you quickly get to the bottom of the issue and get back to work quickly.
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.**
## How can I start using this today?
Here's how you get started:
- **Step 1:** Go to your [Nx Cloud](https://cloud.nx.app/) organization settings
- **Step 2:** Enable AI features
- **Step 3:** Accept the Nx Cloud AI terms and conditions.
- **Step 4:** You're all set ✨
Note that you'll need to be an organization admin for your Nx Cloud workspace to enable AI features.
{% call-to-action title="Log in to Nx Cloud" url="https://cloud.nx.app" icon="nxcloud" description="Enable AI features in your organization settings" %}
Log in to Nx Cloud
{% /call-to-action %}
### I want to try this, but I'm on the Hobby plan 🤔
If you're currently on the Hobby plan, you can start a free Pro plan trial for 14 days to try it out on your own workspace. No, we don't ask for credit cards to start a trial, so feel free to experiment!
## More to come!
This is just the first of a series of AI-powered features that we're going to be rolling out to your workspaces. We've got some cool features in the works already, which we're going to **announce publicly during the [Monorepo World](https://monorepo.world) conference in October**! So stay tuned!
- [Monorepo World Conference Speakers Announced!!](#monorepo-world-conference-speakers-announced)
## Video Summary
{% youtube
src="https://youtu.be/ER-6sKbb9ck"
title="Nx 19.5 is here! Stackblitz, Bun, AND MORE!"
width="100%" /%}
## Announcing Nx Cloud Hobby Tier
We just added a new [Hobby Tier](/pricing#plan-details) to Nx Cloud! Why is this exciting? It is completely free and contains all major features, which includes the ability to [distribute your tasks with Nx Agents](/ci/features/distribute-task-execution).
This gives you plenty of opportunities to experiment with Nx Cloud on your workspace and see its impact on your teams productivity.
Checkout the [plan details page](/pricing#plan-details) for more info, and see how Nx Cloud can help you! And in case you missed it, check out our latest blog on the latest Nx Cloud feature: [Explain with AI](/blog/explain-with-ai)!
## StackBlitz Support
Nx now has support for [Stackblitz](https://stackblitz.com/) (again). For a while it was not possible to use Nx on Stackblitz because we implemented some perf critical parts of Nx as native components with Rust. Huge shoutout to [LongYinan](https://github.com/Brooooooklyn) for [their amazing work of pushing napi-rs](https://napi.rs/) forward and helping us [add WebAssembly support to Nx](https://github.com/nrwl/nx/pull/22870) as well as the StackBlitz team who helped debug issues.
This means we are back and you can create a StackBlitz with a whole Nx Workspace inside it and run all Nx capabilities from their embedded terminal.
[](https://stackblitz.com/edit/stackblitz-webcontainer-api-starter-cwruaw?file=apps%2Freact-app%2Fsrc%2Fapp%2Fapp.tsx)
[Check out the example](https://stackblitz.com/edit/stackblitz-webcontainer-api-starter-cwruaw?file=apps%2Freact-app%2Fsrc%2Fapp%2Fapp.tsx) above. You can use the standard Nx commands in the Stackblitz terminal, like
```shell
nx serve react-app
```
We're excited about this as it opens up many interesting use cases, including easier ways of sharing examples, better opportunities for reproducing issues or bugs, and the potential for us to use embedded examples in our documentation in the future.
Again, special shout out to community contributor [LongYinan](https://github.com/Brooooooklyn) and [their napi-rs project](https://napi.rs/).
## Bun and Pnpm v9 Support
We've been monitoring [Bun](https://bun.sh/) for a while both as a runtime and as a package manager, and we've decided to take the first step in Bun support now by supporting [Bun as a package manager](https://bun.sh/docs/cli/install)! This means that you can now use Bun like you would use npm, pnpm, or yarn to install and manage your dependencies, and Nx will be able to correctly understand those dependencies as `externalNodes` in the Nx dependency graph.
Sending a big thank you to community contributor [Jordan Hall](https://github.com/Jordan-Hall) for completing [this work](https://github.com/nrwl/nx/pull/22602).
In addition to supporting Bun, Nx now supports the latest format of [`pnpm`](https://pnpm.io/) lockfiles which was introduced in version 9.
## Local Flaky Task Detection
Nx Cloud has long offered [flaky task detection](/ci/features/flaky-tasks) on CI, and now this capability is available **even when running them locally**.
If a task is detected as flaky during local execution, you’ll receive a warning. Nx identifies flaky tasks by tracking the outcomes of your tasks in relation to your source code and external dependencies. When the same code produces different results, Nx flags the task as flaky and triggers the warning.
Detecting flaky tasks in the local environment empowers developers to address issues early in the development cycle—before they affect your CI pipelines.
## Project Detail View Enhancements
As part of [project Crystal](/concepts/inferred-tasks) we've added the ability to our plugins to automatically infer tasks based on the tools and configuration files available in your workspace. As part of that we created the "project detail view", allowing you to visualize such dynamically created tasks. You can launch it by using the [Nx Console IDE plugin](/getting-started/editor-setup) or by running the command:
```shell
nx show project [projectName]
```
In this iteration we've added several enhancements to the project detail view. For one, we've added more instructions on how to discover options for the underlying tools, and included examples on how to adjust these options via your `project.json` file.
In addition, we've added a callout for tasks that [leverage the `Nx Atomizer`](/ci/features/split-e2e-tasks). Since atomizer tasks are designed to be used with [Nx Agents](/ci/features/distribute-task-execution#distribute-task-execution-nx-agents), this callout will appear in yellow to warn if your project is not yet configured to run them on CI, and you can click on this callout for an easy way to complete that setup:
Clicking this button will launch the [Nx Cloud onboarding](https://cloud.nx.app) process, which will generate a PR in your repository to complete the setup.
Note that the new, free [hobby tier for Nx Cloud](#new-nx-cloud-hobby-tier) includes the ability to run [Nx Agents](/ci/features/distribute-task-execution) without the need to immediately jump onto a paid plan.
## Pattern Support for `targetDefaults`
When using the [Atomizer features](/ci/features/split-e2e-tasks) of plugins like [`@nx/playwright`](/nx-api/playwright) and [`@nx/cypress`](/nx-api/cypress), you end up creating tasks with dynamic but predictable names.
Notice how the `e2e-ci--src/example.spec.ts` and `e2e-ci--src/test.spec.ts` tasks here are created by the `@nx/playwright` plugin dynamically based on the playwright spec files present in your workspace.
We've now **added pattern matching** to `targetDefaults` task names as a way to target these dynamic tasks.
In the past it was difficult to customize this dynamic set of targets. But with the new support for specifying a pattern to a target name, you can now customize this set of dynamic targets all at once.
The following will set all such tasks to depend on their `build` task:
```json
{
"targetDefaults":{
"e2e-ci--**/*":{
"dependsOn":["build"]
}
}
}
```
Note that our plugins will set sensible configurations here out of the box when creating new workspaces using our generators.
Read more about [reducing configuration with `targetDefaults`](/recipes/running-tasks/reduce-repetitive-configuration#reduce-configuration-with-targetdefaults) and [how you can define task pipelines with `targetDefaults`](/features/run-tasks#defining-a-task-pipeline).
## Individual Targets Can Now Opt Out of Parallelism
One of our goals in transforming the CI landscape is to **make CI more declarative** by focusing on defining the "what" rather than the "how."
To accommodate port collisions in end-to-end tests, we've long adjusted our generated CI script to look like this:
```yml
- run:npx nx affected -t lint test build
- run:npx nx affected --parallel 1 -t e2e-ci
```
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.
Both our `@nx/playwright` and `@nx/cypress` plugins will now automatically set `targetDefaults` for atomized tests to disable parallelism:
```json {% fileName="nx.json" %}
{
// ...
"targetDefaults": {
"e2e-**/*": {
// ...
"parallelism": false
}
}
}
```
This way we can simply run the command:
```shell
nx affected --targets=lint,test,build,e2e-ci
```
In CI, Nx Agents will allow all tasks to run in parallel on the same machine, except for the atomized end-to-end tasks, which will only run in isolation.
Learn more about how you can [Parallelize Tasks Across Multiple Machines Using Nx Agents](/ci/intro/tutorials/github-actions#parallelize-tasks-across-multiple-machines-using-nx-agents):
{% youtube
src="https://youtu.be/0YxcxIR7QU0"
title="Faster e2e Tests!"
width="100%" /%}
## Support For Incremental Builds For Vite
Nx now supports incremental builds with our [`vite` plugin](/nx-api/vite). Incremental builds in Nx workspaces allow you to build any package in your workspace individually, and will then automatically use that built artifact when then building any project or application that consumes the package. This way you can speed up your build and CI times through optimizations like [only building packages that were affected](/nx-api/nx/documents/affected), using [Nx Replay](/ci/features/remote-cache) to effortlessly cache and share your built artifacts, and allowing you to run builds of your various packages in parallel using [Nx Agents](/ci/features/distribute-task-execution).
Read more about [buildable libraries and incremental builds](/concepts/buildable-and-publishable-libraries).
## Project Crystal Conversion Generators
Since launching [Nx Project Crystal](/concepts/inferred-tasks) in Nx version 18, we've adjusted our generators to leverage these features when creating new workspaces and projects. We've now added the `convert-to-inferred` generator to give you an automated way to opt into project crystal.
To run the generator, you can run the command:
```shell
npx nx g convert-to-inferred
```
The important thing to note here is that while this generator will make adjustments to the `project.json` file of the projects you convert, the behavior of your tasks should remain the same. You can see project details via the [Nx Console](/getting-started/editor-setup) plugin of your IDE, or in a browser by running the command: `nx show project [projectName]`.
In Nx 19, we were focused on adding `convert-to-inferred` to our [Playwright](/nx-api/playwright), [Cypress](/nx-api/cypress), and [ESLint](/nx-api/eslint) plugins - where bringing the [Nx Atomizer](/ci/features/split-e2e-tasks) provided the greatest value. Since then, we've added this generator to most other plugins. Currently, our React native plugins (react native, expo, detox) are the only plugins that are outstanding, and we'll be providing `convert-to-inferred` generators here in the near future.
## Gradle Composite Builds Support
In [Nx 19.0](/blog/nx-19-release), we introduced support for Gradle through our [Gradle plugin](/nx-api/gradle). With the latest update, this plugin now also supports [Gradle Composite builds](https://docs.gradle.org/current/userguide/composite_builds.html), in addition to multi-project builds.
Gradle Composite builds are commonly used in larger workspaces to manage dependencies across multiple projects. With this new support, Nx can now leverage composite builds to enhance the Nx Task Graph. For example, consider the following `settings.gradle.kts` file:
```kotlin
rootProject.name = "app"
includeBuild("number-utils")
includeBuild("string-utils")
```
Nx will now be able to automatically determine the dependencies between the `app` project and the `number-utils` and `string-utils` workspaces:
You can read more on composite builds in the [Gradle documentation](https://docs.gradle.org/current/userguide/composite_builds.html).
## Experimental: Gradle Test Atomization
The new [`@nx/gradle` plugin](/nx-api/gradle) now includes experimental support for [Test Atomization](/ci/features/split-e2e-tasks).
With Test Atomization, as you add tests to your Gradle projects, Nx will automatically create a separate task for each test class. This allows you to distribute the execution of these tasks across multiple machines on CI, similar to the functionality provided by our `@nx/playwright` and `@nx/cypress` plugins.
## Experimental: Nx Release Adds File Based Versioning Support
Currently with [Nx release](/nx-api/nx/documents/release), you already have two different ways of figuring out the how to modify the current version of a package to get its updated version:
- Imperatively via the CLI/prompt by telling it your desired relative (semver keyword) or absolute (e.g. `1.2.3`) version.
- Declaratively by letting Nx inspect your git history and determine the semver bump to apply based on the conventional commits specification.
Nx release now supports an experimental third way of deriving the version bump that we call "version plans".
The idea behind version plans is that you want to track your intended version bumps alongside your changes, just like you would do with conventional commits, but you want to make this tracking independent from your actual commit data. This might be because you do not want to/cannot use the conventional commits standard in your workspace, or it could just be that you find it a cleaner approach to versioning.
Version plan files use frontmatter enhanced markdown for their contents, and can be created by hand or by leveraging the new `nx release plan` subcommand. This will guide you through creating a git-tracked file within `.nx/version-plans` that will be committed alongside your normal changes.
When your team is ready to release, you can now simply run the CLI command `nx release` (or use the [powerful programmatic API](/features/manage-releases#using-the-programmatic-api-for-nx-release)) and nx will ingest all the outstanding version plan files and use the combined information to determine the resulting version for all referenced projects and/or release groups as part of the versioning, changelog generation, and publishing steps. (You can also run the command `nx release version` if all you want to do is update the version!)
Anyone who has used the tools "Changesets" or "Beachball" will be familiar with the concept of file based versioning, but with Nx release you get the power to combine one or more of the above mentioned versioning strategies all within the same workspace for different release groups, and we are really excited to keep building out this feature set and mark it as non-experimental (by fully documenting it) very soon. To learn more about the other features of [Nx Release in the meantime, check out our docs](/features/manage-releases).
## Support for React 19 (rc) and Angular 18.1
Nx 19.5 adds support for the React 19 release candidate and updated our Angular package to support the latest Angular minor version: 18.1.
When using our `@nx/angular` package, we'll automatically update you to the latest angular version when you run our migration. Using the `--interactive` flag you can choose to opt in or out of the latest Angular version:
```shell
nx migrate latest --interactive
✔ Do you want to update to TypeScript v5.5? (Y/n) · true
✔ Do you want to update the Angular version to v18.1? (Y/n) · true
Fetching @angular/core@18.1.2
NX The migrate command has run successfully.
```
Our `@nx/react` package will now create new React applications using version 18.3, and we now support the new experimental `reactCompiler`. Users can install the [`babel-plugin-react-compiler` package](https://www.npmjs.com/package/babel-plugin-react-compiler) and you can follow [this guide for how to enable it with Nx](/recipes/react/react-compiler#react-compiler-with-nx).
Note that due to the extent of breaking changes coming with React 19, we will not be providing a automated migration to React 19 via [`nx migrate`](/nx-api/nx/documents/migrate).
## Automatically Update Nx
As always - updating Nx and its plugins is easy as we ship an [automated migration command](/features/automate-updating-dependencies).
```shell
npx nx migrate latest
```
After updating your dependencies, run any necessary migrations.
The [Monorepo World conference](https://monorepo.world) is coming up soon on October 7, 2024 at the Computer History museum in Mountain View, California.
[Get your tickets now](https://ti.to/nx-conf/monorepoworld2024), consider [requesting access to the invite-only Enterprise Summit on October 8](https://ti.to/nx-conf/monorepoworld2024), and be sure to check out our [list of speakers](https://monorepo.world/#speakers-title) that was just published!
# Nx 19.5 Adds StackBlitz, New Features, And More!!
[](/blog/nx-19-5-adds-stackblitz-new-features-and-more)
[](/blog/nx-19-5-adds-stackblitz-new-features-and-more)
Read the [blogpost](/blog/nx-19-5-adds-stackblitz-new-features-and-more) for full details.
{% card title="Pattern Support for `targetDefaults`" type="document" url="/blog/nx-19-5-adds-stackblitz-new-features-and-more#pattern-support-for-targetdefaults" /%}
{% card title="Individual Targets Can Now Opt Out of Parallelism" type="document" url="/blog/nx-19-5-adds-stackblitz-new-features-and-more#individual-targets-can-now-opt-out-of-parallelism" /%}
{% card title="Support For Incremental Builds For Vite" type="document" url="/blog/nx-19-5-adds-stackblitz-new-features-and-more#support-for-incremental-builds-for-vite" /%}
{% card title="NEW: Pattern Support for `targetDefaults`" type="document" url="/blog/nx-19-5-adds-stackblitz-new-features-and-more#new-pattern-support-for-targetdefaults" /%}
{% card title="NEW: Individual Targets Can Now Opt Out of Parallelism" type="document" url="/blog/nx-19-5-adds-stackblitz-new-features-and-more#new-individual-targets-can-now-opt-out-of-parallelism" /%}
{% card title="Experimental: Gradle Test Atomization" type="document" url="/blog/nx-19-5-adds-stackblitz-new-features-and-more#experimental-gradle-test-atomization" /%}
{% card title="Monorepo World Conference Speakers to Be Announced Soon!!" type="document" url="/blog/nx-19-5-adds-stackblitz-new-features-and-more#monorepo-world-conference-speakers-to-be-announced-soon" /%}
"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.",
Alternatively you can generate the CI configuration using:
Let us generate the workflow file for you, if you don't already have one.
```shell
npx nx g ci-workflow
@@ -31,15 +29,16 @@ npx nx g ci-workflow
Or, check out our [recipes for the various CI providers](/ci/recipes/set-up).
## Step 3: Run your Nx commands as usual
**Step 3: Run your Nx commands as usual**
```yml
- run:npx nx-cloud record -- node tools/custom-script.js
- run:npx nx affected -t lint test build e2e-ci
- run:npx nx affected -t lint test build
- run:npx nx affected -t e2e-ci --parallel 1
```
All these commands are automatically picked up by Nx Cloud, split up into smaller tasks and distributed across the specified number of machines. Nx Cloud works with Nx tasks automatically, or you can [record non-Nx commands with `nx-cloud record`](/ci/recipes/other/record-commands).
## Step 4: All results are played back automatically
**Step 4: All results are played back automatically**
Nx Cloud automatically plays back all results to your CI system, as if distribution never happened. You can continue doing post-processing on the results, like uploading test reports, deploying artifacts etc.
Module Federation is a technique that allows developers to share code and resources across multiple applications. It has become more popular in recent years since the addition of the [ModuleFederationPlugin](https://webpack.js.org/plugins/module-federation-plugin/) in [Webpack](https://webpack.js.org).
As of Nx 19.5, our Module Federation support is provided by the [@module-federation/enhanced](https://npmjs.com/@module-federation/enhanced) package.
This package is owned and maintained by [Zack Jackson](https://x.com/ScriptedAlchemy), the creator of Module Federation, and the [ByteDance](https://x.com/ByteDanceTalk) team.
Using this package for Nx's Module Federation support keeps our support aligned with the latest improvements, features and bug fixes for Module Federation.
You can learn more about Module Federation Enhanced on their [docs](https://module-federation.io/).
{% /callout %}
An increasing number of enterprise applications have started to adopt Module Federation to help them develop and scale their applications quickly, while reducing some overhead in sharing code between teams.
Nx added out-of-the-box support for Module Federation with Webpack to make it more approachable, less complex and leverage some unique benefits that can only be realised in a monorepo.
@@ -5,7 +5,7 @@ Environment variables are useful to store system-wide values such as the directo
(PATH), OS version, Network Information, and custom variables. These env variables are passed at build time and used at
the runtime of an app.
## Set Environment Variables
## Setting environment variables
By default, Nx will load any environment variables you place in the following files:
@@ -53,30 +53,7 @@ We recommend nesting your **app** specific `env` files in `apps/your-app`, and c
for workspace-specific settings (like the [Nx Cloud token](/ci/recipes/security/access-tokens)).
{% /callout %}
### Environment Variables for Configurations
Nx will only load environment variable files for a particular configuration if that configuration is defined for a task, even if you specify that configuration name from the command line. So if there is no `development` configuration defined for the `app`'s `build` task, the following command will use `.env.build` instead of `.env.build.development`:
```shell
nx build app --development
```
In order to have Nx actually use the `.env.build.development` environment variables, the `development` configuration needs to be set for the task (even if it is empty).
Nx Release can automate the creation of [GitHub releases](https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository) for you. GitHub releases are a great way to communicate the changes in your projects to your users.
<!-- Prettier will mess up the end tag of the callout causing it to capture all content that follows it -->
<!-- prettier-ignore-start -->
{% callout type="note" title="Authenticating with GitHub" %}
In order to be able to create the release on GitHub, you need to provide a valid token which can be used for authenticating with the GitHub API.
Nx release supports two main ways of doing this:
1. In all environments it will preferentially check for an environment variable (the environment variable can either be called `GITHUB_TOKEN` or `GH_TOKEN`). Please ensure that this environment variable is set in your CI environment (and that the token it has been set to has been configured with the appropriate permissions to create releases) before attempting to create a release in CI.
2. It can also detect if you have a valid, authenticated installation of the official `gh` CLI tool (https://cli.github.com/) and leverage that automatically as a fallback when no environment variable is set.
{% /callout %}
<!-- prettier-ignore-end -->
## GitHub Release Contents
When a GitHub release is created, it will include the changelog that Nx Release generates with entries based on the changes since the last release. Nx Release will parse the `feat` and `fix` type commits according to the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) specification and sort them into appropriate sections of the changelog. Take a look at the [Nx releases page](https://github.com/nrwl/nx/releases) to see examples of GitHub releases generated by Nx Release.
[Nx release](/features/manage-releases) allows you to leverage the [conventional commits](/recipes/nx-release/automatically-version-with-conventional-commits) standard to automatically determine the next version increment.
Nx Release can defer to the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) standard to automatically determine the next version to release. To enable this behavior for versioning, see [Automatically Version with Conventional Commits](/recipes/nx-release/automatically-version-with-conventional-commits).
By default, this results in:
This recipe will cover how to customize the types of commits that trigger version bumps, how to customize the version bump for each type, and how to customize the changelog entry for each commit type.
-`feat(...)` triggering a minor version bump (`1.?.0`)
-`fix(...)` triggering a patch version bump (`1.?.x`)
-`BREAKING CHANGE` in the footer of the commit message or with an exclamation mark after the commit type (`fix(...)!`) triggers a major version bump (`?.0.0`)
## Conventional Commits Usage within Nx Release
The conventional commits configuration is used in two different places within Nx Release - once in the version step for determining the version bump, and once when generating changelogs.
### Determine the Version Bump
When `release.version.conventionalCommits` is `true` in `nx.json`, Nx Release will use the commit messages since the last release to determine the version bump. It will look at the type of each commit and determine the highest version bump from the following list:
- 'feat' -> minor
- 'fix' -> patch
For example, if the git history looks like this:
```
- fix(pkg-1): fix something
- feat(pkg-2): add a new feature
- chore(pkg-3): update docs
- chore(release): 1.0.0
```
then Nx Release will select the `minor` version bump and elect to release version 1.1.0. This is because there is a `feat` commit since the last release of 1.0.0. To customize the version bump for different types of commits, or to trigger a version bump with custom commit types, see the [Configure Commit Types](#configure-commit-types) section below.
If Nx Release does not find any relevant commits since the last release, it will skip releasing a new version. This works with [independent releases](/recipes/nx-release/release-projects-independently) as well, allowing for only some projects to be released while others are skipped.
If Nx Release does not find any relevant commits since the last release, it will skip releasing a new version. This works with [independent releases](/recipes/nx-release/release-projects-independently) as well, allowing for only some projects to be released and some to be skipped.
{% /callout %}
However, you can customize how Nx interprets these conventional commits, for both **versioning** and **changelog** generation.
#### Breaking Changes and Major Version Bumps
## Disable a Commit Type for Versioning and Changelog Generation
Major version bumps are triggered by the presence of a `BREAKING CHANGE` in the footer of the commit message or with '!' after the commit type and scope, as specified by the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) standard. This is regardless of the type or scope of the commit. For example:
To disable a commit type, set it to `false`.
```
fix: remove deprecated config properties
```json {% fileName="nx.json" %}
{
"release": {
"conventionalCommits": {
"types": {
// disable the docs type for versioning and in the changelog
"docs": false,
...
}
}
}
}
BREAKING CHANGE: `settings` and `overrides` keys in config are no longer supported
```
If you just want to disable a commit type for versioning, but still want it to appear in the changelog, set `semverBump` to `none`.
```json {% fileName="nx.json" %}
{
"release": {
"conventionalCommits": {
"types": {
// disable the docs type for versioning, but still include it in the changelog
"docs": {
"semverBump": "none",
...
},
...
}
}
}
}
```
fix!: do not trigger a workflow when user submits bad data
```
## Changing the Type of Semver Version Bump
```
feat(pkg-2)!: redirect users to the new workflow page
```
Assume you'd like `docs(...)` commit types to cause a `patch` version bump. You can define that as follows:
When Nx Release detects a breaking change, it will bump the major version, regardless of the other commits present in the history. Breaking changes will also appear in their own section of the changelog.
### Generate Changelog Sections
Nx Release will sort changes within changelogs into sections based on the type of commit. By default, `fix`, `feat`, and `perf` commits will be included in the changelog. To customize the headers of changelog sections, include other commit types, or exclude the default commit types, see the [Configure Commit Types](#configure-commit-types) section below.
See the [Nx repo](https://github.com/nrwl/nx/releases) for an example of a changelogs generated with Nx Release.
## Configure Commit Types
Commit types are configured in the `release.conventionalCommits.types` property in `nx.json`:
```json {% fileName="nx.json" %}
{
"release": {
"conventionalCommits": {
"types": {
// disable the fix type for versioning and in the changelog
"fix": false,
"docs": {
"semverBump": "patch",
...
},
}
}
}
}
```
## Renaming the Changelog Section for a Commit Type
To rename the changelog section for a commit type, set the `title` property.
```json {% fileName="nx.json" %}
{
"release": {
"conventionalCommits": {
"types": {
...
"docs": {
...
"changelog": {
"hidden": false,
"title": "Documentation Changes"
}
},
...
}
}
}
}
```
## Hiding a Commit Type from the Changelog
To hide a commit type from the changelog, set `changelog` to `false`.
```json {% fileName="nx.json" %}
{
"release": {
"conventionalCommits": {
"types": {
...
"chore": {
"changelog": false
},
...
}
}
}
}
```
Alternatively, you can set `hidden` to `true` to achieve the same result.
```json {% fileName="nx.json" %}
{
"release": {
"conventionalCommits": {
"types": {
...
"chore": {
"perf": {
"semverBump": "none",
// omitting "hidden" will default it to false
"changelog": {
"hidden": true
"title": "Performance Improvements"
}
},
...
"deps": {
"semverBump": "minor",
// omitting "hidden" will default it to false
"changelog": {
"title": "Dependency Updates"
}
},
// unspecified semverBump will default to "patch"
"chore": {
// "changelog.hidden" defaults to true, but setting changelog: false
// is a shortcut for setting "changelog.hidden" to false.
"changelog": false
},
// unspecified semverBump will default to "patch"
"styles": {}
}
}
}
}
```
## Defining non-standard Commit Types
In this example, the following types are configured:
If you want to use custom, non-standard conventional commit types, you can define them in the `types` object. If you don't specify a `semverBump`, Nx will default to `patch`.
```json {% fileName="nx.json" %}
{
"release": {
"conventionalCommits": {
"types": {
"awesome": {}
}
}
}
}
```
- The `fix` type has been fully disabled, so `fix` commits will not trigger a version bump and will not be included in the changelog.
- The `docs` type will trigger a `patch` version bump and will have the "Documentation Changes" title in the changelog.
- The `perf` type will NOT trigger a version bump and will have the "Performance Improvements" title in the changelog.
- The `deps` type will trigger a `minor` version bump and will have the "Dependency Updates" title in the changelog.
- The `chore` type will trigger a `patch` version bump, which is the default for if `versionBump` is not specified, and will not be included in the changelog.
- The `styles` type will trigger a `patch` version bump, which is the default for if `versionBump` is not specified, and will be included in the changelog with the corresponding default title.
@@ -270,8 +270,6 @@ For this same example, if you want the commit message to be 'chore(release): 1.2
}
```
When using release groups in which the member projects are versioned together, you can also leverage `{releaseGroupName}` and it will be interpolated appropriately in the commit/tag that gets created for that release group.
## Future Releases
After the first release, the `--first-release` option will no longer be required. Nx Release will expect to find git tags and changelog files for each package. It will also use `npm view` to look up the current version of packages before publishing, ensuring that the package has not already been published and therefore avoid any conflict errors, meaning you can run the same publish action multiple times without any negative side-effects.
@@ -209,8 +209,6 @@ For this same example, if you want the commit message to be 'chore(release): 1.2
}
```
When using release groups in which the member projects are versioned together, you can also leverage `{releaseGroupName}` and it will be interpolated appropriately in the commit/tag that gets created for that release group.
## Future Releases
After the first release, the `--first-release` option will no longer be required. Nx Release will expect to find git tags and changelog files for each package.
@@ -31,7 +31,6 @@ The following environment variables are ones that you can set to change the beha
| NX_MIGRATE_CLI_VERSION | string | The version of Nx to use for running the `nx migrate` command. If not set, it defaults to `latest`. |
| NX_LOAD_DOT_ENV_FILES | boolean | If set to 'false', Nx will not load any environment files (e.g. `.local.env`, `.env.local`) |
| NX_NATIVE_FILE_CACHE_DIRECTORY | string | The cache for native `.node` files is stored under a global temp directory by default. Set this variable to use a different directory. This is interpreted as an absolute path. |
| NX_PLUGIN_NO_TIMEOUTS | boolean | If set to `true`, plugin operations will not timeout |
Nx will set the following environment variables so they can be accessible within the process even outside of executors and generators.
@@ -132,8 +132,6 @@ Target defaults provide ways to set common options for a particular target in yo
- `` `${executor}` ``
- `` `${targetName}` `` (if the configuration specifies the executor, this needs to match the target's executor as well)
Additionally, if there is not a match for either of the above, we look for other keys that may match the target name via a glob pattern. For example, a key in the target defaults that looks like `e2e-ci--**/*` would match all of the targets created by a task atomizer plugin.
Target defaults matching the executor takes precedence over those matching the target name. If we find a target default for a given target, we use it as the base for that target's configuration.
{% callout type="warning" title="Beware" %}
@@ -309,26 +307,6 @@ If multiple targets with the same name run different commands (or use different
For more details on how to pass args to the underlying command see the [Pass Args to Commands recipe](/recipes/running-tasks/pass-args-to-commands).
### Task Atomizer Configuration
Task Atomizer plugins create several targets with a similar pattern. For example, the `@nx/cypress` plugin creates a top level `e2e-ci` target and a target for each test file that looks like `e2e-ci--test/my/test.spec.ts`. To avoid having to write a target default for each of these targets, you can use a glob pattern in the target default key.
Nx uses glob patterns for matching against the target name. This means that the `**/*` pattern above is required because the target name contains a `/`. If your target name does not contain a `/`, you can use a simpler pattern like `e2e-ci-*`.
{% /callout %}
## Release
The `release` property in `nx.json` configures the `nx release` command. It is an optional property, as `nx release` is capable of working with zero config, but when present it is used to configure the versioning, changelog, and publishing phases of the release process.
@@ -369,7 +347,7 @@ The `projectsRelationship` property tells Nx whether to release projects indepen
Optionally override the git/release tag pattern to use. This field is the source of truth for changelog generation and release tagging, as well as for conventional commits parsing.
It supports interpolating the version as `{version}` and (if releasing independently or forcing project level version control system releases) the project name as `{projectName}` within the string. When using release groups in which the member projects are versioned together, you can also leverage `{releaseGroupName}` and it will be interpolated appropriately in the commit/tag that gets created for that release group.
It supports interpolating the version as `{version}` and (if releasing independently or forcing project level version control system releases) the project name as `{projectName}` within the string.
The default `"releaseTagPattern"` for fixed/unified releases is: `v{version}`
@@ -440,27 +440,6 @@ You can also express task dependencies with an object syntax:
{% /tab %}
{% /tabs %}
Starting from v19.5.0, wildcards can be used to define dependencies in the `dependsOn` field.
```json
{
"targets": {
"test": {
"dependsOn": [
{
"target": "build", // target name
"params": "ignore" // "forward" or "ignore", defaults to "ignore"
},
"build-*", // support for using wildcards in dependsOn, matches: "build-css", "build-js" targets of current project
"^build-*", // matches tasks: "build-css", "build-js" targets of dependencies
"*build-*", // matches tasks: "build-css", "build-js" as well as "task-with-build-in-middle" targets of current project
"^*build-*" // matches tasks: "build-css", "build-js" as well as "task-with-build-in-middle" targets of dependencies
]
}
}
}
```
#### Examples
You can write the shorthand configuration above in the object syntax like this:
@@ -650,23 +629,6 @@ In the case of an explicit target using an executor, you can specify the executo
}
```
### Target Metadata
You can add additional metadata to be attached to a target. For example, you can provide a description stating what the
target does:
```jsonc {% fileName="project.json" %}
{
"targets": {
"build": {
"metadata": {
"description": "Build the application for production"
}
}
}
}
```
## Project Metadata
The following properties describe the project as a whole.
@@ -786,21 +748,7 @@ An implicit dependency could also be a glob pattern:
{% /tab %}
{% /tabs %}
### Metadata
You can add additional metadata to be attached to the project. For example, you can provide a description for your
project:
```jsonc {% fileName="project.json" %}
{
"name": "admin",
"metadata": {
"description": "This is the admin application"
}
}
```
## Including package.json files as projects in the graph
### Including package.json files as projects in the graph
Any `package.json` file that is referenced by the `workspaces` property in the root `package.json` file will be included as a project in the graph. If you are using Lerna, projects defined in `lerna.json` will be included. If you are using pnpm, projects defined in `pnpm-workspace.yml` will be included.
{% callout type="check" title="Forked repository with Nx" %}
Make sure you have completed the previous sections of this tutorial before starting this one. If you want a clean starting point, you can fork the [sample repository with Nx already added](https://github.com/nrwl/nx-recipes/tree/main/npm-workspaces).
So far in this tutorial you've seen how Nx improves the local development experience, but the biggest difference Nx makes is in CI. As repositories get bigger, making sure that the CI is fast, reliable and maintainable can get very challenging. Nx provides a solution.
- Nx reduces wasted time in CI with the [`affected` command](/ci/features/affected).
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.
“JamesHenry”
