## 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
The `@swc/cli` version we're currently using has a security
vulnerability due to dependency on `cross-spawn`. This PR updates it to
the version that fixes the vulnerability.
Advisory: https://github.com/advisories/GHSA-3xgq-45jj-v275
## Current Behavior
Existing and new JS workspaces have a high security warning.
## Expected Behavior
No high security warning for new workspaces, and existing ones are
updated.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
## Current Behavior
When a package has a subpath pattern like the following:
```json
{
"exports": {
"./*": {
"types": "./dist/lib/*/index.d.ts",
"import": "./dist/lib/*/index.js",
"default": "./dist/lib/*/index.js"
}
}
}
```
When constructing the graph the project is not picked as a dependency of
others projects that import from the package using a path that matches
that subpath pattern. This is currently happening because the current
resolution is wrongly using `minimatch` to match those patterns instead
of the [Node.js spec for resolving subpath
patterns](https://nodejs.org/docs/latest-v22.x/api/esm.html#resolution-algorithm-specification).
## Expected Behavior
Subpath patterns should be processed after the [Node.js
spec](https://nodejs.org/docs/latest-v22.x/api/esm.html#resolution-algorithm-specification)
and the graph should pick up dependencies when used.
## Related Issue(s)
Fixes#30342
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
There is no dependency between the inferred `typecheck` and `build`
tasks. Depending on their run order, this can result in duplicated
processing (type-checking, `.d.ts` generation). Given there's no
explicit dependency, the order would be non-deterministic.
Additionally, when `outDir` is set in the tsconfig files, it's used
as-is in the currently inferred outputs for `typecheck`. This can result
in extra files being cached for the task.
## Expected Behavior
For optimum performance, the inferred `typecheck` task should depend on
the `build` task. The `typecheck` task's outputs should be more granular
so that only the relevant files (declaration files and declaration map
files if enabled) are cached.
### Explanation
Consider a typical setup with specific tsconfig file for files with
different concerns:
- tsconfig.lib.json: TS configuration for the library runtime files
- tsconfig.spec.json: TS configuration for the unit test files
- tsconfig.json: TS solution configuration, a solution file that
references the specific config files above
When running `tsc -b tsconfig.lib.json --verbose` (build), we can see
how the `tsconfig.lib.json` TS project is built:
```bash
Projects in this build:
* tsconfig.lib.json
Project 'tsconfig.lib.json' is out of date because output file 'dist/tsconfig.lib.tsbuildinfo' does not exist
Building project '<workspace root>/packages/pkg1/tsconfig.lib.json'...
```
After that, if we run `tsc -b tsconfig.json --emitDeclarationOnly
--verbose` (typecheck), we'll see how the `tsc` output for
`tsconfig.lib.json` is reused:
```bash
Projects in this build:
* tsconfig.lib.json
* tsconfig.spec.json
* tsconfig.json
Project 'tsconfig.lib.json' is up to date because newest input 'src/lib/file.ts' is older than output 'dist/tsconfig.lib.tsbuildinfo'
Project 'tsconfig.spec.json' is out of date because output file 'out-tsc/jest/tsconfig.spec.tsbuildinfo' does not exist
Building project '<workspace root>/packages/pkg1/tsconfig.spec.json'...
```
The relevant bit above is `Project 'tsconfig.lib.json' is up to date
because newest input 'src/lib/file.ts' is older than output
'dist/tsconfig.lib.tsbuildinfo'`. Because the initial `build` task
already typechecks and produces `.d.ts` files for the
`tsconfig.lib.json`, when the `typecheck` task runs, `tsc` identifies
that the outputs for that config files were already produced and can be
reused.
If we were to run the tasks in the inverse order, the results would be
different:
```bash
> npx tsc -b tsconfig.json --emitDeclarationOnly --verbose
Projects in this build:
* tsconfig.lib.json
* tsconfig.spec.json
* tsconfig.json
Project 'tsconfig.lib.json' is out of date because output file 'dist/tsconfig.lib.tsbuildinfo' does not exist
Building project '<workspace root>/packages/pkg1/tsconfig.lib.json'...
Project 'tsconfig.spec.json' is out of date because output file 'out-tsc/jest/tsconfig.spec.tsbuildinfo' does not exist
Building project '<workspace root>/packages/pkg1/tsconfig.spec.json'...
> npx tsc -b tsconfig.lib.json --verbose
Projects in this build:
* tsconfig.lib.json
Project 'tsconfig.lib.json' is out of date because buildinfo file 'dist/tsconfig.lib.tsbuildinfo' indicates there is change in compilerOptions
Building project '<workspace root>/packages/pkg1/tsconfig.lib.json'...
```
Note how when the `build` task is run, `tsc` identifies that there was a
change in `compilerOptions` (`--emitDeclarationOnly`) and it requires
building the project. This is because the `typecheck` task only
generates declaration files and the `build` task must also emit the
transpiled `.js` files.
### Benchmark
Running those two different flows in a simple (non-Nx) project with a TS
configuration structure like the one mentioned above and with 5000 TS
files split in half for runtime and test files yields the following:
```bash
hyperfine -r 5 -p "rm -rf dist out-tsc" \
-n "build => typecheck" "npx tsc -b tsconfig.lib.json && npx tsc -b --emitDeclarationOnly" \
-n "typecheck => build" "npx tsc -b tsconfig.json --emitDeclarationOnly && npx tsc -b tsconfig.lib.json"
Benchmark 1: build => typecheck
Time (mean ± σ): 6.832 s ± 0.094 s [User: 11.361 s, System: 1.060 s]
Range (min … max): 6.734 s … 6.985 s 5 runs
Benchmark 2: typecheck => build
Time (mean ± σ): 8.789 s ± 0.015 s [User: 14.817 s, System: 1.267 s]
Range (min … max): 8.771 s … 8.812 s 5 runs
Summary
build => typecheck ran
1.29 ± 0.02 times faster than typecheck => build
```
## 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 -->
Currently, if you have a webpack application that uses out
NxWebpackAppPlugin and has a non-buildable lib that has exports with
extension enabled for example:`export * from './lib/lib8446520.js';`.
The app fails to build.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When using webpack and including libraries that contain extension it
should resolve.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30492
## Current Behavior
Buildable libraries using `tsc` for `build` don't get a `typecheck`
task, which results in test files not being type-checked.
## Expected Behavior
The `typecheck` task should be inferred, and test files should be
type-checked.
## Related Issue(s)
Fixes #
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
Add `buildLibsFromSource` to the `@nx/rollup:rollup` executor to bring
it to parity with Webpack/Rspack/Vite. This allows the bundle to point
to dist if `buildLibsFromSource: false` is set, which enables
incremental builds.
<!-- 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. -->
Note: This only applies to workspaces using tsconfig paths, as that
linking mechanism is assumed by `buildLibsFromSource`. For NPM
workspaces, whatever is defined in `package.json` exports is used as we
use Node resolution in the new setup.
## Current Behavior
`buildLibsFromSource` does not exist
## Expected Behavior
`buildLibsFromSource exists
## 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 -->
With a project structure where build.gradle.kts is defined in a separate
buildSrc directory, and not in the root project directory where
`gradlew` is defined, the gradle project is not included in nx project
graph. This is a valid gradle project configuration, with project-report
tasks configured. Running ./gradlew projectReport works and builds the
projectReport.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
With the fix, as long as expected tasks - projectReport or
projectReportAll - is defined, nx should be able to build the nx graph
regardless of the location of the `build.gradle` or `build.gradle.kts`
file.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#29783
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.
## Current Behavior
Nx currently does not offer an automated method for switching from an
Angular Webpack build to an Angular Rspack build.
## Expected Behavior
Provide a generator `convert-to-rspack` in `@nx/angular` that will allow
conversion from an Angular Webpack build to an Angular Rspack build.
Usage: `nx g convert-to-rspack --project=myapp`
## TODO
- [x] handle more builder options
- [x] take existing custom webpack configs and migrate into the rspack
config that is created
<!-- 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
Cache artifacts are removed based on age at a random interval. There is
not a way to set a max size for the cache, so it can grow quite large in
certain repos
## Expected Behavior
Cache size can be controlled via `maxCacheSize` in `nx.json`. Cache
artifacts are removed based on usage until the limit has been reached.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
---------
Co-authored-by: FrozenPandaz <jasonjean1993@gmail.com>
Update an e2e test expectation that got outdated after two different
changes were merged.
## 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 #
<!-- 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 -->
If we are using `esbuild` as our bundler and ts project references
(`--workspaces`) local libraries are not building are not resolved in
the build artifacts.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When using ts project references with esbuild all types libraries
(buildable / non-buildable) should work out of the box.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Using vitest whenever we merge configs from executors and the config
file. The executors should override the option which has be set inside
of the config file.
<!-- 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 `reportsDirectory` option which can be set when using
`@nx/vite:test` is not override the generated coverage directory path.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
When the `@nx/vite:test` executor runs the option `reportsDirectory`
should override the option set inside `vite.config`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#30223
This PR adds support for skipping `typecheck` targets when using
`@nx/js/typescript`. Inside `tsconfig.json` for each project, you can
set `nx.addTypecheckTarget` to `false` to not infer `typecheck`.
This allows use to skip `typecheck` for JS projects using `tsc` to
build. Since `tsc` is already used during build, we don't need to run
`typecheck` that is just duplicated work.
<!-- 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
JS libs using `tsc` to build will do typechecking twice. Once during
`build` and once during `typecheck`.
## Expected Behavior
JS libs using `tsc` do not infer `typecheck` by default. And users can
change this behavior by setting `nx.addTypecheckTarget` in
`tsconfig.json`.
## Related Issue(s)
<!-- 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
`@nx/vite:build` executor does not support Vite 6 Environments API
## Expected Behavior
`@nx/vite:build` executor builds all environments when Vite 6 is
detected
This PR brings back the CRA migration that was missing since Nx 18.
## Current Behavior
<!-- This is the behavior we have today -->
`nx init` does not migrate CRA apps
## Expected Behavior
`nx init` migrates CRA apps to Vite since CRA is deprecated
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
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.
<!-- 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 -->
- call init generator using implementationFactory, causing issue because
schema.json file isnt respected, and then NX_INTERACTIVE is never set to
true
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- change back to run init command
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
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
Nx currently supports Vite at version 5. Nx does not generate vite
configurations using Vite 6 which has been released.
## Expected Behavior
Nx should use Vite 6 for vite projects.
## TODO
- [x] Add Package Update Migrations for Existing Projects
- [x] Add AST migrations to handle breaking change in resolve.extensions
- [x] Add migration to install `jsx` or `jiti` to handle processing TS
postcss config files
<!-- 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 -->
- there is no option `fallbackCurrentVersionResolver: 'disk',`
- can't run release for newly created publishable libraries
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
- move code to add release for publishable libraries into its own file
to be reused by other stacks
- add `fallbackCurrentVersionResolver: 'disk',` to project's
release.version. generatorOptions
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes https://github.com/nrwl/nx/issues/29723
This pull request contains a few changes to enhance our swc support for
Next.js with a custom server.
### Issues
Currently, we have a few issues with our configuration when using
executors for Next.js with a custom server:
1. The custom server does not have an independent build configuration.
2. The custom server does not have an independent output directory.
3. Serving via `@nx/next-server` or via `@nx/js:node` with
configurations `production` and `development` does not always work.
(These are contained inside `project.json`).
### Changes
All the above issues have been addressed
1. We now have an independent swc build configuration
called`.server.swrc` (_follows the same format as `.eslintrc`,
`.babelrc`_) etc...
2. Now each custom server output will be named `{app}-server` such that
if you have multiple custom servers for multiple apps the names will not
clash.
3. Serving now works out of the box but can be adjusted to suit your
needs via updating the custom server entry file `main.ts`
When we run inferred Jest tasks with workspaces enabled, it'll result in
an error like this:
```
npm ERR! A complete log of this run can be found in: /Users/jack/.npm/_logs/2025-02-05T13_41_51_079Z-debug-0.log
Error: Command failed: npm config set //localhost:4873/:_authToken "secretVerdaccioToken"
npm ERR! code ENOWORKSPACES
npm ERR! This command does not support workspaces.
```
This is because the cwd is the project root (e.g. `packages/mypkg-e2e`),
and `npm config set` cannot be run on packages inside the workspaces. By
passing `--ws=false`, it'll only be run in the workspace root and won't
error.
## Current Behavior
Jest e2e tests inferred from `@nx/jest/plugin` fail when starting a
local registry.
## Expected Behavior
Jest e2e tests should work even if they are inferred (or have cwd other
than workspace root).
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
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 #
Main fixes:
- Identify dependencies from packages that only expose named exports (no
`.` export)
- Identify dependencies from exports containing wildcards (e.g.
`"./utils/*": "./src/utils/*.js`)
- Disallow identifying dependencies from restricted exports (e.g.
`"./foo": null`)
- Handle conditional exports (e.g. `"exports": { "import":
"./dist/index.js", "default": "./dist/index.js" }`
- Handle invalid `"exports": {}` (by not falling back to `main`)
- Handle projects included or not in package manager workspaces
## Current Behavior
## Expected Behavior
## Related Issue(s)
Fixes#29486
## 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.
<!-- 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 -->
Left a log by accident.
`master` is broken because of migrations misalignment..
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Log is removed
migrations docs are aligned.
## 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 -->
There is no specific API for running things before and after tasks run.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This PR adds an API akin to npm's `preinstall` and `postinstall`.
Plugins can now specify `preTasksExecution` and `postTasksExecution`
functions which run before and after Nx runs tasks respectively.
```ts
import type { PreTasksExecutionContext, PostTasksExecutionContext } from '@nx/devkit';
interface PluginOptions {
field: any;
}
export function preTasksExecution(options: PluginOptions, context: PreTasksExecutionContext) {
console.log('prerun')
}
export function postTasksExecution(options: PluginOptions, context: PostTasksExecutionContext) {
console.log('postrun', context.taskResults)
}
```
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
- Fix server file location for the `@nx/remix:library` generator
- Do not error when generating a buildable Remix library in the TS
solution setup
- Install the correct versions of react-related packages when generating
a React library
## Current Behavior
## Expected Behavior
## Related Issue(s)
Fixes #
## Current Behavior
Creating a new workspace does not prompt for the unit test runner.
## Expected Behavior
Creating a new workspace should prompt for the unit test runner.
For now, this new behavior will be behind the `--workspaces` flag.
## Related Issue(s)
Fixes #
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.
<!-- Please make sure you have read the submission guidelines before
posting an PR -->
<!--
https://github.com/nrwl/nx/blob/master/CONTRIBUTING.md#-submitting-a-pr
-->
<!-- Please make sure that your commit message follows our format -->
<!-- Example: `fix(nx): must begin with lowercase` -->
<!-- If this is a particularly complex change or feature addition, you
can request a dedicated Nx release for this pull request branch. Mention
someone from the Nx team or the `@nrwl/nx-pipelines-reviewers` and they
will confirm if the PR warrants its own release for testing purposes,
and generate it for you if appropriate. -->
## Current Behavior
<!-- This is the behavior we have today -->
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR fixes and issue where generating Nest app in the new TS setup
results in a build error due to missing `experimentalDecorators` option
in tsconfig. Decorators are required for Nest to work, but we do not set
it anymore in `tsconfig.base.json` by default.
## Current Behavior
Nest apps are broken
## Expected Behavior
Nest apps work
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
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 }
]
