Fix 'originalKeywordKind' DeprecationError in TypeScript
The 'originalKeywordKind' DeprecationError fires when @typescript-eslint packages are stuck on v5 while TypeScript moved on. Upgrade to v6.x and restart ESLint to clear it.
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.
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@^6If you use Yarn:
yarn add --dev @typescript-eslint/eslint-plugin@^6 @typescript-eslint/parser@^6After 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.
One email a month — the latest explained errors
What the site published that month — mostly Next.js, Supabase and Node errors, explained. You confirm by email; unsubscribe any time in one click.
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/parserIf 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.
Further reading: Fix Extremely Slow Drizzle IntelliSense on Large Schemas, Unexpected any. Specify a different type: fix or disable, Prettier and ESLint Indent Rules Conflicting: the Fix. Also see Fix Cannot resolve symbol 'Routes': stale JetBrains typings.
Frequently Asked Questions
Still stuck? Paste your error.
Paste the error message or stack trace — we check it against every fix and tool on the site.
Continue Reading
Fix ESLint: Module.createRequire is not a function
Reproduced on Node 10 vs Node 18 with the same node_modules: the crash is the Node runtime executing ESLint, not Parcel or a broken module resolution.
Prettier and ESLint Indent Rules Conflicting: the Fix
Stop fighting indent: Expected indentation of 2 spaces but found 4 by turning off the rule that conflicts with Prettier, not by retuning it.
Fix ESLint 'import/extensions' Definition Not Found
The import/extensions error appears when the eslint-plugin-import package isn't loaded. Register the plugin and extend airbnb-base to resolve it.


