ESLint: Parsing error on a valid file

Fix ESLint parsing errors by aligning the parser and parserOptions, adding TypeScript or JSX plugins, and matching the language version.

beginnerdebuggingeslinttoolingtypescript

Symptoms

Parsing error: Unexpected token <
ESLint fails on JSX or TypeScript syntax
The error appears after adding a new file type to the project

Possible causes

The default parser cannot handle TypeScript or JSX
parserOptions.ecmaVersion or sourceType is too low
The file is not matched by the configured overrides
A flat config uses the wrong languageOptions

Diagnosis steps

Read the token ESLint could not parse

Interpretation

A < token points at JSX; a type annotation points at TypeScript.

Check the parser and parserOptions for the file type

Interpretation

TS and JSX need @typescript-eslint/parser or a configured babel parser.

Confirm the config applies to this file

npx eslint --print-config path/to/file

Interpretation

The printed config shows which parser and options actually apply.

Root cause

ESLint does not parse languages it is not configured for. The default parser understands only JavaScript of the configured ecmaVersion; JSX requires a parser option and TypeScript requires a dedicated parser. Config overrides that do not match the file leave it on the default parser, producing a parsing error on otherwise valid code.

Fix

Configure the parser and parserOptions for the languages in the project, use typescript-eslint for TypeScript, and enable jsx when React is used. In flat config, set languageOptions.parser and ecmaVersion appropriately, and ensure file globs cover the new extensions.

Verify the fix

Run eslint on the previously failing file; it parses without error and reports lint messages rather than a parsing error, confirming the parser and options match the file type.

Symptoms

Parsing error: Unexpected token appears on a file that compiles and runs. It often starts right after a file with JSX or TypeScript syntax is added to the lint scope.

Diagnosis

Note the token and print the effective config:

npx eslint --print-config src/Component.tsx

If the parser is the default espree for a .tsx file, that is the mismatch.

Fix

Configure the right parser and options:

// flat config
import tseslint from 'typescript-eslint';

export default [
  {
    files: ['**/*.ts', '**/*.tsx'],
    languageOptions: {
      parser: tseslint.parser,
      parserOptions: { ecmaVersion: 2022, sourceType: 'module', ecmaFeatures: { jsx: true } },
    },
  },
];

Verification

Run eslint on the file; it now reports lint findings (or none) instead of a parsing error, proving the parser understands the syntax.

Additional Notes

Parsing errors are distinct from lint findings, so a rule change rarely fixes them; the parser simply does not understand the file. Confirm which extensions the config globs cover, because a new tsx or vue file added outside the matched set silently falls back to the default parser. In flat config the parser lives under language options while legacy config uses parser and parser options, and mixing the two shapes leaves files unparsed. Printing the effective config for the failing path shows exactly which parser and options apply.