## Description
This PR fixes an issue where asset files copied during a build using the
`@nx/js:tsc` executor are placed in the wrong directory depending on the
current working directory from which the `nx` command is executed.
This behavior becomes particularly problematic in scenarios like release
workflows that rely on `preVersionCommand` to run E2E tests. For
instance, when using tools like Jest from the root of an E2E project,
scripts like `start-local-registry` may trigger a build and run the
`preVersionCommand`. However, instead of placing assets in the expected
`dist` folder of the project, they are incorrectly copied relative to
the E2E folder’s location.
## Reproduction Steps
1. Create a new Nx workspace:
```bash
npx --yes create-nx-workspace assets-issue --preset=ts --no-interactive
cd assets-issue
```
2. Add the Nx Plugin package:
```bash
nx add @nx/plugin
```
3. Generate a new plugin:
```bash
nx g @nx/plugin:plugin packages/my-plugin --linter eslint
--unitTestRunner jest
```
4. Add a generator to the plugin:
```bash
nx g @nx/plugin:generator packages/my-plugin/src/generators/my-generator
```
5. Build the plugin from the workspace root:
```bash
nx build my-plugin
```
✅ Assets are copied correctly:
```
dist/packages/my-plugin/generators/files/src/index.ts.template
dist/packages/my-plugin/generators/schema.json
dist/packages/my-plugin/generators/schema.d.ts
```
6. Now build the same project from a nested folder:
```bash
mkdir e2e && cd e2e
nx build my-plugin --skip-nx-cache
```
❌ Assets are copied relative to the current folder:
```
e2e/packages/my-plugin/dist/generators/files/src/index.ts.template
e2e/packages/my-plugin/dist/generators/schema.json
e2e/packages/my-plugin/dist/generators/schema.d.ts
```
## Expected Behavior
The build output—especially copied assets—should always respect the
project’s `outputPath` configuration regardless of where the `nx`
command is invoked from. The behavior should be consistent and **not
influenced by `process.cwd()`**.
The simpleName option is no longer useful as we've moved to using
options "as provided" without transformation. Users should provide the
exact name, directory, and import path they want to use.
## Changes
- Add x-deprecated to schema.json marking for removal in Nx 22
- Add runtime warning when simpleName is used
🤖 Generated with [Claude Code](https://claude.ai/code)
<!-- 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
Users are confused with `--simpleName` with using `--name` AND
`--directory`
## Expected Behavior
We should tell users that only `--name` should be used.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#29508
---------
Co-authored-by: Claude <noreply@anthropic.com>
This PR fixes an issue when you use React with Webpack/Rspack, and
aren't using `@nx/webpack/plugin` or `@nx/rspack/plugin`.
<!-- 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
Project configuration contains this for build options:
```
"styles": ["src/myapp/styles.tailwind"]
```
## Expected Behavior
It shoud be :
```
"styles": ["src/myapp/styles.css"]
```
Which is what we actually generate.
## Current Behavior
The deprecation warning for the old script to decorate the Angular CLI
doesn't state the version in which it will be removed. This was
intentional to allow sufficient time for users to migrate away from it.
## Expected Behavior
The deprecation warning for the old script to decorate the Angular CLI
should state that it will be removed in Nx v22. It has been a long time
since it was deprecated, and it should have provided more than enough
time for users to move away from it.
## Related Issue(s)
Fixes #
## 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.
## 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.
<!-- 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
<!-- 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 #
<!-- 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 #
## 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
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.
…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>
## 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
## Current Behavior
<!-- This is the behavior we have today -->
There is no easy way to inspect the hash plan for a task.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
There is a `TaskHashPlanInspector` which can be used to provide details
about the hash plan for a task.
## Example Usage
```js
const { createProjectGraphAsync } = require('@nx/devkit');
const { HashPlanInspector } = require('nx/src/hasher/hash-plan-inspector');
(async () => {
const graph = await createProjectGraphAsync();
const hashPlanInspector = new HashPlanInspector(graph);
await hashPlanInspector.init();
const target = {
project: 'nx',
target: 'build-native',
};
console.log(
JSON.stringify(hashPlanInspector.inspectTask(target), null, 2)
);
})();
```
## 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>
## Current Behavior
TypeScript transformer loading in the js package was limited to standard
Nx/TypeScript transformer plugins and didnt handle different exports
## Expected Behavior
TypeScript transformer loading should support various function-based
transformer formats in a generic way
## Related Issue(s)
Fixes#31411🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Coly010 <Coly010@users.noreply.github.com>
## Current Behavior
The codebase has separate `logError` and `logDebug` functions in the
native logging infrastructure, with both error and debug logging paths.
## Expected Behavior
Consolidate logging to use a single standardized approach. Error
messages are now logged through the debug channel for consistency.
## Related Issue(s)
This change standardizes the logging interface by removing the separate
error logging function and routing all log messages through the debug
logger.
## Current Behavior
When running `nx run <project>` without specifying a target, the command
always fails with an error message "Both project and target have to be
specified", even if the project has a "run" target defined.
## Expected Behavior
When running `nx run <project>` without specifying a target, the command
should check if the project has a "run" target defined. If it does, use
it as the default target. This improves developer experience by allowing
simpler commands like `nx run myapp` instead of `nx run myapp:run`.
## Related Issue(s)
This change improves the developer experience for projects that have a
"run" target defined, making the CLI more intuitive.
## Changes Made
- Modified `packages/nx/src/command-line/run/run-one.ts` to check for a
"run" target when no target is specified
- Added comprehensive test coverage in `e2e/nx/src/run.test.ts` to
verify:
- Projects with a "run" target default to it when no target is specified
- Projects without a "run" target still show the original error message
- Maintains full backward compatibility
## Testing
- All existing tests pass
- Added new e2e tests to verify the behavior
- Ran full validation suite (`nx prepush`) successfully
## Current Behavior
The `pnpm build:wasm` command fails with compilation errors due to
missing dependencies and system-dependent features being included in
WASM builds.
## Expected Behavior
WASM builds should compile successfully by excluding features that
require system access (IPC, terminals, file locking, etc.) while
maintaining these features for native builds.
## Related Issue(s)
Fixes WASM build compatibility issues
## Changes Made
### Core Changes
- Added conditional compilation flags (`#[cfg(not(target_arch =
"wasm32"))]`) to IDE console modules
- Made `socket_path` module conditional for non-WASM targets only
- Fixed unused import warnings for WASM builds in `file_lock.rs` and
`walker.rs`
### Generated File Updates
- Updated TypeScript definitions and JavaScript bindings to reflect
conditional compilation
- WASM builds now exclude system-dependent features like terminal UI and
database connections
### Technical Details
The IDE console functionality depends on:
- `interprocess` crate for IPC communication
- `jsonrpsee` crate for JSON-RPC messaging
- Terminal and file system features not available in WASM
These features are now properly isolated for native targets only while
maintaining full functionality for standard Node.js builds.
## Testing
- ✅ `pnpm build:wasm` now passes successfully
- ✅ Generated bindings properly exclude WASM-incompatible features
- ✅ Native builds retain all existing functionality
## Current Behavior
When generating a pruned pnpm lockfile, if there's no external node with
a default version for a given package and the dependency specification
for the package includes a Semver range specifier, an error is thrown.
## Expected Behavior
When generating a pruned pnpm lockfile, the parser should correctly
handle the scenario where there's no external node with a default
version for a given package, and the dependency specification for the
package includes a Semver range specifier.
## Related Issue(s)
Fixes#28627
ESLint added experimental support for typescript config files since
[9.9.0](https://eslint.org/blog/2024/08/eslint-v9.9.0-released/#experimental-typescript-configuration-files),
and as of
[9.18.0](https://eslint.org/blog/2025/01/eslint-v9.18.0-released/#stable-typescript-configuration-file-support)
that support is stable. This PR add ts/mts/cts to the list of known
eslint config files, and adds the same extensions to config file
generators
## Current Behavior
When using the eslint executor with a ts file, returns error "When using
the new Flat Config with ESLint, all configs must be named
eslint.config.js or eslint.config.cjs and .eslintrc files may not be
used. See
https://eslint.org/docs/latest/use/configure/configuration-files"
When using the eslint plugin, the inferred task is not created for
projects that do not have a non-ts eslint config.
### Workarounds
- Compiling ts rules/configs in a project. Introduces other issues
- Using jiti or comparable
- For plugin users, having a fake eslint.config.js at the root allows
the inferred task to be created. ESLint will still use the ts config.
- Cache targets are wrong
- Complications in non-monorepo workspaces
## Expected Behavior
When using the eslint executor with a ts file, no error is thrown.
When using the eslint plugin with a ts file, the inferred task is
created.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
No issues, but addresses [this
discussion](https://github.com/nrwl/nx/discussions/29710#discussion-7856165)
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
Current Behavior
The webpack and rspack plugins for handling non-buildable libraries
don't properly process the exports field in package.json. They
incorrectly assume libraries have only a single entry point, typically
through a barrel file (index.ts).
When a library defines multiple export paths using the exports field
(e.g., "./*": "./src/*.ts"), the plugins fail to generate the correct
allowlist patterns for webpack externals. This causes build failures
when trying to use non-buildable libraries that expose multiple entry
points without barrel files.
Expected Behavior
The webpack and rspack plugins should properly parse the exports field
from package.json and generate appropriate allowlist patterns for all
exported subpaths. This includes:
Handling wildcard patterns ("./*": "./src/*.ts")
Processing conditional exports (import/require/development)
Supporting exact subpath exports ("./utils": "./src/utils.ts")
Escaping special characters in package names for regex patterns
Gracefully falling back to reading package.json directly when metadata
is unavailable
Co-authored-by: Claude <noreply@anthropic.com>
## Current Behavior
Rollup build fails on Windows with errors like this:
```
[plugin rpt2] error TS6059: File '/foo/bar/baz.ts' is not under 'rootDir' 'C:/foo/bar'. 'rootDir' is expected to contain all source files.
```
This is because since
81fe7bb278
the `tsconfig` path passed to `rollup-plugin-typescript2` is built using
`joinPathFragments`, which removes the drive letter on Windows.
## Expected Behavior
Rollup build should not fail.
closed#30235
## Current Behavior
nxComponentTestingPreset for webpack cannot use rspack as an executor.
## Expected Behavior
nxComponentTestingPreset for webpack can use webpack or rspack as an
executor.
## Related Issue(s)
#30235Fixes#30235
<!-- 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
- Create a project that uses @nx/rspack:rspack as build target with
SkipTypeChecking set to false.
- Run build target for project.
- Type check has not been run and will not bail in case of any
typescript errors
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- It should run type checking as documented:
https://nx.dev/nx-api/rspack/executors/rspack#skiptypechecking
I looked at the webpack executor and there it also runs the type check
based on `skipTypeChecking` and not the `typeCheck` alias. So I've
adjusted it accordingly for the rspack executor.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#31026
---------
Co-authored-by: Colum Ferry <cferry09@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 -->
esbuild breaks on function checks and improperly handles dangling
promises, preventing the program to exit successfully.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The program should exit properly and no zombie processes kept 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(vite): must begin with lowercase` -->
## Current Behavior
Running `nx test … --reporter=verbose` (or any additional Vitest
reporter) on
projects that use **Vitest ≥ 0.29** hangs indefinitely at the end of the
run.
`vitest` itself finishes, but the Nx task-runner never receives the
*done*
signal because **`NxReporter` only implements the legacy
`onFinished()` hook**.
When multiple reporters are configured, Vitest now emits
`onTestRunEnd()` instead of `onFinished()`, so the promise in
`NxReporter`
remains unresolved and the worker process stays alive forever.
## Expected Behavior
`nx test` (and affected `nx run-many --target=test`) exits cleanly on
**all**
Vitest versions, regardless of how many reporters are passed.
* `NxReporter` resolves its internal promise via **either**
`onTestRunEnd` (Vitest ≥ 0.29) **or** `onFinished` (Vitest ≤ 0.28).
* No functional change in watch-mode.
* No extra timers or fallbacks – just one shared helper.
## Implementation Notes
* Added `onTestRunEnd` method that delegates to a private
`_handleFinished`.
* Re-implemented `onFinished` as a thin delegate to the same helper.
* Original error-detection logic is untouched.
## Related Issue(s)
Closes nrwl/nx#<insert-issue-number-if/when-one-exists>
Co-authored-by: Paul Bohm <{{GITHUB_NOREPLY_EMAIL}}>
## Current Behavior
Currently when we're using `rollup.config.ts` rollup is picking up wrong
tsconfig. Because of this not everything works as expected:
- `You are using one of Typescript's compiler options 'declaration',
'declarationMap' or 'composite'. In this case 'outDir' or
'declarationDir' must be specified to generate declaration files.` error
appears , because lib tsconfig.json doesn't have outputDir at all
- even if we add outDir to `tsconfig.base.json` we'll have another error
`[!] (plugin typescript) RollupError: [plugin typescript]
@rollup/plugin-typescript TS6377: Cannot write file
'/workspaces/abapify-docs/dist/tsconfig.tsbuildinfo' because it will
overwrite '.tsbuildinfo' file generated by referenced project
'/workspaces/abapify-docs/packages/abap-to-markdown'`
This happens becase it tries to write all tsbuildinfo files into a root
dist folder.
## Expected Behavior
Using rollup.config.ts should just work in a similar way as js|cjs|mjs
config work.
## Solution
According to docs:
> This option supports the same syntax as the
[--plugin](https://rollupjs.org/command-line-interface/#p-plugin-plugin-plugin)
option i.e., you can specify the option multiple times, you can omit the
@rollup/plugin- prefix and just write typescript and you can specify
plugin options via ={...}.
So it means we can use something like this:
```
rollup -c rollup.config.ts --configPlugin typescript={tsconfig:\'tsconfig.lib.json\'}
```
## Related Issue(s)
Solution is taken from this issue::
https://github.com/rollup/plugins/issues/1713#issuecomment-2201138846
## Current Behavior
The Angular ESLint packages are installed with a v20 beta version.
## Expected Behavior
The Angular ESLint packages should be installed with the stable v20
version.
## Current Behavior
The `nx report` command uses tab characters for indenting local
workspace plugins in its output, which creates inconsistent formatting
compared to other sections like 'Registered Plugins' and 'Community
plugins'.
## Expected Behavior
Local workspace plugins should be formatted consistently with other
plugin sections in the report output, without tab indentation.
## Related Issue(s)
This is a minor formatting improvement for better consistency in the nx
report output. No specific issue was filed for this change.
## Current Behavior
When using Node.js subpath imports with the same name in different
projects, the Nx graph incorrectly picks up seemingly random
dependencies between projects that shouldn't exist.
This happens because the result of the resolution performed with
TypeScript is cached using the import path as the cache key. The problem
with that is that multiple projects can have the same subpath import
name pointing to internal files of the project, so when the resolution
is made for the first project (say `project1`), the result will be
cached and incorrectly reused for other projects with the same subpath
import name. So, all projects with the same subpath import name would
resolve the dependency to the first project (`project1`).
The same could happen to projects with TS path mappings defined in the
project's tsconfig file. These TS path mappings would only apply to the
project internally and therefore, other unrelated projects could also
define them with the same name pointing to different files.
## Expected Behavior
The Node.js subpath imports should be handled correctly. The TypeScript
resolution result should be cached safely and scoped to the project from
which the import is being done.
## Related Issue(s)
Fixes#31223
## Current Behavior
Currently, IDE integration setup requires manual configuration and lacks
streamlined auto-installation capabilities for Nx Console. The logging
system also needs improvement for better developer experience.
## Expected Behavior
With these changes, the IDE integration provides:
- Prompt for automatic Nx Console installation with user preferences
- Enhanced native logger with proper formatting and levels
- Better development documentation for IDE setup
- Updated documentation links to use the new format
## Related Issue(s)
<\!-- Please link the issue being fixed so it gets closed when this is
merged. -->
This PR implements IDE integration improvements including Nx Console
auto-installation and enhanced logging capabilities.
## Current Behavior
When running the `lint` task on a project that contains nested projects,
the task runs over all the files, including the ones inside the nested
projects, but the task cache status is not affected by changes to the
files in nested projects. This only happens when the inputs are defined
with `{projectRoot}/...` (what the `@nx/eslint/plugin` infers). The
`{projectRoot}` token scopes the files inside the project without files
in other nested projects. While the `{workspaceRoot}` token would
include every file and wouldn't scope them to any particular project.
## Expected Behavior
The `@nx/eslint/plugin` should infer `lint` tasks with their inputs
using the `{workspaceRoot}` token to support nested projects. This would
be more aligned with what the tool itself does, which runs over all the
files inside the project root regardless of them being inside nested Nx
projects.
Additionally, the difference in behavior between `{workspaceRoot}` and
`{projectRoot}` should be documented.
## Related Issue(s)
Fixes#31264
## Current Behavior
We currently do not have support for Storybook 9, nor any migrations to
help users switch to it.
## Expected Behavior
Support Storybook 9 and add a migration for users to switch to v9
BREAKING CHANGE: Remove deprecated generators:
`@nx/storybook:cypress-project`,
`@nx/react-native:storybook-configuration`, `@nx/react-native:stories`,
`@nx/react-native:component-story`
<!-- 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 -->
Running tests in the Cursor terminal fails.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Running tests in the Cursor terminal should pass.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
