Fix React/Jsx-Runtime Declaration File Not Found in TypeScript

typescript react jsx-runtime tsconfig npm

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.

← Back to all articles