@rushstack/eslint-patch

@rushstack/eslint-patch is a small runtime patch, maintained inside Microsoft’s Rush Stack monorepo, that is loaded as the first line of an ESLint config file and modifies the ESLint engine in memory. Rather than forking ESLint or waiting on upstream feature requests, it monkey-patches the module resolver and config array factory so that large-scale monorepos can share lint configuration without copy-pasting plugin dependencies into every project’s package.json.

The package bundles three independently loadable features: modern-module-resolution, which lets a shareable ESLint config carry its own plugin dependencies; custom-config-package-names, which removes ESLint’s requirement that shareable configs be named with an eslint-config- prefix (useful for Rush Stack “rig” packages that bundle many tool configs together); and eslint-bulk-suppressions, which lets teams roll out new lint rules across thousands of files by recording legacy violations in a separate .eslint-bulk-suppressions.json file instead of littering source with eslint-disable comments.

Because it operates by detecting which ESLint version and internal file layout is currently loaded (spanning ESLint 6 through 9, including the newer flat-config format), the patch keeps working as ESLint’s internals evolve, and is designed to be forward-compatible until the equivalent functionality lands in ESLint itself.

What You Get

• modern-module-resolution patch - lets a shareable ESLint config bring its own plugin dependencies instead of forcing every consuming project to install and pin the same devDependencies.
• custom-config-package-names patch - removes ESLint’s requirement that shareable config packages include eslint-config- in their name, enabling Rush Stack rig packages to bundle lint config alongside other tooling.
• eslint-bulk-suppressions feature - generates and manages a .eslint-bulk-suppressions.json file so new lint rules can be enabled across a large codebase without hand-editing thousands of files.
• eslint-bulk CLI companion - a globally installable eslint-bulk command (via the separate @rushstack/eslint-bulk package) that drives suppress and prune operations against whichever project-local patch version is installed.
• Broad ESLint version support - a single patch codebase that detects and adapts to ESLint 6.x through 9.x, including both the legacy eslintrc format and the newer flat-config format.

Common Use Cases

• Monorepo lint config sharing - a platform team publishes one internal @company/eslint-config package and uses modern-module-resolution so every project in the monorepo can extend it without redeclaring plugin dependencies.
• Rolling out stricter lint rules - a team enabling a new, noisy ESLint rule across an existing large codebase runs eslint-bulk suppress —all to record current violations, then fixes them incrementally over time.
• Rig-based shared tooling packages - a Rush Stack rig package (e.g. a *-rig package that bundles TypeScript, Jest, and ESLint config together) uses custom-config-package-names so its shared config doesn’t need an eslint-config- prefix.
• Editor and CI parity - teams load the patch in .eslintrc.js so that VS Code/WebStorm ESLint extensions and CI lint runs resolve shared plugins identically, without needing a custom-built ESLint.

Under The Hood

Architecture The patch is organized around a shared detection module, _patch-base.ts, which walks the Node.js require() call stack at load time to locate the running ESLint installation and its internal @eslint/eslintrc package, probing through four different historical ESLint internal layouts (flat config in 9.x, the eslintrc.cjs bundle in 8.x, config-array-factory.js in 7.12+, and the pre-7.12 cli-engine layout) until it finds a match, then exports the resolved ModuleResolver, Naming, and ConfigArrayFactory internals for the other patch modules to monkey-patch. modern-module-resolution.ts and custom-config-package-names.ts each wrap a small number of these internal functions to change resolution/naming behavior, while the eslint-bulk-suppressions subsystem is a larger, self-contained module (ast-guards.ts, bulk-suppressions-file.ts, bulk-suppressions-patch.ts, generate-patched-file.ts) that intercepts ESLint’s rule-reporting path, computes a stable “scope ID” for each AST node via typed guard functions, and reads/writes suppression records to a JSON file per eslintrc folder, with a small CLI (cli/suppress.ts, cli/prune.ts, cli/start.ts) layered on top.

Tech Stack Written entirely in TypeScript targeting Node.js >=20, built with Microsoft’s own Heft build orchestrator and versioned/published via the Rush monorepo tooling; the package emits both CommonJS and ESM output (lib-commonjs and lib-esm) plus generated .d.ts type declarations, and depends only on @typescript-eslint/types for AST typing plus dev-time pairs of eslint-8/eslint-9 aliases to test compatibility across major ESLint versions side by side.

Code Quality The package itself ships no dedicated unit test suite in its own folder — correctness for the runtime-patching logic is instead validated indirectly through the wider Rush Stack monorepo’s own use of the patch in its shared ESLint configs and through the parallel eslint-8/eslint-9 devDependency aliases used during development. Code is consistently typed (no implicit any beyond a couple of explicitly justified eslint-disable comments), uses descriptive interface and function names, follows a flat-config ESLint + Prettier setup enforced by CI, and is validated through Rush’s own bulk-suppressions feature dogfooding itself in the same repo.

What Makes It Unique Rather than forking or wrapping ESLint, the package patches the running ESLint process in memory by reverse-engineering its internal module layout across many historical versions, which lets existing tooling (editor extensions, CI runners, any tool that loads ESLint as a library) keep working unmodified. The bulk-suppressions design is a distinctive answer to the “legacy violations block new rules” problem: instead of injecting per-line suppression comments that erode over time, it isolates suppressions in one reviewable, CODEOWNERS-protectable JSON file with a scope-ID scheme designed to stay stable across unrelated code edits.