Fix React/Jsx-Runtime Declaration File Not Found in TypeScript
The react/jsx-runtime declaration file error means TypeScript can't find the type definitions for React's new JSX transform. The fix is almost always installing (or reinstalling) @types/react at a version that matches your react version, then confirming that your tsconfig.json uses "jsx": "react-jsx". If you already have the types installed, a stale node_modules or a version mismatch is the usual culprit.
npm install --save-dev @types/react @types/react-dom
Pin the types to the same major as your installed React. If you're on React 18, install @types/react@18. On React 19, install @types/react@19. Mixing a React 18 runtime with React 19 types (or vice versa) is one of the most common reasons this error keeps appearing even after a fresh install.
# Match your React major version explicitly.
npm install --save-dev @types/react@18 @types/react-dom@18
Configure tsconfig.json for the New JSX Transform
The react/jsx-runtime module only gets imported when your compiler emits the new JSX transform. If your tsconfig.json still uses the legacy "jsx": "react" setting, you shouldn't be hitting this error at all. If you are, it usually means a dependency resolves the new runtime while your config hasn't caught up.
{
"compilerOptions": {
"jsx": "react-jsx",
"module": "esnext",
"moduleResolution": "bundler",
"esModuleInterop": true,
"skipLibCheck": true,
"types": ["react", "react-dom"]
},
"include": ["src"]
}
Use "react-jsx" for production code and "react-jsxdev" only if you want dev-mode runtime warnings. The "moduleResolution": "bundler" setting matters, because older "node" resolution sometimes fails to discover the jsx-runtime subpath export. It predates the exports field in package.json.
If It Still Breaks: Clear the Cache
After you update types, TypeScript's incremental build cache and your editor's TS server often hold onto the old resolution. Delete the cache and restart.
# Wipe the build cache and reinstall cleanly.
rm -rf node_modules package-lock.json
rm -f tsconfig.tsbuildinfo
npm install
# In VS Code: Cmd/Ctrl+Shift+P -> "TypeScript: Restart TS Server".
Gotchas Worth Knowing
If you use pnpm, hoisting rules can hide @types/react from transitive dependencies that expect it. Add it to your root package.json as a direct devDependency even if you think a library already provides it. With Yarn PnP, you might need to add @types/react to packageExtensions for libraries that forgot to declare the peer dependency.
Another trap: some older libraries ship their own stale React types that shadow the real ones. If tsc --traceResolution shows react/jsx-runtime resolving inside node_modules/some-lib/node_modules/@types/react, deduplicate with npm dedupe or pin a resolution.
// package.json
{
"overrides": {
"@types/react": "18.2.45",
"@types/react-dom": "18.2.18"
}
}
Last Resort: Ambient Declaration
If you're stuck on a locked-down codebase and can't install types, you can silence the error with an ambient module declaration. This is a workaround, not a fix, because you lose all type safety for JSX. Only use it while waiting for a proper install.
// src/types/jsx-runtime.d.ts
declare module "react/jsx-runtime" {
const runtime: any;
export default runtime;
export const jsx: any;
export const jsxs: any;
export const Fragment: any;
}
In summary, install matching @types/react and @types/react-dom, set "jsx": "react-jsx" with "moduleResolution": "bundler", and clear caches if the editor still complains. Ninety-nine percent of the time, that sequence resolves it.