[Feature Request] Support for TypeScript namespaces to prevent duplicate interface collisions

[rick-bongers]

What happened?

Currently, runtype generates TypeScript interfaces into a single output file using the class name as the interface name. While this works for unique class names, it causes duplicate identifier errors when multiple classes share the same name but reside in different namespaces (e.g., App\Resource\User\UserResource and App\Resource\Team\UserResource).

Current Behavior

If I have two classes with the same name in different namespaces, the generated output looks like this:

// Generated output
export interface User {
  id: number;
  email: string;
}

export interface User {
  id: number;
  username: string;
  preferences: any;
}

// ❌ Error: Duplicate identifier 'User'.

Proposed Solution

I suggest introducing support for TypeScript namespaces (or nested export objects) in the generated file. This would allow the generator to mirror the original namespace structure, ensuring name uniqueness.

The output should ideally look something like this:

export namespace Resource {
  export namespace User {
    export interface User {
      id: number;
      email: string;
    }
  }

  export namespace Team {
    export interface User {
      id: number;
      username: string;
    }
  }
}

Why this is needed

In larger projects (especially Domain Driven Design or projects with separate DTO/Entity layers), it is very common to have overlapping class names. Without namespace support, we are forced to manually rename classes or split generation into dozens of tiny, disconnected files, which defeats the purpose of an automated tool.

How to reproduce the bug

Create multiple resources in different namespaces with the same name

Package Version

0.3.3

PHP Version

8.4

Laravel Version

12

Which operating systems does with happen with?

No response

Notes

I am more than happy to contribute a Pull Request for this feature myself.
However, before I start diving into the implementation, I wanted to check:

• Is this a feature you would like to see integrated into the core library?
• Do you have any specific preferences regarding the implementation or configuration?

Let me know your thoughts, and I can start working on a proposal!

[mxaGianluca]

@rick-bongers yes, i think it's a good idea to put this in the core library. Thanks for pointing it out.

Do you think we should keep the default behavior to allow for backwards compatibility? Or just release it as a new major version?

I think the latter is best.

Regarding implementation and configuration, I'm open for suggestions here. I think if we follow the namespace of the application it would prevent any collisions. The question is, how far will we go with this? Should we build it up from the App level? App.Http.Resources.{ResourceName} or do we simply focus on models and resources.