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.
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.
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
## 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 -->
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
<!-- 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 we try to generate a library with react it fails because `name` is
required.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This should work out of the box.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30721
<!-- 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 we generate a react library with `--unitTestRunner` OOTB
it will fail when you run the `test` command because of a missing
dependency.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Generating a library with `--unitTestRunner` and then running that test
should work by default.
## 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 create a React, Vue or Node app we add the app name
inside `package.json` under the nx
```
{
"name": "@myworkspace/acme",
"version": "0.0.1",
"private": true,
"nx": {
"name": "acme"
}
}
```
- When we create a publishable library using React/JS generator inside a
ts project references workspace the `--importPath` option.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- Since the original intention is not known we should not automatically
add this to the project's `package.json`
- `importPath` option should not be required when using ts project
references.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
For workspaces that are not using TS project references the result
remains unchanged.
Fixes #
This PR bumps two v21 removals to v22:
1. SWC inline feature -- some people still use it even though it's
experimental. We should rethink how to remove this.
2. Cypress component testing not relying on `@nx/webpack:webpack`
executor -- we need a separate `webpack.cy.config.js` that only
configures the plugins needed Cypress CT.
This PR also keeps the Webpack plugin exports of `@nx/react` and
`@nx/webpack` packages. The `convert-to-inferred` and app generators
have been using the `@nx/react/webpack-plugin` and
`@nx/webpack/app-plugin` already for a while, there's no harm to keep
the exports in the index for older projects if they haven't been
updated.
This PR updates all `.babelrc` file that still uses the deprecated
`classProperties.loose` (deprecated since v18). The top-level `loose`
option does the same thing -- previously the two options handled
different cases because `@babel/preset-env` did not include class
properties.
This PR delays deprecation of `svgr` for `@nx/next`, as Turbopack
supports it now.
This PR also deprecates all SVGR support for v22. It is not a well-used
feature, and the webpack plugin is not maintained. We'll ensure in v22
to add the SVGR webpack plugin to userland configs, but we'll not
maintain it ourselves moving forward.
<!-- 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 -->
Users migrating from Nx 17 can go up to Nx 20.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Users migrating from Nx 19 can go up to Nx 21. Users migrating from Nx
17 or 18 should go to Nx 19 first.. then go to Nx 21.
## 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 -->
`nx:build` cannot be run in parallel with any other tasks. It was an
improper fix for an issue we were facing in our task graph. This is also
not workable if any continuous tasks are running.. which I want
`local-registry` to be running while things are built.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The proper outputs are set on `build` targets. Most of them only need
`README.md` as the output. `nx`, `create-nx-workspace`, and
`create-nx-plugin` are different and need a few more files.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
The 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 #
This PR marks dev/start from `@nx/react/router-plugin` as continuous.
Otherwise, running e2e will hang.
Repro:
- `npx create-nx-workspace@next org --preset=react-monorepo
--appName=demo --e2eTestRunner=playwright` and pick RR For SSR
- Run `nx e2e demo-e2e`
## Current Behavior
<!-- This is the behavior we have today -->
e2e hangs because dev does not finish, and it is not marked as
continuous
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
dev and start from RR should work with e2e
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
A target default (`dependsOn: [^build]`) for atomized e2e tasks is
always generated to work around a previous limitation where tasks
couldn't depend on continuous tasks. That meant we couldn't add the
dependency to the app's serve task and had to add it to the build task.
With continuous tasks now working, that limitation no longer exists.
We're now able to correctly infer the task dependency on the app's serve
task, and therefore, we can and need to remove the generation of
`dependsOn: [^build]` in target defaults so it doesn't override what the
Cypress and Playwright plugins infers.
## Expected Behavior
A target default (`dependsOn: [^build]`) for atomized e2e tasks should
not be generated. Instead, the Cypress and Playwright plugins will infer
the correct `dependsOn` for the task(s) run in the configured web server
command.
## Related Issue(s)
Fixes #
Currently, we provide `targetDefaults` for atomized targets (e.g.
`e2e-ci`) with a glob pattern that may not match nested paths.
i.e.
```
"e2e-ci--**/*": {
"dependsOn": [
"^build",
],
},
```
The `e2e-ci--**/*` pattern should be `e2e-ci--**/**`.
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
The generated `e2e-ci` pattern in `nx.json` does not match nested paths
for split tasks.
## Expected Behavior
The generated `e2e-ci` pattern should apply to all split tasks.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#28842
## Current Behavior
The Cypress and Playwright graph plugins do not infer tasks configured
to take advantage of continuous tasks (do not add the task they run to
start the app/server as a dependency of the e2e task).
## Expected Behavior
The Cypress and Playwright graph plugins should infer tasks configured
to take advantage of continuous tasks.
## Related Issue(s)
Fixes #
## Current Behavior
Continuous tasks are not set up for React Rspack Module Federation
Remote projects.
This is important because `--dev-remotes` is no longer supported with
Crystal Module Federation usage.
## Expected Behavior
Add Continuous Tasks support for React Rspack Module Federation Remote
Projects.
This replaces the need for `nx serve shell --dev-remotes=remote1`.
Instead, the command is simply `nx serve remote1` and continuous tasks
means that the `shell:serve` task is executed correctly.
<!-- 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
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
Jest should be compatible with react-router out of the box.
<!-- 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, there are two issues when using `jest` with react-router out
of the box
1. Test files are not included from `tsconfig`
2. While running the test `jsdom` is missing Node's `TextEncoder` and
`TextDecoder` so compilation fails.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Running a test should work without issues when you create a react-router
app with Jest.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30387
<!-- 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 generate a react app and select `--use-react-router`
and `--bundler=` any other bundler except `vite` you would be forced
into using `vite`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When you generate a React app and opt into using `--use-react-router`
with `--bundler=webpack` (for example) you will get an error stating the
React Router can only be used with `vite`.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Update library generators to set a `development` conditional export for
buildable libraries' `package.json` files and set the
`customConditions` compiler options in `tsconfig.base.json`. This will
only be done for workspaces using the TS solution setup.
## Current Behavior
## Expected Behavior
## Related Issue(s)
Fixes #
This pull request introduces improvements to React Router integration
and removes the Remix preset.
## Key Changes:
- Updated `create-nx-workspace` to support React Router.
- Removed the Remix option from `create-nx-workspace`, but the package
remains to support existing users.
## SSR & React Router Support
- New users who want SSR in their React apps can enable it via the React
option and select React Router for SSR support.
- The ecosystem has shifted to migrating from Remix to React Router for
SSR needs.
- This option is only available for plain React apps and uses Vite.
Other types of React apps (Micro Frontends, Webpack, Rspack, etc.)
remain unaffected.
## Default Routing Behavior
`--routing` is now enabled by default when creating a React app using
`create-nx-workspace`, aligning with Angular’s default behaviour.
This PR introduces the React Router plugin in Nx.
The new functionality adds a react-router plugin entry into `nx.json`,
projects that are React-Router V7 via `react-router.config.(m|c)?[jt]s`
will have their targets inferred.
### Changes
Update the React plugin to have a react-router (RR V7) plugin export.
The RR V7 will only infer targets if we have a
`react-router.config.(m|c)?[jt]s` and also a `vite.config.(m|c)?[jt]s`.
Under the hood the RR V7 CLI uses vite for compilation.
That being said, apps are not limited to only use vite for RR V7. Should
you choose to use it the compilation will not be done via RR V7 CLI.
## Current Behavior
To create a new workspace that uses the new TS solution setup the
`--workspaces` flag must be provided (Node, React, and Vue stacks).
## Expected Behavior
New workspaces should be created by default using the new TS solution
setup (Node, React, and Vue stacks). Users can opt out of it by
providing the `--no-workspaces` flag.
## Related Issue(s)
Fixes #
Add a `useProjectJson` option to project generators to allow users to
opt in/out of generating the Nx configuration in a `project.json` file.
## Current Behavior
## Expected Behavior
## Related Issue(s)
Fixes #
## Current Behavior
Moving a project included in the package manager workspaces setup to a
new destination that's not matched by that configuration results in the
project not included in the package manager workspaces setup.
## Expected Behavior
Moving a project included in the package manager workspaces setup to a
new destination that's not matched by that configuration should result
in the new destination included in the workspaces setup.
## 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 #
<!-- 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 #
## Current Behavior
In the TS solution setup, several project generators produce the runtime
tsconfig files (e.g. `tsconfig.lib.json`) with the `outDir` set to
`out-tsc/<project name>`. This causes issues with the inferred
`typecheck` task because the project `package.json` has the `types`
export pointing to `dist/...`, which wouldn't be produced by
`typecheck`.
## Expected Behavior
In the TS solution setup, project generators should produce the runtime
tsconfig files (e.g. `tsconfig.lib.json`) with the `outDir` set to a
path (`dist`) that matches the value in the project `package.json`'s
`types` export.
## Related Issue(s)
Fixes #
## Current Behavior
- Generating a non-buildable library in a workspace using the TS
solution setup where a plugin registration for `@nx/js/typescript`
already exists and doesn't configure a build target, results in that
plugin registration being updated excluding the new project and a new
registration being added including the project but inferring the build
target.
- Generating a library in a sub-directory that matches a pattern in the
package manager workspaces configuration, results in a more specific
pattern being added to the workspace configuration.
## Expected Behavior
- Generating a non-buildable library in a workspace using the TS
solution setup where a plugin registration for `@nx/js/typescript`
already exists and doesn't configure a build target, should not modify
that plugin registration and it should not add an extra one.
- Generating a library in a sub-directory that matches a pattern in the
package manager workspaces configuration, should not add a more specific
pattern.
## Related Issue(s)
Fixes #
## Current Behavior
Vite config temp files can sometimes cause errors to be thrown by
ESLint.
## Expected Behavior
Vite config temp files should be ignored by ESLint.
## Related Issue(s)
Fixes #
