Call `assertSupportedEslintVersion(tree)` as the first statement of
every working function backing a `generators.json` entry — `initEsLint`,
`lintWorkspaceRulesProjectGenerator`, `lintWorkspaceRuleGenerator`,
`convertToFlatConfigGenerator`, and `convertToInferred`. Workspaces
declaring `eslint` below the supported floor (`8.0.0`) now fail fast
with the canonical `Unsupported version of` error before any tree
mutations, instead of silently writing configs incompatible with the
installed ESLint major.

The `lintInitGenerator` wrapper does not assert itself — it delegates
to `initEsLint`, which carries the assert (canonical
wrapper/internal-split pattern).

…enerators

Flip the default of `keepExistingVersions` to `true` on
`@nx/eslint:init`'s schema, and pass `true` (or
`keepExistingVersions ?? true` where the option is propagated from a
caller) to every generator-side `addDependenciesToPackageJson` call —
`setup-root-eslint` legacy and flat-config paths, the
`convert-to-flat-config` post-conversion dependency block,
`workspace-rule`, `workspace-rules-project`, and `init-migration`'s
`@eslint/js` and `@nx/eslint-plugin` writes.

Generators that previously overwrote installed ESLint, typescript-eslint,
and related dependency pins on re-run now leave user-pinned versions
intact. Bumping remains the responsibility of migrations, which are
explicitly exempt and not modified.

…SLint 8

Replace the ad-hoc `Number(version[0]) < 7 || ...` floor check and
inlined `ESLint must be version 7.6 or higher.` throw in
`packages/eslint/src/executors/lint/lint.impl.ts` with the shared
`assertSupportedInstalledPackageVersion('eslint', minSupportedEslintVersion)`
helper from `@nx/devkit/internal`. The floor moves from the stale
`7.6` to `8.0.0` (matching the declared `eslint` peer range), and the
thrown message now matches the canonical
`Unsupported version of \`eslint\` detected` format used across plugin
floor asserts.

Update the executor spec to mock `readModulePackageJson` (the FS read
backing `getInstalledPackageVersion`) for the sub-floor case via
`mockReturnValueOnce`, so the mock applies only to the targeted test
and other tests run against the actual installed `eslint`.

Add `requires` blocks to two migration generators in
`packages/eslint/migrations.json` so they only run on workspaces where
their target package is actually present at a relevant version:

* `update-typescript-eslint-v8.13.0` is now gated on
  `@typescript-eslint/parser: >=8.0.0`. Workspaces below v8 are skipped
  by the migrate runner instead of running the migration body and
  silently no-opping. The migration body keeps its per-package
  `gte('8.0.0') && lt('8.13.0')` guard, which covers the
  lockstep-broken case where one of the four typescript-eslint packages
  drifts to a different major than the parser; a comment in the
  migration documents the split.
* `add-file-extensions-to-overrides` is now gated on
  `eslint: >=8.57.0`. Workspaces without ESLint (or below the
  flat-config-compat baseline) no longer run the migration body.

Both gates are intentionally open at the upper bound — migration
generators should remain runnable via `nx migrate --from <older>` even
once newer Nx versions ship.

The `eslint-config-prettier` cross-major bump in `packageJsonUpdates`
`20.7.0` is left ungated: v10's `eslint >=7.0.0` peer covers the entire
supported ESLint window, `@nx/eslint-plugin` itself peers
`eslint-config-prettier: ^10.0.0` via the catalog, and there are no
codemods between v8/v9/v10 — the bump is corrective for sub-v10
workspaces, not a footgun.

…s enforce the floor

Add `packages/eslint/src/utils/all-generators-enforce-floor.spec.ts`
using the shared `assertGeneratorsEnforceVersionFloor` from
`@nx/devkit/internal-testing-utils`. The spec iterates every entry in
`@nx/eslint`'s `generators.json` and verifies it throws the canonical
`Unsupported version of` error on a sub-floor (`~7.32.0`) workspace.

This pins the floor-assert behavior at the suite level, so a future
generator added to `generators.json` without an assert in its working
function fails this spec — matching the canonical shape now used by
`@nx/cypress`, `@nx/playwright`, `@nx/angular`, `@nx/js`, and
`@nx/rsbuild`.

… to ^8

Restrict the `@typescript-eslint/parser` peer in
`packages/eslint-plugin/package.json` from
`^6.13.2 || ^7.0.0 || ^8.0.0` to `^8.0.0` so the declared peer matches
the plugin's actually-bundled runtime dependencies. The plugin ships
`@typescript-eslint/utils` and `@typescript-eslint/type-utils` pinned
to `^8.0.0` via the `catalog:eslint` entry, and workspaces previously
on `@typescript-eslint/parser@^6` or `^7` silently ran the plugin's
rules against v8 internals — risking AST-shape drift on rules that
walk TSESTree nodes.

The plugin does not directly invoke `@typescript-eslint/parser` (only
the user's ESLint config does, when configured to parse TypeScript
files), so the peer is declared as optional via
`peerDependenciesMeta`. Users who only lint JavaScript no longer see
an unmet-peer warning. This matches the canonical optional-peer
pattern used by `@playwright/test`, `cypress`, `vitest`, etc.

`@typescript-eslint/utils` and `@typescript-eslint/type-utils` remain
in `dependencies` — the plugin self-contains its runtime utils rather
than peering on the user's installation.

… to ^8

Restrict the `@typescript-eslint/parser` peer in
`packages/eslint-plugin/package.json` from
`^6.13.2 || ^7.0.0 || ^8.0.0` to `^8.0.0` so the declared peer matches
the plugin's actually-bundled runtime dependencies. The plugin ships
`@typescript-eslint/utils` and `@typescript-eslint/type-utils` pinned
to `^8.0.0` via the `catalog:eslint` entry, and workspaces previously
on `@typescript-eslint/parser@^6` or `^7` silently ran the plugin's
rules against v8 internals — risking AST-shape drift on rules that
walk TSESTree nodes.

The plugin does not directly invoke `@typescript-eslint/parser` (only
the user's ESLint config does, when configured to parse TypeScript
files), so the peer is declared as optional via
`peerDependenciesMeta`. Users who only lint JavaScript no longer see
an unmet-peer warning. This matches the canonical optional-peer
pattern used by `@playwright/test`, `cypress`, `vitest`, etc.

`@typescript-eslint/utils` and `@typescript-eslint/type-utils` remain
in `dependencies` — the plugin self-contains its runtime utils rather
than peering on the user's installation.

Honor the user's flat-config preference when picking the fresh-install
lane in `packages/eslint/src/utils/versions.ts`. When `useFlatConfig`
returns `false` (typically via `ESLINT_USE_FLAT_CONFIG=false`), install
the v8 ESLint + typescript-eslint v7 lane so the workspace remains
internally consistent: ESLint v9 with eslintrc is supported for runtime
linting, but `@typescript-eslint/rule-tester` v8 dropped eslintrc
support entirely and v7 rule-tester is pinned to ESLint v8 — so legacy
workspaces with a v9 + typescript-eslint v8 stack break the
`workspace-rule` generator's emitted spec.

`convert-to-flat-config` is an opt-in upgrade: after conversion the
workspace is on the v9 flat-config-ready stack, so the generator now
writes the latest `eslintVersion` / `typescriptESLintVersion`
constants directly rather than routing through `versions(tree)` (which
would pick the v8/v7 lane based on pre-conversion eslintrc state) and
drops the `keepExistingVersions` flag (this generator is meant to bump
existing pre-conversion pins).

The `@nx/vue` library snapshot is updated to reflect the v9 flat-config
defaults the vue library generator now produces.

…versions(tree) directly

`packages/eslint/src/utils/version-utils.ts` was a two-function file
whose entries (`getInstalledEslintVersion`, `getTypeScriptEslintVersionToInstall`)
were one-line indirections over what `versions.ts` already exposes. Drop
the file and route every consumer through `versions(tree)` directly:

* `packages/eslint/internal.ts` re-exports `getInstalledEslintVersion`,
  `typescriptESLintVersion`, and now also `versions` directly from
  `./src/utils/versions`.
* `packages/eslint/src/generators/workspace-rules-project/workspace-rules-project.ts`
  reads `versions(tree).typescriptESLintVersion` inline.
* `packages/vue/src/utils/add-linting.ts` swaps to the same call shape.

`packages/vue/src/generators/library/library.spec.ts` adds a per-test
`ESLINT_USE_FLAT_CONFIG=true` override for the "should add vue and vitest
to package.json when non-buildable" case. Jest's pnpm hoisting can
resolve `require('eslint')` to a v8 copy in the workspace store, which
would otherwise make `useFlatConfig` route the fresh-install lane
through the v8/v7 stack and not match the v9 flat-config snapshot. The
snapshot is refreshed to capture what real flat-config users actually
see (`@eslint/js`, `typescript-eslint` umbrella package, no
`@typescript-eslint/eslint-plugin`).

No production behavior change.

The legacy install lane (no flat config) paired ESLint v8 with
typescript-eslint v7, which pins `@typescript-eslint/parser` to v7.
With `@nx/eslint-plugin`'s parser peer tightened to `^8.0.0`,
`npm install` fails with ERESOLVE in fresh workspaces that pull in
`@nx/eslint-plugin` (e.g. `nx g @nx/remix:app --linter=eslint`).

typescript-eslint v8 supports ESLint v8.57+ and still works with
eslintrc, so the v8 lane can ship typescript-eslint v8. The only
sub-package that dropped eslintrc is `@typescript-eslint/rule-tester`,
which `@nx/eslint` only installs in the flat-config lane.