<!-- 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 #
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
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
<!-- 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 test is flaky.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This test is disabled and should be investigated to see why it is flaky.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## 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
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 -->
Currently, if you try to import a ESM lib after you generate a Next.js
application it fails to build due to how the module exports `export *
from './lib/lib8446520.js';`.
This has been addressed with webpack and needs to be extended to
Next.js.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
You should work out of the box and you should be able to import a lib
defined like: `export * from './lib/lib8446520.js';.`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
This is also related to our webpack and rspack packages. Changes have
also been made to them to ensure consistency across bundlers.
Fixes#30714
This PR updates Vite's E2E testing setup for the Vue plugin.
Instead of commenting out the serve for vite and rsbuild when using
playwright we update the test to ensure the ports are available before
attempting to run their preview target.
<!-- 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 -->
Command would fail silently with no error message
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Rather than erroring, Nx will find the next available port and use that.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30915
This PR improves dependency resolution for Node.js apps using Webpack or
Rspack.
While we already handle direct dependencies for non-buildable libraries,
this update ensures that **transitive dependencies** are also properly
included. This guarantees that all necessary dependencies are bundled
when the main app/library is built.
closes: https://github.com/nrwl/nx/issues/31334
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
current gradle task executor will run gradle task as it is. by default,
gradle command will run the tasks itself and its all depends on tasks.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- add excludeDependsOn in gradle executor schema with default value to
true: this allows gradle command to run tasks without its dependsOn
tasks. this improves performance time
- change project graph plugin (dev.nx.gradle.project-graph) to accept
option atomizer:
```
nxProjectReport {
atomized = false
}
```
this will disabled atomized targets to be created. check-ci will not
have dependsOn task ci, it will be test instead.
it will not created any ci and ci--* targets, but check-ci will be
created, but dependsOn test:
<img width="605" alt="Screenshot 2025-05-20 at 3 00 39 PM"
src="https://github.com/user-attachments/assets/a2e0ae20-78a1-4848-a063-5825b169c219"
/>
this is what check-ci target looks like with atomized as true:
<img width="917" alt="Screenshot 2025-05-20 at 2 59 34 PM"
src="https://github.com/user-attachments/assets/33c6af0b-3e45-498d-96d0-4f46c54a8159"
/>
- change dependsOn targets to include both project name and task name.
e.g. `spring-boot:checkFormat
`, so when excludeDependsOn is true, it will exclude exact task
- in batch runner, run test runner and build runner as same time
## 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 Module Federation apps, when remotes are defined using URLs that
include query string or hash fragments (e.g. for cache busting), those
params are not preserved after the application is built.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This PR ensures that query strings and hash fragments are preserved when
resolving or generating remote URLs.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30602
This PR disables Remix+Yarn tests. It looks like the tests aren't set up
correctly, and we're using `yarn` even thought he workspace is set up
with pnpm.
## Current Behavior
The e2e tests running Angular Rspack are not having their builds
minimized currently.
## Expected Behavior
Ensure `NODE_ENV=production` is set when calling the build commands
## Current Behavior
We currently have no method for generating Angular Rspack Module
Federation applications
## Expected Behavior
Update the `host` and `remote` generators to support a `--bundler` flag
to allow users to select Rspack as their bundler method
## Current Behavior
The Angular plugin currently uses Angular Rspack at `^20.7.0`.
The latest release of Angular Rspack is `21.0.0`
## Expected Behavior
Use the latest version of Angular Rspack
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
currently, because it requires to sign locally, so i thought run command
like
`:project-graph:publishToMavenLocal -x
:project-graph:signNxProjectGraphPluginPluginMarkerMavenPublication -x
:project-graph:signPluginMavenPublication -x
:project-graph:publishNxProjectGraphPluginPluginMarkerMavenPublicationToMavenLocal
-x :project-graph:publishPluginMavenPublicationToMavenLocal` would
publish the plugin locally, but it actually does not. it does not throw
an error, but does not do anything at all.
so for e2e tests, it is actually pulling the latest published gradle
plugin from maven rather than test local code, hence the e2e errors.
also, currently project graph build for java version 21, we change it to
java 17 to be used by ocean repo.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
change the command to `./gradlew :project-graph:publishToMavenLocal
-PskipSign=true` and not apply signing when skip sign is true, so this
should be able to publish plugin to local repository.
work with java 17
## 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 -->
Currently, when we use the jest configuration generator it will forcibly
update the jest version if the package already exist.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Now, the jest version will be preserved unless the option is passed to
update the version.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
This repo uses Nx 21.0.0-beta.12
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses Nx 21.0.0-rc.1
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
WIP
<!-- 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 -->
this pr address comments in https://github.com/nrwl/nx/pull/30457
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- update executor description
- use pseudo terminal when run batch command
- add an e2e test to run gradle command in batch
- add migration script to change ciTargetName to ciTestTargetName
## 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. -->
BREAKING CHANGE: We are updating our minimum node version to `20.19.0`
which drops support for all prior versions.
---------
Co-authored-by: Jack Hsu <jack.hsu@gmail.com>
…out of memory
<!-- 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 -->
Many pipelines are stuck because this task is causing agents to run out
of memory.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This test is disabled so that pipelines can complete.
## 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 -->
Gradle tasks are run by invoking the Gradle CLI
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Gradle tasks are run through the Gradle Tooling API and is more
performant.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Jason Jean <jasonjean1993@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 -->
No continuous tasks are used in CI.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The local-registry is a continuous task and it is used in CI.
## 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 -->
gradle import e2e failed from time to time. i think it is flaky test
because it passed before.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
disable this e2e test for now. will enable it later.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR updates `nx release` to use the revamped versioning
implementation by default. It also updates and adds relevant
documentation, and provides an automated migration for the new
configuration structure.
For anyone exclusively versioning TS/JS packages, there should be no
real difference to your experience (although a number of bugs have been
fixed and new features around updating multiple `package.json` files at
once are now available to you with this change).
For the lifecycle of Nx v21, `release.version.useLegacyVersioning` will
remain as a option that can be set to `true` to revert to the old
behavior and configuration structure.
NOTE: This should only be a temporary solution, for example if one of
the plugins you use does provide a `VersionActions` based versioning
implementation yet. The option and legacy implementation will be removed
entirely in Nx v22 (in ~6 months).
BREAKING CHANGE:
**⚠️ For any early adopters of `VersionActions` in Nx 20.8 when it was
opt-in, there are breaking changes to the abstract class here as well.**
`manifestRootsToUpdate` has gone from `string[]` to `manifestsToUpdate:
{ manifestPath: string; preserveLocalDependencyProtocols: boolean; }[]`
to support controlling the local dependency updates per manifest in
order to support advanced source vs dist scenarios, and correspondingly
`isLocalDependencyProtocol` has been removed from the abstract class and
the method will no longer be called from the core logic. It should be
thought of as an implementation detail of `updateProjectDependencies`
instead.
<!-- 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 only way to set if a task is continuous is either directly in
`project.json` or via Project Graph Plugins.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Executors know if they are definitely continuous or not. Plenty of
existing continuous tasks are using executors. Executors are now able to
define if they are continuous in their `schema.json` files. Thus,
existing tasks configured with certain executors will automatically
become continuous.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
- [x] change init to create `createNodes` instead
- [x] unit tests
- [x] test-ci
- [x] test on windows
- [x] help metadata
- [x] external nodes
TODO:
- add publish executor?
- publish to maven central?
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
currently, it uses [project report
plugin](https://docs.gradle.org/current/userguide/project_report_plugin.html).
- pro: no need to maintain this plugin
- con: this plugin gives limited information
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
change the project report plugin to @nxn/gradle/plugin-v1
now the @nx/gradle plugin will use project graph plugin
(dev.nx.gradle.project-graph) created in this pr.
this plugin will create json file that is exactly what nx project grpah
expected.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR updates `lerna-smoke-tests.test.ts` test file to improve the
consistency of the snapshots.
The serializer has been updated to reduce flakiness from spacing and
line breaks.
## Current Behavior
When generating `node` projects with an `e2e` project using Jest, we do
not supply any method for the node application to actually be started
before running the tests.
## Expected Behavior
Using Continuous Tasks, have the e2e project dependOn the serve of the
`node` project such that it is available for the e2e tests to run
against it.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
<!-- This is the behavior we have today -->
<!-- This is the behavior we should expect with the changes in this PR
-->
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
## Current Behavior
Node applications rely on the `@nx/js:node` executor to handle serving.
Unfortunately, it can not be determined if existing usage of the
executor is used for a continuous or finite task.
## Expected Behavior
Generate new node applications with `continuous: true` for their serve
targets
## Current Behavior
The `@nx/jest` graph plugin and the `@nx/jest:jest` executor correctly
force the `moduleResolution: node10` to be used by `ts-node` (used by
`ts-jest`), but don't force using `module: commonjs`, which can result
in issues due to incompatible `module`/`moduleResolution` pair.
## Expected Behavior
The `@nx/jest` graph plugin and the `@nx/jest:jest` executor should
force the `moduleResolution: node10` and `module: commonjs` compiler
options to be used by `ts-node`.
## Related Issue(s)
Fixes #
## Current Behavior
The `@nx/angular` app generator currently does not support generating an
Angular Rspack application. This makes it slightly more difficult for
users to get up and running with Angular Rspack
## Expected Behavior
Add `rspack` as a supported `--bundler` option allowing for easy
generationg of new Angular Rspack apps.
## Current Behavior
The `@nx/react` `host` and `remote` generators currently use executors
to support Module Federation
## Expected Behavior
When `bundler=rspack` use Crystal Module Federation with no executors
for Module Federation
## Related Issues
#30391
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Currently, when you have a Nest app that imports a Nest Lib that is not
buildable inside a TS solution workspace the serving that application
fails because the library is marked as external.
Before we would include these projects as a part of
`tsconfig.compilerOptions.paths`. However, this is no longer possible as
it would not be a valid TS solution setup.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
If a library is not buildable it should be able to be resolved
regardless if we are using TS solutions or the legacy paths.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
closes: #30492, #30410, #30544
