typescript-eslint

typescript-eslint is the umbrella npm package published by the typescript-eslint monorepo that lets ESLint understand and lint TypeScript code. Rather than installing the parser, plugin, and rule-preset packages separately, this single dependency re-exports @typescript-eslint/parser, @typescript-eslint/eslint-plugin, and every published flat-config preset (recommended, strict, stylistic, and their type-checked variants) behind one namespace, so a project’s eslint.config.mjs only needs one import to get full TypeScript support.

Its most-used export is the config() helper, a small utility that flattens arrays of ESLint flat-config objects and adds an extends convenience field so configs can compose the way classic .eslintrc extends used to, while staying compatible with ESLint 9’s flat config format. The package also exposes parser and plugin directly (identical objects to their individually-published counterparts, guaranteeing referential equality for third-party configs) plus small platform-detection helpers like getTSConfigRootDirFromStack that make multi-tsconfig monorepos resolve correctly without extra configuration.

What You Get

• A typed config() helper for composing ESLint flat configs with an extends shorthand
• Direct re-exports of @typescript-eslint/parser and @typescript-eslint/eslint-plugin guaranteed to be the same objects consumed elsewhere in a project
• Every published rule-preset getter (recommended, strict, stylistic, and their -type-checked variants) as lazily-evaluated properties
• Automatic TSConfig root-dir detection via stack introspection, so type-aware linting works out of the box in monorepos
• Ready-made file-extension and glob constants (extensions, globs) for targeting JS/TS files in config overrides

Common Use Cases

• Bootstrapping a new TypeScript project’s eslint.config.mjs with one import instead of four separate packages
• Composing custom flat configs that mix js.configs.recommended, tseslint.configs.recommended, and project-specific rule overrides via extends
• Migrating a legacy .eslintrc-based TypeScript project to ESLint 9’s flat config format
• Sharing one canonical parser/plugin reference across a monorepo’s multiple ESLint configs to avoid duplicate-instance errors

Under The Hood

Architecture This package sits as a thin orchestration layer over the monorepo’s other packages (@typescript-eslint/eslint-plugin, @typescript-eslint/parser, @typescript-eslint/typescript-estree, @typescript-eslint/utils). src/index.ts is the sole entry point: it re-exports parser and plugin directly from the underlying packages (preserving referential equality so multi-config projects don’t get “duplicate plugin instance” errors), and builds a configs object via createConfigsGetters, which lazily wraps each of the plugin’s pre-built flatConfigs (recommended/strict/stylistic and their type-checked variants) behind a getter that also registers the caller’s tsconfig root dir on first access (getTSConfigRootDirFromStack.ts walks the call stack to infer this). config-helper.ts implements the config()/extends composition algorithm as a pure function with no side effects beyond validation-time throws, keeping the “resolve extends into a flat array” logic isolated from the rest of the module. There’s no runtime state beyond a module-level TS-major-version guard at the top of index.ts; if the flat-config shape from @typescript-eslint/utils changed, config-helper.ts and index.ts’s casts would need updating in lockstep, but the blast radius stays contained to this one package since it performs no analysis itself.

Tech Stack Written in TypeScript and published as CommonJS (type: “commonjs”, an exports map pointing at dist/index.js/dist/index.d.ts), built via Nx (nx build) as part of the larger pnpm/Nx monorepo, and tested with Vitest (tests/.test.ts using vi.mock to stub sibling modules). It depends on sibling workspace packages (@typescript-eslint/eslint-plugin, @typescript-eslint/parser, @typescript-eslint/typescript-estree, @typescript-eslint/utils, all workspace:) and declares eslint ^8.57.0 || ^9.0.0 || ^10.0.0 plus typescript >=4.8.4 <6.1.0 as peer dependencies. Build tooling includes rimraf for cleaning and @arethetypeswrong/cli (the attw-check target) to verify the published package’s type/module resolution correctness across consumer setups, on top of the shared root tsconfig.base.json/tsconfig.build.json.

Code Quality Tests live in tests/*.test.ts using Vitest, mocking @typescript-eslint/typescript-estree’s addCandidateTSConfigRootDir and the internal getTSConfigRootDirFromStack module, and iterate over real rule metadata from @typescript-eslint/eslint-plugin to assert every exported config’s rule list stays in sync with the plugin (configs.test.ts) — behavior-level testing rather than superficial snapshotting. Error handling in config-helper.ts is explicit and typed: configImpl throws descriptive Error/TypeError messages naming the offending config index and name for malformed extends usage (string entries, non-array extends, nested extends, basePath inside extends) instead of silently swallowing bad input. Naming is consistent and the codebase is fully typed under strict TS, with unavoidable casts paired with comments justifying them. Linting/formatting is enforced repo-wide via the root eslint.config.mjs (the project dogfoods its own rules) and Prettier, with CI running via GitHub Actions.

API Design The package’s central ergonomic contribution is the config()/extends helper, which lets consumers compose flat configs almost exactly like classic .eslintrc’s extends array (a familiar mental model) even though ESLint’s flat config has no native equivalent — though ESLint’s own defineConfig() now covers similar ground, which the JSDoc explicitly acknowledges by marking config() @deprecated in favor of it, a rare case of a library being transparent about being superseded by the platform it wraps. Onboarding requires exactly one import (import tseslint from ‘typescript-eslint’) to get parser, plugin, and every named preset, versus wiring three separate packages by hand. Every exported preset and helper carries a JSDoc block with a runnable example and a link to the corresponding docs page, and the extensions/globs constants remove a common source of copy-pasted glob-pattern bugs. Not novel technology, but a deliberate, well-executed developer-experience layer over an otherwise fragmented multi-package setup.