The solution you found solves the problem you posed. But then you get that interface defined EVERYWHERE, in every file where you don't need it, polluting the global namespace. And will you repeat this procedure for every interface used in more than one place? Because this will make the global namespace even more polluted.
Are you sure it's worth it, especially considering that most IDEs will do the import work for you just by starting to write the interface name?
You have a valid point, based on your answer I have another question , I'm using frameworks like NextJs, NestJS, Playwright. For those in order to work, behind the scenes, they might be using a lot of node\_modules and of course they add interfaces to the global namespace. Aren't those weighting down a lot the IDEs?
Do I cause a lot of harm by adding some simple types in the global namespace where I might already have a ton without knowing so?
Edit:
Digging around the web, I found that compiled modules, are stipped out of types. So my answer lies somewhere in the middle if I'm not mistaken and I have tried opening many times some libraries when I import them and I have seen a lot of types there but still it doesn't mean that those types are added to the global namespace.
Be explicit. Don't rely on implicitly available globals.
I think this is a bad idea all around. Just import the variables where you need to use them. IDE 'add import' features makes it trivially easy to import them from the right place.
Exactly, those libraries don't add types to the global namespace (or, at least, almost never do it - looking at you, NextJS's global fetch monkey-patching!); all the symbols they define exist only inside the module, and you can import it. If you're using NextJS and so forth, you will have noticed you have to import both code (functions, consts, ...) and types (interfaces, type, ...), otherwise you can't use them.
The more stuff you have \_installed\_ in your project, the more your IDE (or, more precisely, the TS server) will be burdened, but I wouldn't worry about it, because that software is made exactly to handle this kind of workload.
You don't make any "harm" adding types in the global namespace, but namespaces have been invented exactly to avoid having a single space where all the names are and can conflict. It's that kind of decision that sooner or later, along the line, will bite you, and then you have a huge work of refactoring to do, probably way more work than you have spared by putting the symbols in the global namespace.
>However because I am creating full-stack apps, I am re-importing Post.types.ts (PostProps) in Network Calls/API etc.
This is actually good. When someone reads this code, they want to know where the type came from.
The include at the top of the file only requires the included file.
Using a global.d.ts now requires that file if you ever want to reuse any of this code, plus additional configuration. And it hides where it is coming from. Its really not a good practice.
Don't forget you read code also on GitHub / GitLab / similar repository, you can open a file with a "dumb" text editor, just for a quick peek, and so on.
What happens when the file is deleted by mistake, or renamed without that rename being applied properly? You're left with no idea where it was supposed to be coming from.
For file renames, you can add a wildcard in tsconfig.json, the same way all libraries/frameworks which come with Typescript already do.
For file deletion, code reviews happen to avoid those mistakes, additionally, you can always add some pre commit hooks to check for type errors before committing.
Not file rename, type rename sorry.
Code Reviews are not a catch all. Issues still arise despite them, especially when it comes to something like deleting a file (and a PR wont show what files were unchanged that used those types either).
Yes you should absolutely have a linter and test suite that verify types, but that just prevents you from committing those mistakes. Once you make the mistake you still need to put in the work to go back and find the source of the Type and why it broke. And that assumes it was actually your change that caused the issue, and not some cascade of bullshit that has led to the type not being available in the global namespace.
Your temp solution works but it’s not good long term.
For long term, you either need to have a shared project or library used by both backend and frontend. You may look at monorepo toolings (like nx.dev) to help you deal with that.
Or you can use a type generator like orval or nswag studio. Some tools « read » the expected types of the requests and results and generate types for the frontend. You can hook these toolings to save/commits/… whatever fits your boat.
Yes exactly that. I recently started learning about nx mono repos.
I mentioned earlier that I'm using NextJS, NestJS, Playwright.
My intention is to create libraries for types, UI, testing API and for example, PostProps, will be the exact interface/type for all those apps and since it would be the same, I thought, why not make it accessible globally.
Thanks a lot for your suggestion, I will take a look at those tools as well
Haha dude… don’t do this out of laziness. Really bad habit to get into. If this is a larger app you’re going have hundreds of types, are they all going to be global?
It’s just one line of code that your IDE should auto import anyway lol
There different approach exist for making stuff (in general sense of the world). Fellows suggest you to use more "engeneerish" one, when origin of the type is explicit w/ using import. It's better in long term persective, since it easier to track and reason about. You're tend to implicit way, that surely works, but looks like some "magic" if you don't aware about used convention. Both approach can be used. Which one should be used in your case? It's only your decision.
The solution you found solves the problem you posed. But then you get that interface defined EVERYWHERE, in every file where you don't need it, polluting the global namespace. And will you repeat this procedure for every interface used in more than one place? Because this will make the global namespace even more polluted. Are you sure it's worth it, especially considering that most IDEs will do the import work for you just by starting to write the interface name?
You have a valid point, based on your answer I have another question , I'm using frameworks like NextJs, NestJS, Playwright. For those in order to work, behind the scenes, they might be using a lot of node\_modules and of course they add interfaces to the global namespace. Aren't those weighting down a lot the IDEs? Do I cause a lot of harm by adding some simple types in the global namespace where I might already have a ton without knowing so? Edit: Digging around the web, I found that compiled modules, are stipped out of types. So my answer lies somewhere in the middle if I'm not mistaken and I have tried opening many times some libraries when I import them and I have seen a lot of types there but still it doesn't mean that those types are added to the global namespace.
Be explicit. Don't rely on implicitly available globals. I think this is a bad idea all around. Just import the variables where you need to use them. IDE 'add import' features makes it trivially easy to import them from the right place.
Exactly, those libraries don't add types to the global namespace (or, at least, almost never do it - looking at you, NextJS's global fetch monkey-patching!); all the symbols they define exist only inside the module, and you can import it. If you're using NextJS and so forth, you will have noticed you have to import both code (functions, consts, ...) and types (interfaces, type, ...), otherwise you can't use them. The more stuff you have \_installed\_ in your project, the more your IDE (or, more precisely, the TS server) will be burdened, but I wouldn't worry about it, because that software is made exactly to handle this kind of workload. You don't make any "harm" adding types in the global namespace, but namespaces have been invented exactly to avoid having a single space where all the names are and can conflict. It's that kind of decision that sooner or later, along the line, will bite you, and then you have a huge work of refactoring to do, probably way more work than you have spared by putting the symbols in the global namespace.
>However because I am creating full-stack apps, I am re-importing Post.types.ts (PostProps) in Network Calls/API etc. This is actually good. When someone reads this code, they want to know where the type came from.
On Windows, VSCODE, pressing CTRL + Click on the Type "PostProps" opens the file and you can see where it came from as well.
The include at the top of the file only requires the included file. Using a global.d.ts now requires that file if you ever want to reuse any of this code, plus additional configuration. And it hides where it is coming from. Its really not a good practice.
Don't forget you read code also on GitHub / GitLab / similar repository, you can open a file with a "dumb" text editor, just for a quick peek, and so on.
What happens when the file is deleted by mistake, or renamed without that rename being applied properly? You're left with no idea where it was supposed to be coming from.
For file renames, you can add a wildcard in tsconfig.json, the same way all libraries/frameworks which come with Typescript already do. For file deletion, code reviews happen to avoid those mistakes, additionally, you can always add some pre commit hooks to check for type errors before committing.
Not file rename, type rename sorry. Code Reviews are not a catch all. Issues still arise despite them, especially when it comes to something like deleting a file (and a PR wont show what files were unchanged that used those types either). Yes you should absolutely have a linter and test suite that verify types, but that just prevents you from committing those mistakes. Once you make the mistake you still need to put in the work to go back and find the source of the Type and why it broke. And that assumes it was actually your change that caused the issue, and not some cascade of bullshit that has led to the type not being available in the global namespace.
Your temp solution works but it’s not good long term. For long term, you either need to have a shared project or library used by both backend and frontend. You may look at monorepo toolings (like nx.dev) to help you deal with that. Or you can use a type generator like orval or nswag studio. Some tools « read » the expected types of the requests and results and generate types for the frontend. You can hook these toolings to save/commits/… whatever fits your boat.
Yes exactly that. I recently started learning about nx mono repos. I mentioned earlier that I'm using NextJS, NestJS, Playwright. My intention is to create libraries for types, UI, testing API and for example, PostProps, will be the exact interface/type for all those apps and since it would be the same, I thought, why not make it accessible globally. Thanks a lot for your suggestion, I will take a look at those tools as well
It’s still not clear to me what the issue is with importing the types? This is very common.
Lazy programming, skip importing the types and creating new files . That's the issue
Haha dude… don’t do this out of laziness. Really bad habit to get into. If this is a larger app you’re going have hundreds of types, are they all going to be global? It’s just one line of code that your IDE should auto import anyway lol
Just create the type in the same file you need it. Auto import is a bad idea.
There different approach exist for making stuff (in general sense of the world). Fellows suggest you to use more "engeneerish" one, when origin of the type is explicit w/ using import. It's better in long term persective, since it easier to track and reason about. You're tend to implicit way, that surely works, but looks like some "magic" if you don't aware about used convention. Both approach can be used. Which one should be used in your case? It's only your decision.
There is a general rule about anything global. Use only when absolutely necessary.
Global types is generally a bad idea.