[REQ] [typescript] exported namespace in Typescript conflicts with ESlint

[RVledder]

By default, the models that get exported contain a namespace.

interface SomeModel { ... }
export namespace SomeModel {} // here

Is this by design?

ESLint has a no-namespace rule. That suggests that many TypeScript projects have no use for the exported namespace and thus fail to compile.

So, what is the reason to export it?

Was it perhaps initially for Angular 1 projects and environments that use AMD/CommonJS modules?

Possible feature

It could be removed from the default mustache file and thus the export. This would mean a backward incompatible API change for this openapi-generator library. And therefore a major upgrade version probably.

Another option would be to add it in the additional-properties, like:

npx openapi-generator-cli generate  -g typescript-angular --global-property models,supportingFiles additional-properties= noNamespaces=false

This is an addition and would not require a major version update of this project.

[RVledder]

The workaround is to generate a set of mustache templates:

openapi-generator-cli author template -g typescript-angular

And then in the template modelGenericEnums.mustache remove the lines:

// remove this part
{{^stringEnums}}
export namespace {{classname}} {
{{/stringEnums}}
// ...
// and remove the closing tag
{{^stringEnums}}}{{/stringEnums}}

And then use the -t flag in the cli command:

npx openapi-generator-cli generate  -g typescript-angular --global-property models -t openapi-generator-cli/out

But what I don't like about this is that you have a folder with quite a bunch of files with which you don't do anything. And not sure about what happens if there is an update in this library. Then you'd have to re-generate this folder.

[RVledder]

Considerations

TypeScript namespaces were widely used before ES6 modules gained universal support, providing a way to organize large codebases and avoid name collisions

Namespaces allow grouping of related interfaces, types, and enums together. This helps with code navigation, especially in large or auto-generated files. Some users still prefer this organization for types tightly coupled by API structure.

Namespaces can be used to extend interfaces or types with static helper functions, a pattern still occasionally used in some Angular and TypeScript projects

Interoperability and Usability

Some environments or workflows using AMD/CommonJS modules or legacy Angular setups may expect namespace structures rather than ES module exports, allowing easier integration.

Namespaces are less likely to cause “global leakage” in generated code, since the code generator controls namespace encapsulation for the client.

Why Are Namespaces Generally Discouraged in Modern TypeScript?

Despite their original purpose, namespaces are discouraged today for several reasons:

Modern ES Modules: ES6 modules provide a global import/export mechanism, rendering most uses of namespaces unnecessary and even counterproductive.

Global Scope Pollution: Namespaces can create global variables that risk naming conflicts and make code harder to maintain or refactor.

Tree Shaking Limitations: Bundlers like Webpack and Rollup can’t tree-shake code inside namespaces, resulting in larger bundles.

Tooling Compatibility: Namespaces are not supported in JavaScript and can complicate integration with modern build tools focused on modules.

[jase88]

With the Typescript Compiler flag erasableSyntaxOnly syntax features like namespaces and enums are completely forbidden.

Maybe as first step (to avoid a breaking change) a configuration flag like onlyErasableSyntax could be introduced.
This would probably also be interesting for other TypeScript targets.