This error occurs when you try to import a namespace declaration as if it were an ES module or CommonJS module. The issue arises from mixing TypeScript namespace syntax with modern module import/export patterns.
This error happens when TypeScript encounters a mismatch between how code is exported and how it's being imported. TypeScript has two distinct code organization mechanisms: **Namespaces** are a TypeScript-specific feature that pre-dates JavaScript modules. They organize code into named objects but don't create actual module boundaries. **ES Modules (import/export)** and **CommonJS (require/module.exports)** are the standard module systems that create separate scopes and clear dependencies. When you try to import a namespace using modern module syntax—like `import * as namespace from './file'` or `import namespace from './file'`—TypeScript complains because namespaces aren't actual module exports. They're just scoped objects within the same global file scope.
Look at the file you're trying to import. If it contains code like:
namespace Utils {
export function doSomething() { }
}This is the problem. The namespace is declared but not exported as a module.
Replace the namespace syntax with ES module exports:
Before:
namespace Utils {
export function doSomething() { }
export const value = 42;
}After:
export function doSomething() { }
export const value = 42;This converts the namespace into a proper ES module.
Change from namespace-style imports to modern ES module syntax:
Before (doesn't work):
import * as Utils from './utils';
Utils.doSomething();After (works):
import { doSomething } from './utils';
doSomething();Or if you prefer namespace-like behavior:
import * as Utils from './utils';
Utils.doSomething();If you're using the old TypeScript triple-slash syntax:
Before:
/// <reference path="./utils.ts" />After:
import { doSomething } from './utils';Triple-slash references are an old pattern and don't work well with modern module systems.
Ensure your tsconfig.json is configured correctly for your module system:
For ES modules (recommended):
{
"compilerOptions": {
"module": "esnext",
"moduleResolution": "bundler"
}
}For CommonJS:
{
"compilerOptions": {
"module": "commonjs",
"moduleResolution": "node"
}
}Make sure the module setting matches your actual import/export syntax.
### Legacy Code Migration
If you're working with legacy TypeScript code that heavily uses namespaces (common in older Angular projects or .d.ts definition files), consider creating a "shim" file that exposes the namespace as a proper module export. This allows you to migrate gradually without rewriting all the old code at once.
### Namespace Merging
TypeScript supports namespace merging, where you can split a namespace across multiple files. This feature doesn't work with ES modules, which is another reason to migrate away from namespaces.
### Definition Files (.d.ts)
The namespaces pattern is still common in TypeScript definition files. If you're importing from a .d.ts file that uses namespaces, the library author needs to update it or provide separate type definitions.
### Why TypeScript Recommends Modules
ES modules have better tooling support, cleaner dependency graphs, and align with JavaScript's evolution. They're now the standard in Node.js and browsers.
Function expression requires a return type
Function expression requires a return type
Value of type 'string | undefined' is not iterable
How to fix "Value is not iterable" in TypeScript
Type 'undefined' is not assignable to type 'string'
How to fix "Type undefined is not assignable to type string" in TypeScript
Type narrowing from typeof check produces 'never'
How to fix "Type narrowing produces never" in TypeScript
Type parameter 'T' has conflicting constraints
How to fix "Type parameter has conflicting constraints" in TypeScript