https://chatgpt.com/share/0e0f2a80-c724-4c0e-b283-3f1189558a6a
src/types dir with a index.tsx file that imports all other types files in the dir. that way when importing you just import the global file.

https://www.reddit.com/r/typescript/comments/16wsn88/comment/k3brrm7/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

The tendency here seems to be define types where they are needed, and that is certainly the #1 rule and one you should follow.

1 Keep types close to their model

Ie if you are defining types near a relevant model say a User type (or IUser if thats your thing), it makes sense to also define the type there, and is what you should do because it's what most devs would expect.These can then be imported when needed, and depending on the size of your project it could be relevant to indicate the import type keyword(s?).

Please note it is not recommended to use this keyword*, because the compiler no longer needs it, but it does bring clarity to your codebase if you have large or complicated files.*

If you have DTOs or other cases where you need to model a variation type from a base type (ie PendingUser from User), it is also convenient to have these defined near each other.
It makes them easier to find and types are all about communicating with your fellow devs.

As for folder structure with this approach, I think colocation is the way to go, but I may be a bit biased, as I personally enjoy that approach.

I imagine something like:

src/
common/
auth/
user/
organization/
...
Here I would create the relevant user files; service; dto's; controllers etc., as well as the types. Types could be in a file of their own, as your own suggestion, but if so I would find a way to name them consistently to make search easier, ie userTypes.ts. And yes, I know you can see filepath when searching, but I personally find the model in the filename to be a better choice.

2 Keep global types available in a types folder

If you have global types that needs to be used often in many places across the application, say if you're working on a backend application and need to define types for req.user, it might be worth keeping a main.d.ts file, near the root of your project (often in a ./types/ folder).

Within your types/ folder you can structure with as many or few folders as you'd like, creating the folder structure that makes sense to you. I would recommend keeping a common/ folder, and then just creating a folder for each resource where this approach might be relevant (it should be few!).

In the ./types/main.d.ts file you can import files using the following syntax:

// types/main.d.ts
/// ///

(Note the triple slash on reference paths).

In your tsconfig.json you would need to define "typeRoots": ["./types" ] and you should be good to go.

This approach is only preferable if:

A) You are not building an npm library that is injected into another application, as the global types file will pollute the importing project

B) You have types that are being used "globally" (across the application), and often.

3 Prefer type over interface

As a final note, it seems the general consensus is to prefer using type over interface whenever possible.

I'm still learning and researching on this last note, but that does seem to be true from what I've found so far :-)

I hope it helps!

interfaces vs classes

or abstract classes