## Current Behavior
`nx run lint --quiet --fix` doesn't respect `--quiet` and fixes all
issues, even silenced ones. This is different from how `eslint --quiet
--fix` behaves.
## Expected Behavior
`nx run lint --quiet --fix` should only fix issues that aren't silenced
by `--quiet`, like `eslint` does
## Related Issue(s)
Fixes#31401
ESLint added experimental support for typescript config files since
[9.9.0](https://eslint.org/blog/2024/08/eslint-v9.9.0-released/#experimental-typescript-configuration-files),
and as of
[9.18.0](https://eslint.org/blog/2025/01/eslint-v9.18.0-released/#stable-typescript-configuration-file-support)
that support is stable. This PR add ts/mts/cts to the list of known
eslint config files, and adds the same extensions to config file
generators
## Current Behavior
When using the eslint executor with a ts file, returns error "When using
the new Flat Config with ESLint, all configs must be named
eslint.config.js or eslint.config.cjs and .eslintrc files may not be
used. See
https://eslint.org/docs/latest/use/configure/configuration-files"
When using the eslint plugin, the inferred task is not created for
projects that do not have a non-ts eslint config.
### Workarounds
- Compiling ts rules/configs in a project. Introduces other issues
- Using jiti or comparable
- For plugin users, having a fake eslint.config.js at the root allows
the inferred task to be created. ESLint will still use the ts config.
- Cache targets are wrong
- Complications in non-monorepo workspaces
## Expected Behavior
When using the eslint executor with a ts file, no error is thrown.
When using the eslint plugin with a ts file, the inferred task is
created.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
No issues, but addresses [this
discussion](https://github.com/nrwl/nx/discussions/29710#discussion-7856165)
---------
Co-authored-by: Leosvel Pérez Espinosa <leosvel.perez.espinosa@gmail.com>
## Current Behavior
When running the `lint` task on a project that contains nested projects,
the task runs over all the files, including the ones inside the nested
projects, but the task cache status is not affected by changes to the
files in nested projects. This only happens when the inputs are defined
with `{projectRoot}/...` (what the `@nx/eslint/plugin` infers). The
`{projectRoot}` token scopes the files inside the project without files
in other nested projects. While the `{workspaceRoot}` token would
include every file and wouldn't scope them to any particular project.
## Expected Behavior
The `@nx/eslint/plugin` should infer `lint` tasks with their inputs
using the `{workspaceRoot}` token to support nested projects. This would
be more aligned with what the tool itself does, which runs over all the
files inside the project root regardless of them being inside nested Nx
projects.
Additionally, the difference in behavior between `{workspaceRoot}` and
`{projectRoot}` should be documented.
## Related Issue(s)
Fixes#31264
## Current Behavior
When running `nx g @nx/eslint:convert-to-flat-config` on windows, the
ignores path is not handled correctly. After converting, the path will
have the additional `/r`
## Expected Behavior
When running `nx g @nx/eslint:convert-to-flat-config` on windows, the
ignores path should be correct.
This PR improves the **createNodes** function of eslint's inferred
plugin by making two pragmatic choices:
- reusing the ESLint between config file's runs instead of recreating
the new one every time
- skipping ignored files checks for projects that already have eslint
config file
## Results of benchmarks on customer's repo:
### Without ESLint plugin
- create-project-graph-async - avg. 11739.1326225 -> 11 seconds
### With current ESLint plugin
- create-project-graph-async - avg. 98005.0965135 -> 98 seconds
### With modified ESLint plugin
- create-project-graph-async - avg. 13225.073817 -> 13 seconds
- (@nx/eslint/plugin:createNodes - 2206.96497, 16.69%)
## 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 #
Closes#29252
## Current Behavior
See #29252
## Expected Behavior
See #29252
## Related Issue(s)
See #29252
Fixes #
See #29252
---------
Co-authored-by: Miroslav Jonaš <missing.manual@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 -->
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 #
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 #
Restores a package update group with a `requires` entry to handle
workspaces using `@typescript-eslint/eslint-plugin` and not
`typescript-eslint`.
## Current Behavior
## Expected Behavior
## Related Issue(s)
Fixes #
This PR updates `migrations.json` for `@nx/eslint` and `@nx/angular` so
that `@typescript-eslint/*` and `@angular-eslint/*` packages that are
installed in the workspaces are updated to the same version.
I've updated it for v20 and v19, but if we need to go back further we
could. This will also require patch versions for each major that we want
to fix.
**Note:** Previously there were two entries for `@nx/esilnt@20.4.0` that
handles cases where one of `typescript-eslint` or
`@typescript-eslint/eslint-plugin` are > 8. The packages in both entries
overlap, so I collapsed them down to one entry that checks
`typescript-eslint > 8`.
## Current Behavior
If user has `@typescript-eslint/rule-tester` or
`@angular-eslint/test-utils` installed, our migrations do not update
these versions. This makes them out of sync with
`@typescript-eslint/utils`, etc. which can lead to problems.
## Expected Behavior
Packages in the same `@typescript-eslint/*` and `@angular-eslint/*` are
updated together. If they are not installed, we don't add them to the
workspace.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
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 #
When flat compat is necessary, we don't ensure that `@eslint/eslintrc`
is installed, even though we import it. Depending on the package manager
and hoisting, it may still work, but as we see with pnpm v10, it is not
working without an explicit dependency in `package.json`.
<!-- 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
Some app generators are broken is we use eslint compat.
## Expected Behavior
App generators should work.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#29845
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
When using the TS solution setup and `jest` is used, `ts-jest` is used
as the transformer in most cases (except when the build compiler is
`swc`). The `ts-jest` transformer doesn't support modern module
resolutions like `nodenext` and it doesn't support TS project references
either.
## Expected Behavior
When using the TS solution setup and `jest` is used, `@swc/jest` should
be used as the transformer in cases where previously `ts-jest` was being
used and regardless of using `swc` as the build compiler.
## Related Issue(s)
Fixes #
This pull request includes changes to migrate ESLint configuration files
from CommonJS (`.cjs`) to ECMAScript modules (`.mjs`) as the default.
### ESLint Configuration Generation Changes
The changes also ensure consistent generated eslint configs based on the
base eslint config.
- If the workspace root has an `eslint.config.cjs` or `eslint.config.js`
with `module.exports`. When you create a library or application it will
generate an accompanying config at path
`{projectRoot}/eslint.config.cjs` of the same format.
- If the workspace root has an `eslint.config.mjs` or
`eslint.config.mjs` with `export default`. When you create a library or
application it will generate an accompanying config at path
`{projectRoot}/eslint.config.mjs`.
- If no eslint config is found at the workspace root one will be created
`eslint.config.mjs`
This PR updates our generators to use `eslint.config.cjs` instead of
`eslint.config.js` so that Node resolution will treat it as CommonJS.
This solves an issue where having `"type": "module"` in `package.json`
will result in an error when Node tries to resolve the config file as
ESM.
Also allows us to clean up out Remix generators to not have to rename to
`eslint.config.cjs` to solve the same issue.
<!-- 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 -->
The migration to remove Angular ESLint rules that were removed in v19
does not handle these rules in the root eslint config files.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The migration to remove Angular ESLint rules that were removed in v19
should handle these rules in the root eslint config files.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
Add migration to remove Angular ESLint rules that were removed in v19:
- `@angular-eslint/no-host-metadata-property`
- `@angular-eslint/sort-ngmodule-metadata-arrays`
- `@angular-eslint/prefer-standalone-component`
See Angular ESLint v19 changelog for reference:
https://github.com/angular-eslint/angular-eslint/blob/main/CHANGELOG.md#1900-2024-11-29
<!-- 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 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 -->
`@typescript-eslint/eslint-plugin` and `@typescript-eslint/parser` are
left at old versions after converting to flat config.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
`@typescript-eslint/eslint-plugin` and `@typescript-eslint/parser` are
removed when converting to flat config.
## 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 create fresh angular or react integrated project no eslint
extension out of the box. Few years ago I fill the issue
https://github.com/nrwl/nx/issues/7047 about deprecated tslint extension
looks like that has been deleted but without change to eslint extension
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
when I create angular / react project eslint extension should be added
to recommended vscode extensions
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
closes#28291
<!-- 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 -->
eslint 9 support --quiet param for not run warn rules, but nx not pass
that param directly
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
nx executor should pass --quiet directly to eslint
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#28291
<!-- 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 the workspace has `eslint.config.cjs` at the root, generation of
new lint projects currently does not check for it correctly
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
Ensure utils continue to work as expected when `eslint.config.cjs` is
detected at the workspaceRoot
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes#28214
This PR removes logic where we handle both `@nx/` and `@nrwl/` scope.
The latter scope has stopped being published in v20, and are no longer
relevant.
- Cleans up e2e
- Removes references to `@nrwl/` scope in our generators and executors
- Removes `@nrwl/` from `nx/package.json` `packageGroup`
- Cleans up documentation quality script
This change speeds up Nx Cloud runs by not orchestrating cache hits for
lint tasks.
<!-- 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 #
BREAKING CHANGE
<!-- 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/devkit` supports Nx 17 - 20.
* Node 18 - 22 is supported
* `ExecutorContext.projectGraph`, `ExecutorContext.nxJsonConfiguration`,
and `ExecutorContext.projectsConfigurations` is marked as optional
because `ExecutorContext` in some versions of Nx did not have them.
* `ExecutorContext.workspace` is marked as optional because
`ExecutorContext` in some versions of Nx did not have the above
properties which contain the same information.
* `ProjectGraphNode` is deprecated.
* `NxPluginV1.processProjectGraph` was deprecated long ago and there has
been a warning since.
* `appRootPath` has been deprecated for a long time.
* `parseTargetString` had a variant that did not take either the project
graph or the executor context.
* `readNxJson` has a variant which does not take a tree. This was not
clearly deprecated.
* There are handlers to require from `@nx/` instead of `@nrwl`
* Nx tries to get a root install from `@nrwl/cli`
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
* `@nx/devkit` supports Nx 19 - 21.
* Node 20 - 22 is supported
* `ExecutorContext.projectGraph`, `ExecutorContext.nxJsonConfiguration`,
and `ExecutorContext.projectsConfigurations` is marked as required
because `ExecutorContext` in Nx 19+ is guaranteed to have them.
* `ExecutorContext.workspace` is removed because the same information is
available in the above properties
* `ProjectGraphNode` is removed.
* `NxPluginV1` is no more. All plugins should be `NxPluginV2`.
* `workspaceRoot` is the replacement for `appRootPath`. `appRootPath` is
removed.
* `parseTargetString` no longer has a variant that did not take either
the project graph or the executor context.
* `readNxJson` still has a variant which does not take a tree but it's
clearly deprecated to be removed in Nx 21.
* `@nrwl` packages are no more so we don't have to redirect requires
anymore.
* `@nrwl/cli` is no more so Nx shouldn't try to get a root install there
*
## 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 #
<!-- 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 removes the `@nrwl/*` packages. Also cleans up references to the
legacy packages.
NOTE: The rescope page is now under `/deprecated/rescope`. There is
still >1000K monthly traffic to it, which might be due to older Nx
users.
<!-- 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: Jack Hsu <jack.hsu@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
The DX to migrate to project crystal isn't great right now - people have
to run `convert-to-inferred` generators manually.
## Expected Behavior
We should provide a smoother way to migrate, so we introduced an
`@nx/workspace:infer-targets` generator that can handle multiple
conversions at once, either for the whole workspace or at a project
level.
---------
Co-authored-by: Jack Hsu <jack.hsu@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 -->
There is a race condition in the `@nx/eslint/plugin` causing projects to
be missing lint.
## Expected Behavior
<!-- This is the behavior we should expect with the changes in this PR
-->
The `@nx/eslint/plugin` creates a map of lintable files up front before
analyzing any particular project and there is no race condition.
## Related Issue(s)
<!-- Please link the issue being fixed so it gets closed when this is
merged. -->
Fixes #
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.
