## Current Behavior
The `set-inject-document-domain` migration updates the component
configuration. This is incorrect since the `inject-document-domain` is
not a property supported by the component configuration.
## Expected Behavior
The `set-inject-document-domain` migration should not update the
component configuration.
## Related Issue(s)
Fixes#31610
## Current Behavior
When the user hasn't interacted with the TUI and has not disabled the
auto-exit functionality, it will always auto-exit regardless of the
number of failed tasks.
## Expected Behavior
When the user hasn't interacted with the TUI and has not disabled the
auto-exit functionality, it should not auto-exit if there are multiple
failed tasks. Additionally, as long as no terminal output panes are open
(e.g., the run one command will always display the initiating task
terminal pane), it should focus and open the first failed task.
If all tasks succeed or there's only one failure, it should continue to
auto-exit.
Adds comprehensive explanation that both files support executors and all
Nx features through the 'nx' property in package.json. Clarifies that
project.json is optional.
Preview:
https://nx-dev-git-issues-28715-nrwl.vercel.app/reference/project-configuration#project-level-configuration-files
## Current Behavior
The documentation for project configuration does not clearly explain
that both package.json and project.json support the same Nx features,
including executors.
## Expected Behavior
The documentation now clearly states that:
- Both package.json and project.json support targets through the "nx"
property in package.json
- The choice between the two is primarily a matter of preference
- Includes an updated example showing how to use `nx.targets` in
package.json
## Related Issue(s)
Fixes#28715
## Current Behavior
When Nx is invoked from a global install, both the global and local
versions register process exit handlers that flush captured logs. This
causes Nx Cloud logs to be displayed twice - once from the global
installation and once from the local installation.
## Expected Behavior
Only the local Nx installation should handle log flushing, preventing
duplicate log output. The process exit handler is moved from the global
entry point (nx.ts) to the local entry point (init-local.ts) so that log
flushing only occurs once.
## Related Issue(s)
This change requires users to update their globally installed Nx to
fully resolve the duplicate logging issue, as the fix is now in the
local version that gets invoked.
## Current Behavior
The string regex the script uses to validate commits is not correctly
escaped.
## Expected Behavior
The string regex the script uses to validate commits should be correctly
escaped.
<!-- 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
-->
Adds the path to the terminal output s.t. you can at least debug what's
going on
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When building applications that depend on workspace libraries for
deployment (particularly in containerized environments like Docker),
developers must manually handle copying workspace dependencies and
updating package.json references.
This creates friction when trying to deploy applications that consume
workspace libraries, as the build output doesn't contain the necessary
workspace dependencies and the package.json still references them with
`workspace:` protocol which doesn't work outside the workspace context.
## Expected Behavior
With the new `@nx/js:copy-workspace-modules` executor, developers can
automatically prepare their built applications for deployment by:
1. **Automatically copying workspace dependencies**: The executor scans
the application's package.json for workspace dependencies (those with
`workspace:` or `file:` version specifiers) and copies the source code
of these dependencies into a `workspace_modules` directory within the
build output
---------
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
## Current Behavior
Some Angular migrations collect the Angular projects from the project
graph using the dependencies information. When reading the project
configuration for those projects, it can throw an error if trying to do
it for a completely inferred project (it doesn't have a project
configuration file).
## Expected Behavior
The Angular migrations collecting Angular projects from the project
graph using the dependencies information should gracefully handle
projects that were completely inferred when trying to read the project
configuration.
In fact, the current migrations didn't need to read the project
configuration and could use the project graph information directly, so
the call to read the project configuration was removed.
## Related Issue(s)
Fixes#31607
## Current Behavior
`nx run lint --quiet --fix` doesn't respect `--quiet` and fixes all
issues, even silenced ones. This is different from how `eslint --quiet
--fix` behaves.
## Expected Behavior
`nx run lint --quiet --fix` should only fix issues that aren't silenced
by `--quiet`, like `eslint` does
## Related Issue(s)
Fixes#31401
This PR added two TUI environment variables to the reference page:
- NX_TUI to enabled/disable
- NX_TUI_AUTO_EXIT to control auto-exit behavior
## Current Behavior
The environment variables documentation does not include the new
Terminal UI (TUI) environment variables `NX_TUI` and `NX_TUI_AUTO_EXIT`
that were recently added to control the interactive terminal interface
for task
execution.
## Expected Behavior
The documentation now includes comprehensive information about the TUI
environment variables:
- `NX_TUI`: Controls whether the Terminal UI is enabled or disabled for
running tasks
- `NX_TUI_AUTO_EXIT`: Controls the auto-exit behavior of the TUI after
tasks complete, supporting boolean values or a number for countdown
seconds
## Related Issue(s)
Fixes#31111
<!-- 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 atomized=false, it does not generate build-ci and check-ci targets
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- when atomized=false, it should still generate build-ci and check-ci
targets
- upgrade dev.nx.gradle.project-graph version to 0.1.2
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR adds bun to list of package managers that can be used on the CI
deployment page.
Fixes#31431
## Current Behavior
The CI deployment documentation at
https://nx.dev/ci/recipes/other/ci-deployment only mentions npm, yarn,
and pnpm as supported package managers. However, Bun is actually
supported by Nx as shown in the PackageManager type
definition which includes 'bun' as a valid option.
## Expected Behavior
The documentation should accurately reflect all supported package
managers, including Bun. Users should be aware that they can use Bun as
their package manager when following the CI deployment recipes.
## Related Issue(s)
Fixes#31431
<!-- 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 -->
fix to run gradle on windows
./gradlew command is only macos
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
use @nx/gradle:gradle executor instead of command ./gradlew
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Summary
This pull request updates the documentation to reflect changes in
project names for task dependencies. The documentation was referring to
the `modules-shared-ui` and `modules-products` packages on the chart,
but these packages are called differently.
## Current Behavior
Some links in the Angular and React tutorials are broken.
## Expected Behavior
The links in the Angular and React tutorials work correctly.
## Related Issue(s)
Fixes#31601
## Current Behavior
Using the `ng-packagr` executors in an Angular version lower than v20
results in an error due to a bad import.
## Expected Behavior
The `ng-packagr` executors should work correctly regardless of the
Angular version used.
## Related Issue(s)
Fixes#31597
Extended the `Callout` component and schema to support a new 'announcement' type with corresponding styles and icon. Updated documentation example for the new type.
This PR adds the ability to set the port of the React application when
using the generator.
e.g.
```shell
npx nx g @nx/react:app --port 8080
```
This is useful when generating multiple apps and then running them in
parallel.
<!-- 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
Index pages read from the map.json description which is missing for a
lot of entries.
<img width="853" alt="image"
src="https://github.com/user-attachments/assets/8c0db9a2-d293-482d-8597-647cda47cc93"
/>
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The new logic
- checks the corresponding markdown file `description` property which is
also used for the HTML meta description tags
- falls back to the `map.json` description
<img width="809" alt="image"
src="https://github.com/user-attachments/assets/716358f0-bab9-4bd4-97b2-b31fa151ebe0"
/>
## 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 #
This PR updates pages like
`/technologies/typescript/api/executors/verdaccio`, such that the
backlink to the API index is correct. Even though we redirect `/nx-api`
pages, the Next.js pages router does not respect them and users see 404
instead.
This PR updates the Nodejs version installed on our docker images
contained in the publish script to be consistent with the Nx repository
Node compatibility version.
The current Nodejs version being pulled from the docker image is Node
v18 but our repository requires Node v20.19.0.
A test run can be found here:
https://github.com/nrwl/nx/actions/runs/15593332649
…le extensions for type definitions.
Updated the Rollup plugin's logic for generating type definition files
to ensure compatibility with additional file extensions, including
.cjs.js and .mjs.js.
This change improves the handling of entry points and ensures that
corresponding .d.ts files are correctly named and emitted in all
supported scenarios.
Added a comprehensive test case to validate the new behavior.
closed#29308
<!-- 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: Colum Ferry <cferry09@gmail.com>
This PR modifies the populate-local-registry-storage inputs to
invalidate the cache when the native task is updated (which includes
OS/architecture information).
This change addresses MacOS failures we've been encountering in our
nightly GitHub Actions runs. The issue stems from incorrect cache
restoration when running multiple OS and Node.js version combinations,
which explains why native modules were consistently missing in most
MacOS tests.
Here is the result: https://github.com/nrwl/nx/actions/runs/15562011534
## Current Behavior
Docs do not callout potential port conflict issues with running e2e in
parallel
## Expected Behavior
Docs mention how to avoid parallel port collisions
## Related Issue(s)
Fixes #
## Current Behavior
The Nx Console installation prompt has verbose and redundant wording
that makes the message unclear.
## Expected Behavior
The prompt is simplified and more concise, focusing on the key benefits
of installing Nx Console while being more direct about what users will
gain.
## Related Issue(s)
This change improves the user experience when prompted to install Nx
Console.
## Current Behavior
The native logging is currently set to a global 'info' level, which can
produce verbose output that may not be relevant to users.
## Expected Behavior
Native logging should be scoped to the 'nx::native' module by default
with 'info' level, reducing noise while still allowing users to control
logging verbosity through the `NX_NATIVE_LOGGING` environment variable.
## Related Issue(s)
This improves the developer experience by providing more focused logging
output and reduces unnecessary verbosity in the console.
Fixes https://github.com/nrwl/nx/issues/31518
<!-- 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 -->
- for the atomized test, currenly, its testClassName is just the 1st
class name in the file
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- upgrade gradle to latest version from 8.13 to 8.14
- for test task, exclude all its depends on tasks
- it currently only exclude its direct depends on, its children
- now it will go down the dependency tree and exclude all of its depends
on, its children and grandchildren
- for the atomized test target, its testClassName will be the full
package name
- e.g.
org.springframework.boot.autoconfigure.jersey.JerseyAutoConfigurationCustomObjectMapperProviderTest
- add logics to handle nested class
- exclude private class name
<img width="1081" alt="Screenshot 2025-06-06 at 2 53 39 PM"
src="https://github.com/user-attachments/assets/285792fb-f098-4511-85dc-ee1263d75929"
/>
- add build-ci target
<img width="1140" alt="Screenshot 2025-06-10 at 10 21 06 AM"
src="https://github.com/user-attachments/assets/25db4a3e-2794-4654-9a95-1b66d229340b"
/>
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
The Node.js application generator
(`packages/node/src/generators/application/application.ts`) is
implemented as a single large file containing ~469 lines of code. All
generator logic is mixed together in one file including:
- Option normalization and validation
- Project configuration creation
- File generation
- Build/serve target setup
- Dependency management
- ESLint configuration
- Proxy setup
This makes the code harder to maintain, test, and understand as the file
handles multiple responsibilities.
## Expected Behavior
The generator is now refactored into smaller, focused modules organized
in a `lib/` directory:
- `normalize-options.ts` - handles option normalization and validation
- `normalized-schema.ts` - defines the normalized schema interface
- `create-project.ts` - handles project configuration creation (exported
as `addProject`)
- `create-files.ts` - handles file generation (exported as
`addAppFiles`)
- `create-targets.ts` - handles build/serve target configuration
- `add-dependencies.ts` - handles dependency management (exported as
`addProjectDependencies`)
- `add-linting.ts` - handles ESLint setup (exported as
`addLintingToApplication`)
- `add-proxy.ts` - handles proxy configuration (exported as `addProxy`)
- `index.ts` - exports all the functions
The main `application.ts` file is now much cleaner at ~15 lines,
focusing on orchestrating the generator workflow by calling the
extracted functions. This separation of concerns improves:
- **Maintainability**: Each file has a single responsibility
- **Testability**: Individual functions can be tested in isolation
- **Readability**: Easier to understand what each part does
- **Reusability**: Functions can be potentially reused by other
generators
