[uPaymeiFixit]

Migrates every @code-style/eslint-config* package, eslint-plugin-nest, and create-configs from ESLint 8 .eslintrc configs to ESLint 10 flat configs. Rule content is unchanged except where the plugin majors forced it.

Context: Paciolan's Maps team wants to standardize on code-style, but it needs a current ESLint first (their spike rejected it over ESLint 8 / eslintrc). Frontend rules come in a follow-up.

Tip: review with whitespace ignored. Wrapping each config in a Linter.Config[] re-indents most files; the rule bodies are otherwise unchanged.

What changes for consumers

// eslint.config.mjs
import { defineConfig } from 'eslint/config';

import { config as base } from '@code-style/eslint-config';
import { config as node } from '@code-style/eslint-config-node';

export default defineConfig(base, node);

• Every package exports a named config array (like jest-configs); layering still works the same way, with later configs winning. -typescript and -jest also export their files, for scoping your own changes to their rules; see docs/customizing-eslint.md.
• Requires ESLint 10 and Node ^20.19.0 || ^22.13.0 || >=24. The packages are ESM-only, which also works for CommonJS projects since config files are loaded via eslint.config.mjs.
• create-configs now writes eslint.config.mjs, installs eslint directly, and drops --ext. When overwriting an old .eslintrc, it carries over the project's own rules, ignore patterns, overrides' rules, and .eslintignore, and warns about anything it can't migrate.
• Migration guide: docs/migrating-v2-to-v3.md.

Notable implementation details

• eslint-plugin-import (no ESLint 10 support) is replaced with eslint-plugin-import-x, registered under the import namespace so every import/* rule ID and disable comment keeps working.
• eslint-plugin-react, eslint-plugin-jsx-a11y, and eslint-plugin-json-files still call rule-context methods ESLint 10 removed; they're wrapped with @eslint/compat's fixupPluginRules. React & jsx-a11y also don't declare ESLint 10 in their peer ranges yet (see the migration guide).
• react-hooks is pinned to rules-of-hooks + exhaustive-deps, since v6+'s recommended adds the React Compiler rules.
• .mjs files are linted as ES modules, so CommonJS projects can lint their own eslint.config.mjs.
• The YAML packages (browser, cli, nest) are now built TS packages like the others.

Fixes to v2 behavior

• Test & lenient relaxations now apply. Base's testing and lenient configs turned off n/* and @typescript-eslint/* rules, but the node and typescript layers come after base and re-enabled them, so they never took effect. Each relaxation now lives in the package that owns the rule.
• no-barreling's suggestion deleted the whole file; it now deletes only the export * declarations.
• create-configs config replacement. Overlapping name checks could race to delete an existing config twice, leaving the project with no config, and with overwrite off an existing config was ignored, so setup wrote a second one next to it.
• Prereleases publish under next. The publish action runs a bare npm publish, so every prerelease took latest; the workflow now sets npm's tag from the version.

Behavior changes forced by the upgrade

• ESLint 10's recommended rules add no-useless-assignment, no-unassigned-vars, preserve-caught-error, and others.
• typescript-eslint 8's strict/stylistic configs rename and add rules (eg: no-throw-literal → only-throw-error). switch-exhaustiveness-check keeps v7's behavior of accepting a default case.
• Plugin majors: eslint-plugin-n 18, eslint-plugin-jest 29, eslint-plugin-promise 7, @next/eslint-plugin-next 16.

Not in this PR

No version bump. With the workflow change, bumping to 3.0.0-N publishes under next, and existing ^2.0.0-35 ranges can't resolve to 3.x.

🤖 Generated with Claude Code

[uPaymeiFixit]

Should 23 be supported?

[uPaymeiFixit]

No. This range is ESLint 10's own engines field. ESLint 10 doesn't support Node 23 (an odd-numbered release that's now end-of-life), and utils depends on ESLint 10 directly, so it couldn't run on 23 anyway.

That said, this question made me look at where else I'd changed engines. I've kept this range only on packages that depend on ESLint 10, and reverted it on the ones that don't (code-style, jest-configs, and the rubocop, stylelint, and typescript configs) in 9c1e95c.

[uPaymeiFixit]

Should this be included in the base config?

[uPaymeiFixit]

I'd keep it out of base. A testing/ folder of test helpers is this repo's convention, and putting it in base would relax rules in any consumer's testing/ folder.

Also, this block isn't redundant with base, though it looks it. Base's testing override comes before the typescript layer, so typescript-eslint's strict configs re-enable the @typescript-eslint/* rules it turns off. Re-applying it here, last, is what makes those relaxations work for utils. v2's .eslintrc.yaml did the same thing for the same reason. The real fix is for eslint-config-typescript to own its test-file relaxations, but that changes what consumers get, so I'd rather do it as a follow-up than fold it into this migration.

I did switch this to defineConfig's extends, which reads like the original eslintrc override (8bbfb05, 6668a91).

[uPaymeiFixit]

Update: I fixed the underlying problem instead of working around it. The testing and lenient relaxations for n/* and @typescript-eslint/* rules now live in eslint-config-node and eslint-config-typescript, so they come after the rules they relax. With that, utils doesn't need this block at all, so it's gone (b711e47).

[uPaymeiFixit]

do we need these to be default exports?

[uPaymeiFixit]

No. Every config module now has a named config export, matching jest-configs:

import { config as base } from '@code-style/eslint-config';

That also let me delete the three import/no-default-export exemptions the default exports needed. The remaining default exports are ones that have to be: the eslint.config.* files themselves, eslint-plugin-nest's plugin object, and type stubs for CJS plugins (8bbfb05).

[uPaymeiFixit]

Maybe we should add a migration script to automate this

[uPaymeiFixit]

Agreed. create-configs already does most of it: re-running it with overwrite writes eslint.config.mjs and removes the old .eslintrc* and .eslintignore. The gap is rules you've added to your own .eslintrc.yaml, which it drops. I'd rather teach create-configs to carry those over than add a separate script, but I'll do that in a follow-up so this PR stays focused. I've also cut this doc down to just the steps (8bbfb05).

[uPaymeiFixit]

Update: done in create-configs instead of a separate script. When overwrite replaces an old .eslintrc, it now carries over the project's rules, ignore patterns, overrides' rules, and .eslintignore into eslint.config.mjs, and warns about anything it can't migrate (eg: env) (d1a1df0).

[uPaymeiFixit]

This looks sus. Why did we drop config-types.ts from the command? I get that we need to override the tsconfig for typescript-json-schema

[uPaymeiFixit]

Good catch, it was a workaround. The command only broke because I'd regenerated the whole lockfile, which changed which version of @types/glob got hoisted. With the lockfile now rebuilt incrementally from main's (e434c1a), the original command works again, so I've restored it and deleted tsconfig.jsonschema.json (9c1e95c).

[uPaymeiFixit]

out of scope. look for more changes that are OOS

[uPaymeiFixit]

Reverted. Looking for others turned up these, which I've also reverted:

• the .nvmrc bump, the CI test matrix, and the e2e smoke test script
• engines bumps on packages that don't depend on ESLint
• a ts-jest pin in the published jest-configs, which would've downgraded its consumers
• the build:jsonschema workaround
• a behavior change to eslint-plugin-nest's no-barreling (its suggestion deletes the whole file instead of just the export; that's a real bug, but it belongs in its own PR)

Several of these traced back to regenerating the lockfile from scratch, which upgraded every transitive dependency. It's now rebuilt incrementally from main's (e434c1a, 9c1e95c, 8bbfb05).