<!-- 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
- fix(rspack): choosing nest as framework should not result in error
#31204
- fix(rspack): add deprecation message for application generator
- fix(rspack): ensure application generated projects are added to
excludes
## Current Behavior
Running the `@nx/rspack:application` generator with `--framework=nest`
results in an error due to mix of inferred and executor usage throughout
the generation process.
## Expected Behavior
Running the generator should pass without failure and create a working
project.
Deprecate the generator in favour of using project specific packages
(@nx/react etc)
## Related Issue(s)
Fixes#31204
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
Co-authored-by: Coly010 <Coly010@users.noreply.github.com>
## Current Behavior
rspack.config.ts options related to optimizations are removed if the
mode is not "production". This makes the compile fail for all
non-production builds.
## Expected Behavior
If mode isn't set to "production" configuration related to optimization
should be passed through.
## Related Issue(s)
Fixes#31268#30292
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
## Current Behavior
The `convert-to-rspack` generator does not handle projects that use
Prerendering or App Shell
## Expected Behavior
The generator sets up Prerendering and App Shell
Fixes https://github.com/nrwl/angular-rspack/issues/88
## Current Behavior
We currently install Rspack at `^1.2`. The latest version of Rspack is
`1.3.8`
Angular Rspack now requires at least `1.3.5`
## Expected Behavior
Rspack installations should use latest version of `1.3.8`
This commit also contains various changes to ensure serve-static tasks
depend on their build.
BREAKING CHANGE: Remove deprecated static-serve target name from Remix
Inferred Tasks in favour of serve-static.
## Current Behavior
The `HtmlRspackPlugin` does not support interpolation of %VAR% in the
index.html.
This is supported with a custom Webpack Plugin for `@nx/webpack` for
generating index.html files.
## Expected Behavior
The `@nx/rspack` plugin should support the same feature set as webpack
for seamless migration.
Add a new `WriteIndexHtmlPlugin` for Rspack to support this.
It should only be used when `useLegacyHtmlPlugin` is set to true
<!-- 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 #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
When using Module Federation with an app that defines styles as a
separate entry point, HMR fails to update in the browser. Instead of
updating automatically, a warning is shown in the console related to a
missing chunk. A full-page reload is typically required, which is not
the intended behaviour.
## Expected Behavior
<!-- This is the behaviour we should expect with the changes in this PR
-->
HMR should work with styles as an entrypoint.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
The default is for `runtimeChunk` is `config.optimization.runtimeChunk =
{name: 'runtime'}` it is _not_ the same as `single` but the naming will
be the same.
Fixes#9582
<!-- 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, the `convert-to-inferred` generator description inside the
rspack package references Webpack when it should reference Rspack
instead.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The `convert-to-inferred` generator description should reference Rspack
instead of Webpack.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes
## Current Behavior
The `sassImplementation` option for Webpack and Rspack is set to `sass`
by default.
`sass-embedded` offers a faster alternative.
## Expected Behavior
Switch the default `sassImplementation` option to `sass-embedded`.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
Unit tests are broken after rebase
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Unit tests are passing
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
Rspack and Rsbuild Inference Plugins do not infer `continuous` for serve
tasks.
## Expected Behavior
Correctly infer `continuous` true.
## Current Behavior
The `@nx/rspack` graph plugin reuses the potentially existing
`TS_NODE_COMPILER_OPTIONS` to set the `env` property of the inferred
tasks for a TS config file. This is not correct since the env var could
have a different value (or not exist at all) when running tasks compared
to when the graph plugin runs.
## Expected Behavior
The `@nx/rspack` graph plugin should not reuse any existing
`TS_NODE_COMPILER_OPTIONS` when inferring tasks for a TS config file.
## Related Issue(s)
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 fixes a runtime error in our NestJS application:
```
TypeError: Cannot read properties of undefined (reading 'get')
```
The root cause was that services were not being injected correctly due
to missing metadata reflection, which NestJS relies on for its
dependency injection system to resolve services.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
We now fully support NestJS's DI system by adding:
```ts
transform: {
legacyDecorator: true,
decoratorMetadata: true,
}
```
This restores proper behavior, and services are injected as expected.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#29136
## Current Behavior
The `@nx/webpack` depends on `webpack` at version `^5.80.0`. Despite the
`^` allowing it to resolve to a higher minor, there has been no
migration to force users onto a higher version.
There is a security vulnerability with version `5.88.0`.
## Expected Behavior
Ensure users are migrated to a version where the security vulnerability
has been fixed.
## Related Issue(s)
Fixes#29755
## 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
## Current Behavior
The `NxRspackAppPlugin` and `NxWebpackAppPlugin` will not provide
typechecking if using TS Solution setup because it already has a
typecheck target.
However, this means that typechecking will not be run during serve.
## Expected Behavior
Allow typechecking to run during serve even with TS Solution setup
## Related Issue(s)
Fixes#29267
This PR fixes and issue where the standard `output.clean` option is
ignored and replaced by the Nx-specific `deleteOutputPath` option on the
`NxAppWebpackPlugin` and `NxAppRspackPlugin` plugins.
We want to allow users to use standards over our own features, so if we
see that `output.clean` is set in webpack/rspack config, then we use
that value.
For example, an Rspack config could be:
```js
const { NxAppRspackPlugin } = require("@nx/rspack/app-plugin");
const { join } = require("path");
module.exports = {
output: {
path: join(__dirname, "dist/demo"),
clean: false, // <-- THIS DOES NOT WORK!
},
plugins: [
new NxAppRspackPlugin({
// ...
}),
],
};
```
But even though `output.clean` is `false`, each build will still delete
`dist`. The only way to disable that behavior is to use the Nx-specific
option like this:
```js
const { NxAppRspackPlugin } = require("@nx/rspack/app-plugin");
const { join } = require("path");
module.exports = {
output: {
path: join(__dirname, "dist/demo"),
},
plugins: [
new NxAppRspackPlugin({
deleteOutputPath: false,
// ...
}),
],
};
```
## Current Behavior
Setting `output.clean` in Webpack/Rspack config does nothing, and we
always default our own `deleteOutputPath` to `true`.
## Expected Behavior
Setting `output.clean` standard option is respected.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
`@nx/rspack` set ups currently install `@rspack/plugin-minify` which has
been deprecated. It is also unused in the configurations that are
generated.
## Expected Behavior
Remove unused the unused `@rspack/plugin-minify`
## Related Issue(s)
Fixes#30318
## Current Behavior
The `NxAppWebpackPlugin` and `NxAppRspackPlugin` both always set `<base
href="` even when it is set to undefined.
## Expected Behavior
If `baseHref` is set to false, do not set `<base href`.
## Related Issues
#30291
## Current Behavior
In a few different places (Crystal plugins, executors, generators,
helpers) where `ts-node` compiler options are overridden and
`moduleResolution` is being set to something other than `node16`,
`nodenext`, or `bundler`, an error can occur if the `customConditions`
compiler option is being used.
## Expected Behavior
When overriding the `ts-node` compiler options and changing forcing
`moduleResolution` to have a value that's incompatible with
`customConditions`, the latter should be unset (set to `null`) to avoid
errors.
## Related Issue(s)
Fixes #
## Current Behavior
The current `NxModuleFederationPlugin` does not support SSR
## Expected Behavior
The current `NxModuleFederationPlugin` supports SSR
Infer the relevant ts-node compiler options to support an Rspack config
file using TypeScript as per https://rspack.dev/config/#using-ts-node.
## Current Behavior
## Expected Behavior
## Related Issue(s)
Fixes #
The following are the main changes in the context of the TS solution
setup:
- Ensure `name` in `package.json` files is set to the import path for
all projects
- Set `nx.name` in `package.json` files when the user provides a name
different than the package name (import path)
- Clean up project generators so they don't set the `nx` property in
`package.json` files unless strictly needed
- Fix `@nx/vue:application` generator so it creates the Nx config in a
`package.json` file for e2e projects
- Ensure `@types/node` is installed in `vitest` generator
- Fix generated Vite config typing error (surfaced with Vite 6)
- Ensure `jsonc-eslint-parser` is installed when the
`@nx/dependency-checks` rule is added to the ESLint config
- Misc minor alignment changes
## Current Behavior
## Expected Behavior
## Related Issue(s)
Fixes #
## Current Behavior
Webpack and Rspack currently use `sass` and its Legacy API with
`sass-loader`.
There is also no method to pass stylePreprocessorOptions other than
`includePaths` to the loaders.
## Expected Behavior
Switch to using `modern-compiler` api to remove deprecation warnings and
improve build performance.
Allow users to choose between `sass` and `sass-embedded` for sass
compiler implementation.
Expand the `stylePreprocesserOptions` interface to accept
`includePaths`, `sassOptions` and `lessOptions` that will be passed to
the appropriate loader.
## Current Behavior
Our Rspack support currently leverages `fork-ts-checker-webpack-plugin`
to handle typechecking during build.
## Expected Behavior
Switch to using `ts-checker-rspack-plugin` for better memory management
and typecheck support.
## Current Behavior
If the lock file is missing the `@nx/rspack/plugin` plugin throws a
cryptic error.
## Expected Behavior
The `@nx/rspack/plugin` should handle a missing lock file.
## Related Issue(s)
Fixes #
## Current Behavior
Rspack v1.2.3 was released with some issues around resolving and
transforming modules throwing errors at build time.
## Expected Behavior
Pin Rpsack to 1.2.2 until a solution for the above problem can be
resolved.
This PR updates the Rspack Plugin to be inferred by default.
### Currently
When you generate a project using rspack it would not be inferred and
would add the executor to `project.json`.
### After
Generating a project using rspack will add it to inferred plugins inside
`nx.json` and update the `rspack.config.js` to be a standard config and
use Nx plugins.
## Current Behavior
Currently, calculating nodes via the `@nx/rspack/plugin` takes a long
time because the hash generation attempts to hash every source file.
This is problematic because the targets that are inferred do not rely on
the source files themselves and rather just the config file.
It also means the time taken to infer the targets grows as the project
grows.
## Expected Behavior
Calculate the hash based off the config file and the installed
dependencies, allowing it to scale as the project grows and allowing it
to be invalidated if dependencies change.
## Tested Results
Application with 90k files
Previous: 2mins
New: 1.18s
Updates some generators to ensure the build tool produces the output
contained within the project root for the TS solution setup.
## Current Behavior
## Expected Behavior
## Related Issue(s)
Fixes #
## Current Behavior
When we resolve the config file for rspack, it can be provided in a few
different formats:
```
config
config.default
config.default.default
```
We do not handle if the config is provided in any of the named default
methods.
## Expected Behavior
Handle named defaults for the resolved user config for Rspack.
Reproduction repo: https://github.com/olaf-cichocki/sample
## Current Behavior
When using mjs config file we end up with following error:
```
⚠️ Unable to construct project graph.
Failed to process project graph. Run "nx reset" to fix this. Please report the issue if you keep seeing it.
Failed to process project graph. Run "nx reset" to fix this. Please report the issue if you keep seeing it.
An error occurred while processing files for the @nx/rspack/plugin plugin.
- apps/appA/rspack.config.mjs: require() of ES Module /Users/miro/Dev/Testbox/sample/apps/appA/rspack.config.mjs not supported.
Instead change the require of /Users/miro/Dev/Testbox/sample/apps/appA/rspack.config.mjs to a dynamic import() which is available in all CommonJS modules.
Error [ERR_REQUIRE_ESM]: require() of ES Module /Users/miro/Dev/Testbox/sample/apps/appA/rspack.config.mjs not supported.
Instead change the require of /Users/miro/Dev/Testbox/sample/apps/appA/rspack.config.mjs to a dynamic import() which is available in all CommonJS modules.
at resolveUserDefinedRspackConfig (/Users/miro/Dev/Testbox/sample/node_modules/.pnpm/@nx+rspack@20.2.0-beta.3_@babel+traverse@7.25.9_@module-federation+enhanced@0.7.6_react-dom@1_7iwdcl66l7me4m7pewq22wegge/node_modules/@nx/rspack/src/utils/resolve-user-defined-rspack-config.js:19:16)
at createRspackTargets (/Users/miro/Dev/Testbox/sample/node_modules/.pnpm/@nx+rspack@20.2.0-beta.3_@babel+traverse@7.25.9_@module-federation+enhanced@0.7.6_react-dom@1_7iwdcl66l7me4m7pewq22wegge/node_modules/@nx/rspack/src/plugins/plugin.js:65:98)
at createNodesInternal (/Users/miro/Dev/Testbox/sample/node_modules/.pnpm/@nx+rspack@20.2.0-beta.3_@babel+traverse@7.25.9_@module-federation+enhanced@0.7.6_react-dom@1_7iwdcl66l7me4m7pewq22wegge/node_modules/@nx/rspack/src/plugins/plugin.js:51:34)
at async /Users/miro/Dev/Testbox/sample/node_modules/.pnpm/nx@20.2.0-beta.3/node_modules/nx/src/project-graph/plugins/utils.js:10:27
at async Promise.all (index 0)
```
## Expected Behavior
Using EU module config files is supported
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Thank you @olaf-cichocki for reporting the issue.
<!-- 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. -->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#29514
---------
Co-authored-by: Colum Ferry <cferry09@gmail.com>
This PR updates our generators to no longer generate with `nx` in
`package.json` by default. The only times it is needed is if you pass
add `tags` or `implicitDependencies` to the project config.
This PR replaces our `projectType` checks to use the `getProjectType`
util from `@nx/js` to prefer the project config, but otherwise will
check for our conventions (e.g. using `exports` for libs,
`tsconfig.lib.json` vs `tsconfig.app.json`).
## Impact
- There shouldn't be any behavioral changes to existing projects that
have explicit `projectType`, `name`, etc. in with `project.json` or
`package.json` (via `nx` property).
- For new projects created under the new TS setup, the `nx` property
will no longer be there. Generators with logic that depend on
`projectType` will now check for `tsconfig.lib.json` and
`tsconfig.app.json` (so all of our generators are covered). If none of
those tsconfig files are found, then we check `package.json`, since
libraries are required to have `exports` to be consumed.
This pull request includes changes to support multi-configuration mode
for both Rspack and Webpack.
## Currently
Currently our plugin only supports single configurations
```js
module.exports = {
...config
}
```
Which works in most cases but some applications can have mutliple
configs that serve different platforms.
## Changes
With these changes, the Webpack and Rspack plugins will also support
multi-configuration.
```js
module.exports = [
{ ...clientConfig },
{ ...serverConfig }
]
## Current Behavior
We currently have no support for React 19, generating only React 18
applications.
## Expected Behavior
Add utils to determine what version of React is installed in the
workspace.
If React 18 is the main version of react installed, continue to generate
React 18 projects.
If React 19 is the main version of react installed, generate React 19
projects.
If no React version is installed or can be determined, generate React 19
projects.
## Current Behavior
We currently set Subresource Integrity (SRI) on all scripts injected via
`HtmlRspackPlugin`.
This should be configurable.
## Expected Behavior
Expose an option to set SRI - mark false by default to match Rspack's
`HtmlRspackPlugin` behaviour
This PR adds `build-deps` and `watch-deps` targets to buildable JS
projects to help with incremental builds.
A use-case for this is if an app (e.g. Vite React app) has buildable
dependencies that need to be rebuilt when they change.
Say, you create a React app and lib as follows:
```
nx g @nx/react:app apps/react-app --bundler vite
nx g @nx/react:lib packages/react-lib --bundler vite
```
And import `react-lib` inside the app.
```jsx
import { ReactLib } from '@acme/react-lib';
//...
return <ReactLib />
```
The user can then run:
```
nx watch-deps react-app
```
And then serve the app in another terminal:
```
nx serve react-app
```
Then whenever code is updated for a buildable dependency, it'll be
rebuilt and then reloaded in the app.
