## Current Behavior
Vue and Nuxt projects using ESLint with flat config generate projects
using the `@typescript-eslint/parser` but don't install the package.
This can result in an error if the package has not been installed
before.
## Expected Behavior
Vue and Nuxt project generators should install the
`@typescript-eslint/parser` if they generate ESLint configuration that
uses it.
## Related Issue(s)
Fixes #
## Current Behavior
After the migration to Vite 6 - The `@vitejs/plugin-vue` was not updated
to v5.
This has led to an incorrect peer dependency.
## Expected Behavior
Upgrade `@vitejs/plugin-vue` to version 5 to remove peer dependency
issues
## Related Issue(s)
Fixes#30326
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.
## Current Behavior
The Rsbuild plugin is exported at `@nx/rsbuild/plugin`
## Expected Behavior
Export the plugin from `@nx/rsbuild` i.e. the root of the package.
<!-- 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: Leosvel Pérez Espinosa <leosvel.perez.espinosa@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>
We should be consistent about how options are defined in our plugins.
Currently, there are some options that use `enum`s and some that use
typed strings. I think typed strings are preferable because someone
extending a generator only needs to import the main generator that
they're extending, not all the transitive dependencies of that
generator.
Current extending code:
```
// ...
import { applicationGenerator as reactApplicationGenerator } from '@nx/react';
import { Linter } from '@nx/eslint';
export async function applicationGenerator(
tree: Tree,
options: ApplicationGeneratorSchema
) {
reactApplicationGenerator(tree, {
...options,
linter: Linter.EsLint,
});
}
```
Desired extending code:
```
// ...
import { applicationGenerator as reactApplicationGenerator } from '@nx/react';
export async function applicationGenerator(
tree: Tree,
options: ApplicationGeneratorSchema
) {
reactApplicationGenerator(tree, {
...options,
linter: 'eslint',
});
}
```
The problem is not just an extra line of code, the person extending the
`reactApplicationGenerator` has to dig into the implementation details
of the generator itself in order to know where to find the `Linter`
enum. The `e2eTestRunner` is already a typed string and is easily
extended.
The solution I'm proposing in this PR would define a typed string in the
same file as the existing enum. None of the implementations need to
change. No community plugin code will be broken.
<!-- 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 -->
Building a newly created Nuxt workspace/application fails with:
```bash
Nuxt Build Error: Cannot find module '@volar/typescript/lib/node/proxyCreateProgram'
```
This can be seen in current CI runs like the following:
https://staging.nx.app/runs/bszKddEenc/task/e2e-nuxt%3Ae2e-ci--src%2Fnuxt.test.ts.
This is happening because the `vite-plugin-checker` (used by Nuxt)
requires `vue-tsc@>=2.0.0`, but the `@nx/vue` plugin installs
`vue-tsc@^1.8.8`.
```bash
└─┬ nuxt 3.12.3
└─┬ @nuxt/vite-builder 3.12.3
└─┬ vite-plugin-checker 0.7.1
└── ✕ unmet peer vue-tsc@>=2.0.0: found 1.8.27
```
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Newly created Nuxt workspaces/applications should build successfully.
## 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#21739
