Fix TS2305: Module Has No Exported Member in TypeScript

TypeScript rejects an import you're sure is correct:

Module '"./user-service"' has no exported member 'getUser'. (2305)

TS2305 means exactly what it says: the module does not export that name. The cause is almost always one of four things, and each has a precise fix. This guide walks them in order of frequency.

Cause A — wrong name, typo, or rename (most common)#

The named import must match an export exactly — case-sensitive.

// user-service.ts
export function getUser() {}
 
import { GetUser } from './user-service';   // TS2305 (wrong case)
import { getUser } from './user-service';   // correct
import { getUser as fetchUser } from './user-service';   // aliased

Cause B — default vs named export mismatch#

Importing a default as named (or vice versa):

// default export:  export default function foo() {}
import { foo } from './m';   // TS2305 — it's the default, not a named "foo"
import foo from './m';       // correct
 
// named export only:  export const bar = 1;
import bar from './m';       // TS1192: has no default export
import { bar } from './m';   // correct

So TS2305 and its sibling TS1192 ("has no default export") are usually the same root: you guessed the wrong export shape. Open the module (or its .d.ts) and check.

Cause C — CommonJS / ESM interop#

A CommonJS package (module.exports = ... / export =) default-imported with interop off throws TS1259 or TS2497 ("can only be default-imported using the 'esModuleInterop' flag").

// tsconfig.json — the fix
{ "compilerOptions": { "esModuleInterop": true } }

What esModuleInterop does (from the docs): with it off, import X from "moment" is checked as require("moment").default — which often doesn't exist. Turning it on changes the compiler's checking and emits helper shims (__importDefault, __importStar) so default/namespace imports of CommonJS work safely. It also automatically enables allowSyntheticDefaultImports.

The docs warn directly: "allowSyntheticDefaultImports without esModuleInterop should be avoided. It changes the compiler's checking behavior without changing the code emitted by tsc, allowing potentially unsafe JavaScript to be emitted."

If you can't change config, the namespace import is a safe workaround:

import * as React from 'react';   // no default needed

Cause D — a type-only export under verbatimModuleSyntax#

Single-file transpilers (Babel, esbuild, SWC) can't tell a type from a value, so under verbatimModuleSyntax you must use import type (errors TS1484/TS1485):

import type { User } from './types';   // type
import { createUser } from './api';    // value
export type { User };                  // re-export a type

Cause E — stale @types vs the runtime package#

If @types/foo is on a different version than foo, the typed export genuinely isn't in the installed .d.ts — a real TS2305. The source of truth is the .d.ts, not the JS.

npm ls foo @types/foo
npm i -D @types/foo@latest   # or pin to match the runtime major

Decision guide#

Official references: esModuleInterop, allowSyntheticDefaultImports, ESM/CJS interop handbook, isolatedModules.

Related Articles#

• TypeScript Migration Guide: Moving a JS Codebase in 2026
• Fix TS7016: Could Not Find a Declaration File for Module
• Fix Next.js Build Error Module Not Found After Deploy
• Interfaces vs Types in TypeScript: 2026 Best Practices
• Fix TS2564: Property Has No Initializer in TypeScript
• TypeScript Getter Setter Errors: TS1056, TS1028, TS2378 Fix
• JSX.Element vs ReactNode vs ReactElement: TS2322 Fix