SECURITY WARNING: Never run commands you don't understand. Always review code before execution. Use at your own risk.
TypeScript New Added 10 September 2026

TypeScript: Two different types with this name exist, but they are unrelated

Two copies of the same type package are installed at different paths, usually @types/react or @types/node pulled in at two versions by different dependencies. The types are structurally identical but nominally distinct, so a value from one tree cannot be assigned to a parameter typed by the other.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix
# Find the duplicates, path and version
npm ls @types/react @types/node
# pnpm why @types/react     yarn why @types/react

# Pin one copy for the whole tree (npm 8.3+)
# package.json
"overrides": { "@types/react": "18.3.12" }
# yarn: "resolutions", pnpm: "pnpm.overrides"

# Then flatten and rebuild
rm -rf node_modules package-lock.json && npm install
npx tsc --noEmit

# Confirm only one copy remains
find node_modules -path '*@types/react/package.json' -not -path '*/node_modules/*/node_modules/*'

How to diagnose TypeScript errors

TypeScript errors are the compiler describing a mismatch between what you declared and what you did. Nearly all of them fall into assignability (this shape is not that shape), missing declarations (a JavaScript package with no types), or strict null checks (a value can be undefined on a path you did not handle). Casting with as or any silences the message without fixing the underlying mismatch, which usually reappears at runtime.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

  1. Read the error from the innermost "Types of property X are incompatible" line outward. That nested line names the actual mismatch.
  2. For missing declarations, try npm i -D @types/<pkg> first; if none exists, write a minimal .d.ts rather than reaching for any.
  3. Narrow rather than assert. A type guard, an in check, or an early return preserves safety where as discards it.
  4. Use tsc --noEmit --pretty to check the whole project; editors sometimes use a different TypeScript version than the build.
  5. Check strict, skipLibCheck and moduleResolution in tsconfig when errors appear only in CI or only in the editor.

Tools worth reaching for

  • tsc --noEmit
  • ts-node / tsx
  • @types/* packages
  • typescript-eslint
  • editor TS version selector

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

docs.npmjs.com

Related TypeScript errors

See all 19 TypeScript errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.