This error occurs when attempting to import a module using default import syntax, but the module only exports named exports. The mismatch between import and export styles causes TypeScript or your bundler to fail.
The "Module has no default export" error indicates a mismatch between how you're importing a module and how it's actually exported. In JavaScript/TypeScript, there are two main export styles: default exports and named exports. A default export allows importing with any name you choose (`import MyComponent from './Component'`), while named exports require using the exact export name with curly braces (`import { MyComponent } from './Component'`). This error commonly occurs in React applications when: - Importing a component that uses named exports with default import syntax - Working with third-party libraries that only provide named exports - Migrating between different module systems (CommonJS vs ES Modules) - Using TypeScript with stricter module resolution settings The error is especially common in TypeScript projects because TypeScript enforces stricter module compatibility rules than JavaScript bundlers like Webpack or Babel, which sometimes perform "magic" transformations to make incompatible imports work.
First, examine how the module you're trying to import actually exports its values. Open the source file and look for the export statement.
Named export examples:
// Named exports
export const MyComponent = () => { ... };
export function MyComponent() { ... }
export { MyComponent };Default export examples:
// Default exports
export default MyComponent;
export default function MyComponent() { ... }If you're importing from a third-party library, check the package's index.d.ts file in node_modules/@types/[package] or the library's TypeScript definition files.
If the module uses named exports, update your import statement to use curly braces:
Before (incorrect default import):
import MyComponent from './MyComponent';After (correct named import):
import { MyComponent } from './MyComponent';For multiple named imports:
import { Component1, Component2, utilFunction } from './module';This is the most common and recommended fix, as it aligns your import with the actual export type.
If a module has many named exports or you want to avoid naming conflicts, use namespace import syntax:
import * as MyModule from './MyModule';
// Then use as:
<MyModule.Component />
MyModule.utilFunction();This approach is particularly useful when:
- The module has many exports and you need most of them
- You want to make the module origin clear in your code
- Working with React itself: import * as React from 'react'
If you're working with CommonJS modules or need compatibility with certain libraries, enable synthetic default imports in tsconfig.json:
{
"compilerOptions": {
"esModuleInterop": true,
"allowSyntheticDefaultImports": true
}
}Important: This only affects TypeScript type-checking, not runtime behavior. Use this when:
- Importing CommonJS modules that use module.exports
- Working with libraries designed for different module systems
- You have no control over the export style
Note: While this fixes the TypeScript error, it doesn't change the actual module behavior. The bundler (Webpack/Vite) must still support the import style.
If you own the module being imported and want to support default imports, change the export to default:
Before (named export):
export const MyComponent = () => {
return <div>Hello</div>;
};After (default export):
const MyComponent = () => {
return <div>Hello</div>;
};
export default MyComponent;Or use the inline syntax:
export default function MyComponent() {
return <div>Hello</div>;
}Best practice: Modern React style guides generally recommend named exports for better refactoring and IDE support, so only use this approach if you have a specific reason to prefer default exports.
After making changes, verify the error is resolved:
# Run TypeScript compiler
npx tsc --noEmit
# Or if using Next.js
npm run build
# For Create React App
npm run buildEnsure your IDE (VS Code, WebStorm) no longer shows red squiggly lines under the import. Restart the TypeScript language server if needed:
- VS Code: Cmd/Ctrl + Shift + P → "TypeScript: Restart TS Server"
Export Style Philosophy:
The React ecosystem has evolved in its export preferences. Early React tutorials often used default exports, but modern best practices increasingly favor named exports because they:
- Enable better tree-shaking in bundlers
- Provide clearer IDE autocomplete and refactoring
- Prevent naming inconsistencies across imports
- Allow multiple exports from a single file
TypeScript Module Resolution:
The allowSyntheticDefaultImports flag creates type-level compatibility but doesn't change JavaScript output. Your bundler (Webpack, Vite, etc.) must independently support the import pattern. This flag is primarily useful when:
1. TypeScript reports errors but the code runs fine (bundler handles it)
2. You're importing CommonJS modules in an ES Module project
3. Working with libraries that have complex module setups
CommonJS vs ES Modules:
This error frequently appears when mixing module systems:
- CommonJS: module.exports = Component (Node.js default)
- ES Modules: export default Component (JavaScript standard)
TypeScript's esModuleInterop flag bridges this gap, but runtime behavior still depends on your bundler configuration.
React Specific Considerations:
React itself (the library) uses named exports. Modern React recommends:
import { useState, useEffect } from 'react';However, some configurations allow:
import React from 'react';This works because bundlers like Webpack provide synthetic defaults. TypeScript requires esModuleInterop: true to accept this pattern without errors.
Auto-Import Pitfalls:
IDE auto-import features sometimes incorrectly suggest default imports for named exports. Always verify the import style matches the export, especially after using auto-complete suggestions.
React Hook useCallback has a missing dependency: 'variable'. Either include it or remove the dependency array react-hooks/exhaustive-deps
React Hook useCallback has a missing dependency
Cannot use private fields in class components without TS support
Cannot use private fields in class components without TS support
Cannot destructure property 'xxx' of 'undefined'
Cannot destructure property of undefined when accessing props
useNavigate() may be used only in the context of a <Router> component.
useNavigate() may be used only in the context of a Router component
Cannot find module or its corresponding type declarations
How to fix "Cannot find module or type declarations" in Vite