TypeScript historically allowed a form of code organization called "custom modules" (module Example {}), later renamed to "namespaces" (namespace Example).Namespaces are an outdated way to organize TypeScript code.ES2015 module syntax is now preferred (import/export).

This rule does not report on the use of TypeScript module declarations to describe external APIs (declare module 'foo' {}).

exportdefault tseslint.config({
rules:{
"@typescript-eslint/no-namespace":"error"
}
});

module.exports={
"rules":{
"@typescript-eslint/no-namespace":"error"
}
};

Examples​

Examples of code with the default options:

module foo{}
namespace foo{}

declaremodule foo{}
declarenamespace foo{}

declaremodule'foo'{}

// anything inside a d.ts file

Options​

This rule accepts the following options:

typeOptions=[
{
/** Whether to allow `declare` with custom TypeScript namespaces. */
    allowDeclarations?:boolean;
/** Whether to allow `declare` with custom TypeScript namespaces inside definition files. */
    allowDefinitionFiles?:boolean;
},
];

const defaultOptions: Options=[
{ allowDeclarations:false, allowDefinitionFiles:true},
];

allowDeclarations​

Whether to allowdeclare with custom TypeScript namespaces. Default:false.

Examples of code with the{ "allowDeclarations": true } option:

module foo{}
namespace foo{}

declaremodule'foo'{}
declaremodule foo{}
declarenamespace foo{}

declare global{
namespace foo{}
}

declaremodule foo{
namespace foo{}
}

Examples of code for the{ "allowDeclarations": false } option:

module foo{}
namespace foo{}
declaremodule foo{}
declarenamespace foo{}

declaremodule'foo'{}

allowDefinitionFiles​

Whether to allowdeclare with custom TypeScript namespaces inside definition files. Default:true.

Examples of code for the{ "allowDefinitionFiles": true } option:

// if outside a d.ts file
module foo{}
namespace foo{}

// if outside a d.ts file and allowDeclarations = false
module foo{}
namespace foo{}
declaremodule foo{}
declarenamespace foo{}

declaremodule'foo'{}

// anything inside a d.ts file

When Not To Use It​

If your project uses TypeScript's CommonJS export syntax (export = ...), you may need to use namespaces in order to export types from your module.You can learn more about this at:

• TypeScript#52203, the pull request introducingverbatimModuleSyntax
• TypeScript#60852, an issue requesting syntax to export types from a CommonJS module.

If your project uses this syntax, either because it was architected before modern modules and namespaces, or because a module option such asverbatimModuleSyntax requires it, it may be difficult to migrate off of namespaces.In that case you may not be able to use this rule for parts of your project.

You might consider usingESLint disable comments for those specific situations instead of completely disabling this rule.

Further Reading​

• FAQ: I get errors from the@typescript-eslint/no-namespace and/orno-var rules about declaring global variables
• FAQ: How should I handle reports that conflict with verbatimModuleSyntax?
• TypeScript handbook entry on Modules
• TypeScript handbook entry on Namespaces
• TypeScript handbook entry on Namespaces and Modules

Resources​

• Rule source
• Test source