TL;DR
If you're seeing Parsing error: DeprecationError: 'originalKeywordKind' has been deprecated since v5.0.0 and can no longer be used, the cause is a version mismatch between your TypeScript 5.x installation and outdated @typescript-eslint packages still on v5.x. Fix it by upgrading both @typescript-eslint/eslint-plugin and @typescript-eslint/parser to v6.x or later.
If that doesn't work, scroll to verify the fix — there are two common variants this guide also covers.
-
Symptom: Every
.tsxfile shows the parsing error at line 0, even in files with no code. -
Root cause:
@typescript-eslint/parserv5.x calls the removedoriginalKeywordKindAPI from TypeScript 5.x. -
Fix: Upgrade
@typescript-eslint/eslint-pluginand@typescript-eslint/parserto^6(or latest). -
Verification: Run
npx eslint .— the error disappears, and linting works normally.
What you'll see
The error appears at line 0 of every .tsx file in your React project, even if the file is empty. The exact output ESLint prints is:
Parsing error: DeprecationError: 'originalKeywordKind' has been deprecated since v5.0.0 and can no longer be used. Use 'identifierToKeywordKind(identifier)' instead.
It happens when you run ESLint (via CLI, your editor, or a pre-commit hook) after upgrading TypeScript to v5.x but leaving the @typescript-eslint toolchain on v5.x. The behavior is the same across local development, CI pipelines, and VSCode — any environment where ESLint parses TypeScript files.
This exact symptom was reported on Stack Overflow, confirming it's a widespread upgrade pain point. The original question shows the error hits React projects that recently bumped TypeScript.
Root cause: @typescript-eslint v5.x calls a removed TypeScript API
TypeScript 5.0 deprecated the internal originalKeywordKind utility and replaced it with identifierToKeywordKind(identifier). The old function was not removed outright; in TypeScript 5.x it still exists but throws a DeprecationError when called. The @typescript-eslint/parser package (which ESLint uses to understand TypeScript syntax) still referenced originalKeywordKind in its v5.x versions. When ESLint hands a .tsx file to the parser, the parser tries to call that function, TypeScript throws a DeprecationError, and ESLint surfaces it as a parsing error at line 0 — before any of your code is even examined.
The version chain that triggers this:
-
typescript≥ 5.0 (the old function throwsDeprecationErrorwhen called) -
@typescript-eslint/parser≤ 5.x (still calls the deprecated function) -
@typescript-eslint/eslint-plugin≤ 5.x (pulls in the parser)
You can verify the mismatch by checking your package.json. A broken setup often looks like this:
{
"devDependencies": {
"typescript": "^5.0",
"@typescript-eslint/eslint-plugin": "^5.0",
"@typescript-eslint/parser": "^5.0"
}
}
The parser v5.x still calls originalKeywordKind, but TypeScript 5.x throws a DeprecationError when that function is called. Since the parser uses the project's installed TypeScript instance, the call fails with a DeprecationError.
The fix: Upgrade @typescript-eslint packages to v6.x
The accepted answer on Stack Overflow and multiple follow-up answers all point to the same solution: bump both @typescript-eslint packages to v6.x. Version 6.x of the parser and plugin were rewritten to use the new identifierToKeywordKind API, making them compatible with TypeScript 5.x.
Run this in your project root:
npm install --save-dev @typescript-eslint/eslint-plugin@^6 @typescript-eslint/parser@^6
If you use Yarn:
yarn add --dev @typescript-eslint/eslint-plugin@^6 @typescript-eslint/parser@^6
After the install, your package.json devDependencies should reflect the upgrade:
{
"devDependencies": {
"typescript": "^5.0",
"@typescript-eslint/eslint-plugin": "^6",
"@typescript-eslint/parser": "^6"
}
}
That single change addresses the cause because v6.x of the parser no longer references the deprecated originalKeywordKind — it uses the replacement API that TypeScript 5.x provides.
Step by step
- Open your terminal in the project root.
- Run the
npm installcommand above (or the Yarn equivalent). - If you're using VSCode, restart the ESLint server: press
Ctrl+Shift+P(orCmd+Shift+Pon macOS), typeRestart ESLint Server, and select it. This clears any cached parser instance that might still hold the old version. - If you're running ESLint from the command line, no restart is needed — the next run picks up the updated packages.
Verify the fix
Run ESLint on your project:
npx eslint .
You should see normal lint output — no DeprecationError at line 0. If you previously had zero lint errors, the command should exit cleanly. If you had other lint issues, they'll appear as usual, but the parsing error will be gone.
If you're still seeing the error, two common variants exist:
Variant A — Only one package was upgraded
The parser and plugin must both be on v6.x. If you upgraded only @typescript-eslint/parser but left the plugin on v5.x, the plugin and parser share internal packages that must be at the same major version; upgrading only one leaves a version mismatch in those shared dependencies, which can cause the same error. Check your lockfile (package-lock.json or yarn.lock) to confirm both are resolved to v6.x. Run npm ls @typescript-eslint/parser to see the resolved version.
Variant B — ESLint server cache in VSCode
Even after upgrading, VSCode's ESLint extension can hold a reference to the old parser in memory. Restart the ESLint server as described in step 3. If that doesn't work, reload the VSCode window (Ctrl+Shift+P → Developer: Reload Window). This forces a fresh load of all extensions and clears any stale module cache.
Why this happens (and how to avoid it next time)
The underlying invariant is that @typescript-eslint packages are tightly coupled to the TypeScript compiler API. When TypeScript removes or renames an internal function, the parser must be updated to match. The originalKeywordKind deprecation was announced in TypeScript 5.0, but many projects didn't notice until they upgraded TypeScript while keeping ESLint tooling pinned to v5.x.
To prevent this regression, pin your @typescript-eslint packages to a version range that matches your TypeScript major version. The @typescript-eslint team maintains a compatibility table: v6.x supports TypeScript ≥4.7 and fully supports 5.x. Add a engines or a peer-dependency check in your CI to alert you when the versions drift. For example, you can add a lint script that checks the installed parser version:
npm ls @typescript-eslint/parser
If the output shows a v5.x version, the build should fail.
FAQ
What causes the 'originalKeywordKind' DeprecationError in ESLint?
It's caused by a version mismatch: your project uses TypeScript 5.x but @typescript-eslint/parser and @typescript-eslint/eslint-plugin are still on v5.x, which references the removed originalKeywordKind API. Upgrading both packages to v6.x or later resolves it.
Can I fix the 'originalKeywordKind' error without upgrading packages?
No. The error is caused by the version mismatch and will persist until the packages are upgraded. Restarting the ESLint server or reloading the editor will not resolve it. The only permanent fix is upgrading @typescript-eslint packages to v6.x.
Does this error affect plain .ts files too?
Yes. The error appears on any TypeScript file (.ts, .tsx, .mts, .cts) that ESLint parses. The parser doesn't distinguish between JSX and non-JSX files when calling the deprecated API — it fails at the parsing stage before JSX-specific logic runs.
I'm using a monorepo with multiple TypeScript versions. Will upgrading break older projects?
If some packages in your monorepo still use TypeScript 4.x, @typescript-eslint v6.x remains compatible (it supports TypeScript ≥4.7). However, you should test your ESLint config across all packages. Consider using ESLint's overrides to apply different parser versions per directory if needed.
Related
- Fix "Parsing error: Cannot find module next/babel"
- Fix TS2305: Module Has No Exported Member in TypeScript
- Cannot use JSX unless the '--jsx' flag is provided
- Fix ESLint 'import/extensions' Definition Not Found
Originally published at https://www.iloveblogs.blog
Top comments (0)