typescript-eslint 8.x

Complete instructions

Verified against typescript-eslint@8.70.0 on 2026-09-08. 3 of 3 examples executed.

Those historical examples inspect exports and configuration composition only. The separate ESLint 9/10 fixtures exercise actual typed linting and project service behavior; their execution evidence is tracked separately.

typescript-eslint v8

Use the unified package first

For v8, install the unified package:

npm i -D typescript-eslint@8

The main package exports config, configs, extensions, globs, parser, plugin, and FlatConfig. Its parser and plugin exports provide the TypeScript parser and ESLint plugin surfaces.

The preferred v8 setup is ESLint flat config. The recommended and stylistic presets already configure the TypeScript parser and plugin, so do not manually register them when using those presets.

import js from "@eslint/js";
import { defineConfig } from "eslint/config";
import tseslint from "typescript-eslint";

export default defineConfig({
  files: ["**/*.{js,ts}"],
  extends: [js.configs.recommended, tseslint.configs.recommended],
});

tseslint.config(...) accepts any number of ESLint configuration objects, but it is deprecated. Prefer ESLint core's defineConfig(...) for new flat configurations.

File extensions and globs

Use the exported extension lists instead of duplicating them:

• extensions.ts: ['mts', 'ts', 'cts', 'tsx']
• extensions.js: ['mjs', 'js', 'cjs', 'jsx']
• extensions.jsts: both sets; do not rely on the order of this combined list

import assert from "node:assert/strict";
import tseslint from "typescript-eslint";

assert.deepEqual(tseslint.extensions.ts, ["mts", "ts", "cts", "tsx"]);
assert.deepEqual(tseslint.extensions.js, ["mjs", "js", "cjs", "jsx"]);
assert.deepEqual(
  [...tseslint.extensions.jsts].sort(),
  ["mjs", "js", "cjs", "jsx", "mts", "ts", "cts", "tsx"].sort(),
);

const customGlob = `src/**/*.{${tseslint.extensions.ts.join(",")}}`;
assert.equal(customGlob, "src/**/*.{mts,ts,cts,tsx}");

Main package exports

A plain script can inspect and compose the main package exports without running ESLint:

import assert from "node:assert/strict";
import tseslint from "typescript-eslint";

assert.equal(typeof tseslint.config, "function");
assert.equal(typeof tseslint.parser, "object");
assert.equal(typeof tseslint.plugin, "object");
assert.equal(typeof tseslint.configs.recommended, "object");
assert.ok(tseslint.extensions.ts.includes("ts"));
assert.ok(tseslint.extensions.js.includes("js"));

Do not assume that the parser export has a parse method. The package exposes the parser object, but that particular method is not part of the verified standalone surface.

The config helper is still available for compatibility, but new configuration should use ESLint's defineConfig. When using config, pass ESLint configuration objects rather than legacy string-based extends entries.

import assert from "node:assert/strict";
import tseslint from "typescript-eslint";

const result = tseslint.config({
  files: ["**/*.ts"],
  extends: [tseslint.configs.recommended],
  rules: {
    "@typescript-eslint/array-type": "error",
  },
});

assert.ok(Array.isArray(result));
assert.ok(result.length > 0);

Typed linting

Type-aware rules need TypeScript project/type information. They are not enabled merely by selecting a TypeScript parser. In flat config, use parser options with projectService: true:

import { defineConfig } from "eslint/config";
import tseslint from "typescript-eslint";

export default defineConfig({
  files: ["src/**/*.ts"],
  extends: [tseslint.configs.recommendedTypeChecked],
  languageOptions: {
    parserOptions: {
      projectService: true,
      tsconfigRootDir: import.meta.dirname,
    },
  },
});

The type-checked preset names in v8 are recommendedTypeChecked and stylisticTypeChecked. The hyphenated names recommended-type-checked and stylistic-type-checked are the legacy names commonly shown in older configuration examples.

projectService uses TypeScript's editor-style service and generally replaces manually specifying project paths or creating a separate tsconfig.eslint.json. It is parser configuration consumed by ESLint; it is not a standalone typed-linting switch for an arbitrary script.

Parser utilities

The research describes parser utilities such as createProgram(configFile, projectDirectory?) and withoutProjectParserOptions(options). However, the verified typescript-eslint v8 standalone package export does not expose the tested utility methods through tseslint.parser; do not write code that assumes tseslint.parser.createProgram or tseslint.parser.withoutProjectParserOptions exists.

These APIs are therefore not demonstrated here. Parser configuration and typed project services are primarily consumed while ESLint runs the configuration.

Legacy configuration warning

Older projects may still use the split packages and .eslintrc shape:

module.exports = {
  extends: ["eslint:recommended", "plugin:@typescript-eslint/recommended"],
  parser: "@typescript-eslint/parser",
  plugins: ["@typescript-eslint"],
  root: true,
};

That setup requires separately installed @typescript-eslint/parser and @typescript-eslint/eslint-plugin and is run through ESLint. Do not translate it mechanically into v8 flat config: use the unified typescript-eslint package and its exported presets instead. v8 supports ESLint v9 and flat config; v7 was the first version with flat-config support.

Execute typed linting

Version 8.70.0's peer range supports ESLint 8.57+, 9 and 10, and TypeScript >=4.8.4 <6.1. Earlier 8.x patches can have different supported ranges. Check the installed parser/plugin versions instead of installing a second incompatible copy as a workaround.

Run the project's installed ESLint CLI on a real file inside its tsconfig. projectService uses the editor-style project boundary; files outside it need a separate untyped scope or a deliberately narrow default-project allowance. Keep allowDefaultProject bounded rather than matching all source files.

eslint src/example.ts --max-warnings=0
eslint --print-config src/example.ts

Verify a type-aware rule with a source case that actually needs type information, such as an unhandled promise. Check both the intended failing case and a valid handled case. Parsing or importing the rule preset alone is not a typed-lint verification. Keep compiler diagnostics under the project's own typecheck.

What this skill does not cover

• The detailed contents of every preset or every rule.
• Creating a real TypeScript Program from a filesystem project.
• The standalone @typescript-eslint/project-service API, including createProjectService, its settings, and lifecycle.
• The separate @typescript-eslint/utils package and its exported AST, scope, and utility APIs.
• Parser utility methods not verified on the unified package's standalone parser export.
• Legacy ESLint configuration migration details beyond the v8 versus older configuration shapes described above.

Sources

• Unified package
• Typed linting and project service
• Troubleshooting typed linting
• ESLint flat configuration