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 #
<!-- 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 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 }
]
This PR updates app and lib generators in the following packages such
that they will generate files with the TS solution setup if it is
detected.
- `@nx/react`
- `@nx/next`
- `@nx/remix`
- `@nx/expo`
- `@nx/react-native`
React apps and libs will be linked using npm/pnpm/yarn/bun workspaces
feature rather than through tsconfig paths. This means that local
aliases like `@/` will work with Next.js and Remix apps.
Note: This will be behind `--workspaces` flag when using `npx
create-nx-workspace` and choosing React stack. If you use the None/TS
stack then adding plugins like `nx add @nx/react` then generating apps,
it will automatically pick up the new TS solution setup.
<!-- 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
React generators are not compatible with TS solution setup (i.e.
workspaces + TS project references).
## Expected Behavior
React generators work with new TS solution setup (Plain, Next.js, Remix,
Expo, React Native).
## Related Issue(s)
#28322
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
Co-authored-by: Nicholas Cunningham <ndcunningham@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 -->
## 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>
Co-authored-by: Nicholas Cunningham <ndcunningham@gmail.com>
This PR updates the default test runner for React/Web apps to be
`vitest`. It aligned better with our emphasis on modern tooling, and the
lack of ESM and proper TS support (using `module` other than `commonjs`)
in Jest makes it hard to use in some workspaces.
<!-- 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 -->
## 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: Nicholas Cunningham <ndcunningham@gmail.com>
The `NxAppWebpackPlugin` does not support relative paths in
`additionalEntryPoints`.
So this will fail:
```js
new NxAppWebpackPlugin({
...
additionalEntryPoints: ['.src/foo.ts']
```
The resolved path is relative to workspace root when it should be
project root.
<!-- 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
Build will fail.
## Expected Behavior
Build should work.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
- fix(vite): preview should dependOn build
- fix(react): playwright should use vite preview
- fix(vue): playwright should use vite preview
- fix(web): playwright should use vite preview
- chore(testing): add e2e test
<!-- 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, `playwright` uses the `vite serve` command when setting up
the web server to run the e2e tests against.
The `vite preview` command/target should also depend on `vite build`.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`playwright` should use the `vite preview` command when setting up the
web server
`vite preview` targets add a `dependsOn["build"]`
Ensure `serve-static` has a dependsOn: ['build']
Cypress should use the `ciBaseUrl` if it exists when running the
`e2e-ci` targets
Migrations for Playwright and Cypress to use serve-static and preview
correctly
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Hello!
I fixing issue related to nx project with enhanced webpack config.
I created this repository to reproduce the bug:
https://github.com/NicolasBelliard/nx-enhance-example
## Current Behavior
When created an Nx repository with nx enhanced config, we faced the
current issue when we try to build the application.
```
> nx run nx-enhance:build
> webpack-cli build --node-env=production
[webpack-cli] TypeError: Cannot read properties of undefined (reading 'nodes')
at calculateProjectDependencies (/home/test/dev/nx-enhance/node_modules/@nx/js/src/utils/buildable-libs-utils.js:24:30)
at calculateProjectBuildableDependencies (/home/test/dev/nx-enhance/node_modules/@nx/js/src/utils/buildable-libs-utils.js:20:12)
at NxTsconfigPathsWebpackPlugin.handleBuildLibsFromSource (/home/test/dev/nx-enhance/node_modules/@nx/webpack/src/plugins/nx-typescript-webpack-plugin/nx-tsconfig-paths-webpack-plugin.js:37:111)
at NxTsconfigPathsWebpackPlugin.apply (/home/test/dev/nx-enhance/node_modules/@nx/webpack/src/plugins/nx-typescript-webpack-plugin/nx-tsconfig-paths-webpack-plugin.js:17:14)
at createCompiler (/home/test/dev/nx-enhance/node_modules/webpack/lib/webpack.js:78:12)
at create (/home/test/dev/nx-enhance/node_modules/webpack/lib/webpack.js:145:16)
at webpack (/home/test/dev/nx-enhance/node_modules/webpack/lib/webpack.js:153:47)
at WebpackCLI.f [as webpack] (/home/test/dev/nx-enhance/node_modules/webpack/lib/index.js:73:16)
at WebpackCLI.createCompiler (/home/test/dev/nx-enhance/node_modules/webpack-cli/lib/webpack-cli.js:1785:29)
at async WebpackCLI.runWebpack (/home/test/dev/nx-enhance/node_modules/webpack-cli/lib/webpack-cli.js:1877:20)
Warning: command "webpack-cli build --node-env=production" exited with non-zero status code
Process finished with exit code 1
```
## Expected Behavior
No error and the build is working.
## Related Issue(s)
https://github.com/nrwl/nx/issues/26303
<!-- 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 `19.4.0-rc.1`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
This repo uses Nx `19.5.0-beta.5`
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
This PR adds a comment when `useLegacyNxPlugin` is used so users know
what it is, and how they can remove it.
<!-- 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 introduces functionality for users who currently use the
`withNx` and `withReact` plugins in their webpack configuration to
migrate to the `NxAppWebpackPlugin`.
The `nxUseLegacyPlugin` wraps the legacy style function so that it
continues to work with the standardized generated webpack config.
By implementing this change, the aim is to provide a consistent method
for users opting to transition to inferred targets. This ensures a
smoother migration process, offering better integration and reducing
potential configuration complexities.
This PR adds `@nx/rollup:convert-to-inferred` generator.
## 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` -->
## 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 adds the ability for incremental builds when using the Webpack
Plugin.
Instead of using the source library directly, you can now utilize the
output folder by utilizing the `buildLibsFromSource` option within your
webpack.config file, through `NxAppWebpackPlugin`. This means that
instead of accessing `mylib/src/index.ts`, it will access
`dist/mylib/index.js`.
This directly aligns with incremental builds as it ensures that the
build process only recompiles the source doe that has been modified
since the last build.
This PR removes deprecated code that's been slated for removal in Nx 19
- mentioned as `TODO(v19)` comments.
## Breaking Changes
- **CNW:** `create-nx-workspace` no longer support `--preset=empty` and
`--preset=core`, use `--preset=apps` and `--preset=npm` respectively.
Deprecated in Nx 15.9.
- **Next.js:** `NX_` environment variables are no longer bundled into
Next.js apps, use `NEXT_PUBLIC` instead. Deprecated in Nx 16.8.
- **Webpack, Storybook, Esbuild:** `NX_` environment variables are no
longer bundled into browser bundles, use `NX_PUBLIC` instead. This
removes the possibility of intentional bundling of `NX_` variables.
Deprecated in Nx 18.
- **Cypress:** `cypressComponentConfiguration` generator removed from
`@nx/cypress`, use `configurationGenerator`instead. Deprecated in Nx
16.8.
- **Cypress:** `cypressProjectGenerator` generator removed from
`@nx/cypress`, use `configurationGenerator` instead. Deprecated in Nx
15.9.
- **Expo:** `withNxWebpack` removed from `@nx/expo`, use [metro
bundler](https://docs.expo.dev/guides/customizing-metro/)
(https://docs.expo.dev/guides/customizing-metro/) in app.json instead.
There is a migration to handle this in Nx 19. Deprecated in Nx 15.8.
## Deferred to v20
- **JS:** `classProperties.loose` option removed from `@nx/js/babel`
preset, use `loose` instead. Deprecated in Nx 17.0.
- **ESLint:** Low priority task to "deviations from
@typescript-eslint/recommended" for our lint rules. @JamesHenry will
look at this later before Nx 20, but it is unimportant.
- **React:** component testing does not work with Project Crystal, and
we need the executor + built-in webpack configs to run CT. Will do a
follow-up on this after Nx 19 release. Related issue:
https://github.com/nrwl/nx/issues/21546
- **Next.js:** `withStylus` removal from `@nx/next`, use SASS instead.
It hasn't worked, but we kept the file to throw an error when used.
Deprecated in Nx 17.0.
- **Next.js**: `@nx/next:component` and `@nx/next:page` generators to
not derive the `components` and `app`/`pages` directory. Use `nx g
@nx/next:component apps/myapp/components/button` instead. Deprecated in
Nx 17.0.
- **Webpack:** `isolatedConfig` option removal from
`@nx/webpack:webpack` executor. There is a migration to handle this in
Nx 19. Deprecated in in Nx 17.2.
- **Angular:** `executeWebpackDevServerBuilder` removal from
`@nx/angular/executors`, use `executeDevServerBuilder` instead.
Deprecated in Nx 17.0.
