You pre-empted me and my commenting, you rascal! 😉 Tbh though, whatever you've got going could work just fine as long as you eliminate the echo. That is to say, sound treating the room.
I think folks do it cuz: 1) The ".d" part of the filename makes it seems like it's where you should define types or something 2) When you open any library "d.ts" file and you'll see that it's a file full of type definitions, one can get the impression that "d.ts" files are simply files where you define types you wanna use across your project (not saying that's right, just describing the impression i had had)
That's why I generally don't like 90% of the web devs I've encountered: they assume lots of stuff and usually think others are in the wrong, not them. Web devs are the forever wanna be devs, not putting enough work to understand their flaws and wanting others to bend to their flawed necessities. And I'm a web dev.
I have an answer to your question: Why do people use them? I can answer anecdotally with my experience: because ts docs are a mess, and you didn't yet made an explaination video about it. 2 takeaways: - ts docs should be rewritten from scratch - you are a rare gem, thanks for existing ❤
Well said Matt. When writing typescript code is usually have a directory "types" in which files that add my own types to the global namespace using declare global ... Good one 👍
Thanks for the revelation, Matt. I think I do this because types feel like such a specific feature of a codebase to me that it doesn't make sense for type declarations to be modular inherently. It made more sense in my head for them to be global; if TS doesn't end up in the bundle anyway, why should I care about the import statements? That's just how I thought about it, but never thought that it could be an issue.
Thanks, that exactly that info i want. I wondered why I shouldn’t store all my types and interfaces in d.ts, because it looked convenient - I don’t have to import them. But I suspected there was a catch somewhere...
Putting my internal types into a global.d.ts file caused me a lot of headaches to actually get it to work and then realize that this approach was completely stupid. Not only because Typescript interprets two different types of declaration files (one with imports and one without), but also because it's very cumbersome since you have to re-type all the used internal classes because of the type-value difference. I learned that you should not use declaration files if the compiler does not complain about missing types from external modules or unknown imported file types it cannot read.
Found this out the hard way a while ago. Now I only use .d.ts files to declare certain modules I need to have globally available. For example, if I'm using SCSS modules, Typescript normally doesn't know or understand what they are so I declare them in my types.d.ts as declare module "*.module.scss" { const content: { [className: string]: string }; export default content; } I suppose this is what it was meant for
This explanation pretty much put you on main part of normal distribution where on the left side there's a noob and other side senior, saying "it works, don't care".
That's very helpful to know! Something else I've wondered, is should we put centralize the types, or have them distributed around the codebase. At work, we have a types folder with multiple files for each kind of category like auth.ts, billing.ts, etc. Is that an antipattern?
Hi Matt, thanks for this! Very interesting. About skipLibCheck, I thought it was about all the typings, not just custom ones. But why disabling it? I mean, wouldn't it be better to have it disabled ("false") so TS warn you are making code-smell? Would it be perhaps be better to have a tsconfig.build.json file that turns it true while on development it is turned to false? I'm used to always create two tsconfig files, one for build and one for development. What's your suggestion here? Do you agree with this way of making ts projects? Thanks!
@@mattpocockuk I make tsconfig.json to extend tsconfig.build.json, so what's really important stands in production file while things like "paths" stays in the dev
I use .d.ts to declare some project specific types that I want to use everywhere in the project. That way they got into global scope so I don't need to import them in every single module that uses them. I also use namespaces, so different parts don't clash with each other. What's wrong with that?...
1. When you need to type some JavaScript 2. When you want to make alterations to a global type, like in this article: www.totaltypescript.com/how-to-properly-type-window
Can you do a video on why packages that ship with types, should include the declaration maps and source ts files in the package? It's very annoying not having `go to definition` work.
I have a related question that maybe somebody have faced before : If i create a `customTypes.ts` file, where I create and export some interfaces/types, and i put that file inside the folder where I have my `main.ts` file (where I write my code), How could I exclude that file/folder from the compilation? I'd like that the compiler do not create a `customTypes.js` when compiling. I tried to create a ` "exclude":["customTypes.ts"] ` in my `tsconfig.json`. , but since the file contains "export" declarations , the compiler walks through that file anyway. Do you have any standar solution, or a way to really exclude a file with import/export statements ?
Can you declare global types outside of the types.d.ts file? I know you can export and import individual .d.ts files throughout a project but I'd like to better organize global types.
I think you have to reevaluate your sentence. That you dont do it when you write Typescript. But for JavaScript, you can do it. If you generate JavaScript from your Typescript code, or just writing JavaScript itself. you have a prejudice that everyone writes Typescript. Maybe it is your preference, but not for everybody. At the end, if you write Typescript or JavaScript, your production code is JavaScript (your application and npm package), with our without d.ts files. I think you only prefer to write Typescript, and dont want to write the d.ts itself by hand.
Why would I want runtime features (1:38) in my *types* files anyways? They're for types. I used to prefer types.d.ts exactly because of this - it only allows adding actual types, not utility functions but ESPECIALLY enums (which generates runtime code) which I absolutely despise
I prefer separating types into different files inside a "types" folder that contain types for specific things (like database types in one file, utility types in other file and some app stuff in 3rd file), I don't like the approach of putting every single type into 1 file bc especially in large applications we end up with a huge and hard to maintain types file. Also, I put types into types files only if I have to use them somewhere else, otherwise I would just define a type right in the file that will use that type
I think all depends on the scope of the project and it's nature. If it's big one with hundreds of PR's and thousands types defined having a giant single file would be ridiculous 😂 in my experience the best is a mix. If you have some types u use Everywhere - use them in global scope. If you have types you use only where you defined it or use them somewhere else where you import it - use them within the file. If you have complex use case where some interfaces are shared, some are used separately - create one file if that benefit the clarity. Also worth to discuss these as you go with your teammates to make sure that you all following the same patterns and that you all agree. But this actually should be a part of Code Review and initial phase of a project
I do the same and for the first time I disagree with Matt on this one. If you put the types in a file co-located with the items using it (sometimes to solve circular references) and don't make it a definition file then you will now have an empty module output. I usually put the types in the same file but sometimes they need to be separated out for readability of the code it's typing for the other Devs in the team. I do agree there should never be actual code in a .d.ts file but then doing that had never even occurred to me.
Yup, I type stuff coming from APIs in d.ts files because they are global and are passed around through components. Seems like the correct way to do it so I am not having to redefine types every time I use them.
I use .d.ts to augment some types and interfaces of the external libraries. Example: there is a leaflet map library, and there are a bunch of plugins that are written in pure js, but they add to the library's inbuilt features. So to make typescript happy, I declare those types there.
At 1:20 Let me show you exactly why they're so bad... But a straight up answer never comes (only indirectly)... So I think I understand, but the explanatation doesn't go into why declaring types globally is a bad idea. And why can packages use them for sure, but you shouldn't as module declaration files... Still unclear to me. 😊
I used to write .d.ts files for ambient type suggestions via jsdoc before we took the time to swap to typescript's actual runtimes. It was a big project and it took a while to have the time to do the migration.
so if you wanted to make a package that was just a type definition to publish on npm, for example an AnyStringWithAutocomplete (that weird "| (string & {})" or something like that, you just have a .ts file instead of a .d.ts file?
All my projects have an index.d.ts in the project root where I augment libraries, like adding properties to the express req object, for typing process.env and adding semantic alises like type IsoDate = string or type UnixTimestamp = number.
I’ve been using TS because of ReactNative for years but it is only now that I’m realizing how much separate TS knowledge I need. I’m learning so much from your channel. Thank you the breakdowns!
I mean, we are talking about a superset of features (because Typescript really isn’t a language) that was designed to make a scripting language do something it wasn’t designed to do. And the bandage keeps getting bigger and bigger.
I agree with you but then, I was wondering why npm suggests you to create a `.d.ts` file when it could have just told you to have types files ? N.B. : I am currently creating a React npm package and I just saw the npm message...
A huge smile spread on my face when i read the title of this video. About a year and a half ago i started my first frontend dev job, and on my very first task, on the very first week, i stumbled upon our app's huge usage of the .d.ts files. I tried asking several of my peers what is this ".d.ts" file, and nobody knew, one assumed that the "d" stands for "deprecated" (to which i replied in a question - "so why did you declare new types in a new .d.ts file just two weeks ago?"). So i did a bit of investigation and soon enough i understood the depth of the antipattern that is spread all over. You see, i came from Python, and in Python, as Python is, it is extremely easy to make a huge mess and chaotic code, because no typing is required. So i was very sensitive to this issue. So at the end of this first week, and actually up until today, because this thing is like cancer, my crusade is to get rid of all our .d.ts files. Good luck to me.
I still dont understand the issue. I use d.ts files to make my types global so I don't have to import them into every file. What if every time I wanted to use "let" or "const", I had to import it? That would get annoying. So for certain other common fundamental types in my app, I put them in a d.ts file. Is that blasphemy?
Bad technology where people have to struggle with the question where their types go to ;-) Don't understand me wrong, TypeScript is the best thing which could happen to JS. But JS itself is horror and deserves to be forbidden :P
After seeing tons of garbage typescript definition file all over the place from different projects time to time, where you have to constantly jump between different files to check out and correct the typescript. Similar to when you have a big CSS file or multiple CSS files where you constantly have to hop over to check out a specific class style. For 99% of the times and non library development, if there is no hard guideline for the typescript definition across the team, I simply put typescript definition on the top of the same file that is using the typescript if it's not going to be shared anywhere. No import, no export, less typescript confliction during the review, people change it on demand, scope well, move out of scope on demand, no premature "typescript optimization”, works the best. Big file issue? It's always case by case. Big file can be simple if the code flow is clean, small file can be complex if there are tons of unnecessary nested abstractions everywhere. People will thank me later if they don't need to jump between files to figure out a simple logic.
I feel like this is the TypeScript docs's fault. I remember trying to read the docs about .d.ts files and not understanding the use cases for them. The docs do not make this clear.
I'm confused here. At one point you say "that's what declaration files are for, putting things in the global scope". Thrn uoubgononnto say "never put types in the global scope". So, why? And what are you supposed to put in declaration files ifnit's.notnthe types you eant to share? If you have types that are used throuout your projectnthen why eould you want to be importing them in every file? And why are you trying to put runtime code in your type declaration files anyway?
How about a video on why 40% of the people do this wrong. Is it bad documentation? Are the profession books teaching this wrong? Did everyone just learn it from some random youtuber?
whats interesting is why people use .d.ts in the first place .. as a FE dev we always just used .ts for interfaces ... but the internet kind of suggested otherwise. If it seemed like convention - people will follow. But why did we follow this guide to begin with?
I hate how fastify forces me to make d.ts files and use declaration merging for their interfaces. I spend weeks to setup the tsconfig so my monorepo packages work when being used as a dependency.
I hate .d.ts files because any time you jump to definition it actually jumps to the types. great, i know the types of this function that i have no idea what kt does..
When i started at my new job i saw this .d.ts file nonsense and well continued the pattern, now i regret my decision 😅 volate your damn types or wirst case have a types folecto share types easily.
Thanks for the information, but I haven't seen the use of .d.ts files in any tutorial project other than declaring types and interfaces. However, if you create a types.d.ts file in the root of the project, you can use types and interfaces without importing them, but just by specifying types (interfaces), which in my opinion is very convenient.
Hi @mattpocockuk - I watched the video more than once and I'm confused between the title of it and its content. Can I use an env.d.ts global file in my Astro app for example to declare a type that I know for a fact I'll use throughout my codebase? Is this not recommended?
I hate how the .d.ts files are often used in Express apps. The request object is given to middleware and the type of its data property is often defined using a .d.ts file. But all of the properties have to marked as possibly null since that's how the request object starts. And then every single middleware function has to type-check that property again for type safety.
i think a better explanation is that it is for compiled ts code that has become js, not for us to write directly so you can have the actual runnable code, and the types for developers to use
It's a cool feature, but you will have to be careful naming your types, specially if you're using React, or any other library or framework, because you could be naming a type with a name that already being used by that library/framework, and if you're not paying attention, you could end up choosing the wrong type.
I sometimes use global types for automatic declaration merging because I need to extend types that I share with my git submodule(s). This means i can share types with my submodule, but also extend these types with project specific stuff. I don't use .d.ts files for this, instead I use "declare global" in normal module files. Before watching your vid, I would have said it doesn't make a difference, but with your skipLibCheck advice, it does actually.
i always have a .d.ts file for my glsl files: declare module "*.glsl" { const value: string export default value } is this the correct way to do this? or should i use plain .ts?
New audio setup arrived today - thanks for bearing with me during my failed Shotgun Mic experiment.
You pre-empted me and my commenting, you rascal! 😉
Tbh though, whatever you've got going could work just fine as long as you eliminate the echo. That is to say, sound treating the room.
@@herrpez If you're on Twitter, you'll be able to see the latest no-echo setup:
twitter.com/mattpocockuk/status/1677624336285421569
@@mattpocockuk Sounds a lot better, and is no doubt a great deal easier than modifying the environment to suit the shotgun mic. 🙂
I think folks do it cuz:
1) The ".d" part of the filename makes it seems like it's where you should define types or something
2) When you open any library "d.ts" file and you'll see that it's a file full of type definitions, one can get the impression that "d.ts" files are simply files where you define types you wanna use across your project
(not saying that's right, just describing the impression i had had)
Absolutely! I was surprised how many people got that impression.
I think the real reason is that it makes the types global with no imports necessary.
Devs love globals, no matter how bad it makes the code smell.
That's why I generally don't like 90% of the web devs I've encountered: they assume lots of stuff and usually think others are in the wrong, not them.
Web devs are the forever wanna be devs, not putting enough work to understand their flaws and wanting others to bend to their flawed necessities.
And I'm a web dev.
That is exactly me. I put all my types in .d.ts file, maybe I should stop doing that from now on. Should I just put them in a .ts file then?
@@MAXHASS-ph5ib Thanks for the suggestion!
I have an answer to your question: Why do people use them?
I can answer anecdotally with my experience: because ts docs are a mess, and you didn't yet made an explaination video about it.
2 takeaways: - ts docs should be rewritten from scratch - you are a rare gem, thanks for existing ❤
clear, consise, crisp - You have awesome voice Matt!
Well said Matt. When writing typescript code is usually have a directory "types" in which files that add my own types to the global namespace using declare global ...
Good one 👍
Thanks for the revelation, Matt. I think I do this because types feel like such a specific feature of a codebase to me that it doesn't make sense for type declarations to be modular inherently. It made more sense in my head for them to be global; if TS doesn't end up in the bundle anyway, why should I care about the import statements? That's just how I thought about it, but never thought that it could be an issue.
Thanks, that exactly that info i want.
I wondered why I shouldn’t store all my types and interfaces in d.ts, because it looked convenient - I don’t have to import them.
But I suspected there was a catch somewhere...
Just found this video as I am learning TS. Well, time to refactor my code, while it is still fresh. :D
Putting my internal types into a global.d.ts file caused me a lot of headaches to actually get it to work and then realize that this approach was completely stupid. Not only because Typescript interprets two different types of declaration files (one with imports and one without), but also because it's very cumbersome since you have to re-type all the used internal classes because of the type-value difference.
I learned that you should not use declaration files if the compiler does not complain about missing types from external modules or unknown imported file types it cannot read.
Found this out the hard way a while ago. Now I only use .d.ts files to declare certain modules I need to have globally available. For example, if I'm using SCSS modules, Typescript normally doesn't know or understand what they are so I declare them in my types.d.ts as
declare module "*.module.scss" {
const content: { [className: string]: string };
export default content;
}
I suppose this is what it was meant for
Absolutely!
This explanation pretty much put you on main part of normal distribution where on the left side there's a noob and other side senior, saying "it works, don't care".
That's very helpful to know! Something else I've wondered, is should we put centralize the types, or have them distributed around the codebase. At work, we have a types folder with multiple files for each kind of category like auth.ts, billing.ts, etc. Is that an antipattern?
Here you go!
www.totaltypescript.com/where-to-put-your-types-in-application-code
@@mattpocockuk thanks!
Hi Matt, thanks for this! Very interesting. About skipLibCheck, I thought it was about all the typings, not just custom ones. But why disabling it? I mean, wouldn't it be better to have it disabled ("false") so TS warn you are making code-smell?
Would it be perhaps be better to have a tsconfig.build.json file that turns it true while on development it is turned to false?
I'm used to always create two tsconfig files, one for build and one for development. What's your suggestion here? Do you agree with this way of making ts projects? Thanks!
You definitely want the same rules in your tsconfig in dev and production. Much easier maintenance and keeps things more secure in the long run.
@@mattpocockuk I make tsconfig.json to extend tsconfig.build.json, so what's really important stands in production file while things like "paths" stays in the dev
I was using it the right as you explained but any way it was good to know that I can make that mistake.
I used to do exactly this until I found out you can't put enums in .d.ts files. That's when I learned I was doing it wrong
I use .d.ts to declare some project specific types that I want to use everywhere in the project. That way they got into global scope so I don't need to import them in every single module that uses them. I also use namespaces, so different parts don't clash with each other. What's wrong with that?...
And why not keep types in the component itself when they are not reuseable?
I've never seen anyone using a .d.ts file using for types used in the actual project, just JavaScript libraries
great content!
So when should you use it - specifically when you have a .js with types?
1. When you need to type some JavaScript
2. When you want to make alterations to a global type, like in this article: www.totaltypescript.com/how-to-properly-type-window
Can you do a video on why packages that ship with types, should include the declaration maps and source ts files in the package? It's very annoying not having `go to definition` work.
I have a related question that maybe somebody have faced before :
If i create a `customTypes.ts` file, where I create and export some interfaces/types, and i put that file inside the folder where I have my `main.ts` file (where I write my code), How could I exclude that file/folder from the compilation?
I'd like that the compiler do not create a `customTypes.js` when compiling.
I tried to create a ` "exclude":["customTypes.ts"] ` in my `tsconfig.json`. , but since the file contains "export" declarations , the compiler walks through that file anyway.
Do you have any standar solution, or a way to really exclude a file with import/export statements ?
What is wrong is to use the `export` key inside the types.d.ts file, right?
Correct!
I learnt this the hardway... haha
I use .d.ts files to add type declarations for regular js dependencies that do not export types, is this wrong?
Absolutely fine.
@@mattpocockuk Thanks, another question: is there a way to bypass that file when I ctrl+click on the module import, and send me to the node_modules?
Can you declare global types outside of the types.d.ts file? I know you can export and import individual .d.ts files throughout a project but I'd like to better organize global types.
declare global {
interface MyGlobal {}
}
after this video, i still don't understand what it's for
this happends because programmers don't know bases...
I think you have to reevaluate your sentence.
That you dont do it when you write Typescript.
But for JavaScript, you can do it.
If you generate JavaScript from your Typescript code, or just writing JavaScript itself.
you have a prejudice that everyone writes Typescript.
Maybe it is your preference, but not for everybody.
At the end, if you write Typescript or JavaScript, your production code is JavaScript (your application and npm package), with our without d.ts files.
I think you only prefer to write Typescript, and dont want to write the d.ts itself by hand.
my No. 1 tip for any programming: don't do things you don't understand!
So there's no real reason to not put your types in .d.ts files apart from personal preference
Why would I want runtime features (1:38) in my *types* files anyways? They're for types.
I used to prefer types.d.ts exactly because of this - it only allows adding actual types, not utility functions but ESPECIALLY enums (which generates runtime code) which I absolutely despise
skipLibCheck, though
@@mattpocockuk yeah - that and global scope is enough for me to keep away from them 👍
awesome video btw, as always
I prefer separating types into different files inside a "types" folder that contain types for specific things (like database types in one file, utility types in other file and some app stuff in 3rd file), I don't like the approach of putting every single type into 1 file bc especially in large applications we end up with a huge and hard to maintain types file. Also, I put types into types files only if I have to use them somewhere else, otherwise I would just define a type right in the file that will use that type
I think all depends on the scope of the project and it's nature. If it's big one with hundreds of PR's and thousands types defined having a giant single file would be ridiculous 😂 in my experience the best is a mix. If you have some types u use Everywhere - use them in global scope. If you have types you use only where you defined it or use them somewhere else where you import it - use them within the file. If you have complex use case where some interfaces are shared, some are used separately - create one file if that benefit the clarity. Also worth to discuss these as you go with your teammates to make sure that you all following the same patterns and that you all agree. But this actually should be a part of Code Review and initial phase of a project
I do the same and for the first time I disagree with Matt on this one. If you put the types in a file co-located with the items using it (sometimes to solve circular references) and don't make it a definition file then you will now have an empty module output.
I usually put the types in the same file but sometimes they need to be separated out for readability of the code it's typing for the other Devs in the team.
I do agree there should never be actual code in a .d.ts file but then doing that had never even occurred to me.
Yup, I type stuff coming from APIs in d.ts files because they are global and are passed around through components. Seems like the correct way to do it so I am not having to redefine types every time I use them.
Hi Matt, keep this content up, I really love improving my typescript skills with you
I use .d.ts to augment some types and interfaces of the external libraries.
Example: there is a leaflet map library, and there are a bunch of plugins that are written in pure js, but they add to the library's inbuilt features. So to make typescript happy, I declare those types there.
Yep - great idea.
Nice, I hadn't thought of doing this!
At 1:20 Let me show you exactly why they're so bad... But a straight up answer never comes (only indirectly)... So I think I understand, but the explanatation doesn't go into why declaring types globally is a bad idea. And why can packages use them for sure, but you shouldn't as module declaration files... Still unclear to me. 😊
I thought that d.ts was just naming convention for type related files and a lot of my dev friends also, lol…
So basically roughly half of the devs do not know what (or why) they are doing 😂Proper training and standards should be mandatory in our field ...
I used to write .d.ts files for ambient type suggestions via jsdoc before we took the time to swap to typescript's actual runtimes. It was a big project and it took a while to have the time to do the migration.
so if you wanted to make a package that was just a type definition to publish on npm, for example an AnyStringWithAutocomplete (that weird "| (string & {})" or something like that, you just have a .ts file instead of a .d.ts file?
Yes
i have to like before watching 🎉
enough for me to see you publishing new content
All my projects have an index.d.ts in the project root where I augment libraries, like adding properties to the express req object, for typing process.env and adding semantic alises like type IsoDate = string or type UnixTimestamp = number.
I do this as well. I thought that was the use case for them. Is there an alternative?
I’ve been using TS because of ReactNative for years but it is only now that I’m realizing how much separate TS knowledge I need. I’m learning so much from your channel. Thank you the breakdowns!
I mean, we are talking about a superset of features (because Typescript really isn’t a language) that was designed to make a scripting language do something it wasn’t designed to do. And the bandage keeps getting bigger and bigger.
PLEASE someone, can you create a video on HOW TO USE script CORRECTLY ?
I agree with you but then, I was wondering why npm suggests you to create a `.d.ts` file when it could have just told you to have types files ?
N.B. : I am currently creating a React npm package and I just saw the npm message...
A huge smile spread on my face when i read the title of this video.
About a year and a half ago i started my first frontend dev job, and on my very first task, on the very first week, i stumbled upon our app's huge usage of the .d.ts files. I tried asking several of my peers what is this ".d.ts" file, and nobody knew, one assumed that the "d" stands for "deprecated" (to which i replied in a question - "so why did you declare new types in a new .d.ts file just two weeks ago?").
So i did a bit of investigation and soon enough i understood the depth of the antipattern that is spread all over.
You see, i came from Python, and in Python, as Python is, it is extremely easy to make a huge mess and chaotic code, because no typing is required. So i was very sensitive to this issue.
So at the end of this first week, and actually up until today, because this thing is like cancer, my crusade is to get rid of all our .d.ts files.
Good luck to me.
I still dont understand the issue. I use d.ts files to make my types global so I don't have to import them into every file. What if every time I wanted to use "let" or "const", I had to import it? That would get annoying. So for certain other common fundamental types in my app, I put them in a d.ts file. Is that blasphemy?
But if you put your types without "export" keyword into .d.ts files, tsc fails compiling. (Cannot find name "...") Am I missing something ?
Bad technology where people have to struggle with the question where their types go to ;-) Don't understand me wrong, TypeScript is the best thing which could happen to JS. But JS itself is horror and deserves to be forbidden :P
After seeing tons of garbage typescript definition file all over the place from different projects time to time, where you have to constantly jump between different files to check out and correct the typescript. Similar to when you have a big CSS file or multiple CSS files where you constantly have to hop over to check out a specific class style.
For 99% of the times and non library development, if there is no hard guideline for the typescript definition across the team, I simply put typescript definition on the top of the same file that is using the typescript if it's not going to be shared anywhere.
No import, no export, less typescript confliction during the review, people change it on demand, scope well, move out of scope on demand, no premature "typescript optimization”, works the best.
Big file issue? It's always case by case.
Big file can be simple if the code flow is clean, small file can be complex if there are tons of unnecessary nested abstractions everywhere.
People will thank me later if they don't need to jump between files to figure out a simple logic.
I feel like this is the TypeScript docs's fault. I remember trying to read the docs about .d.ts files and not understanding the use cases for them. The docs do not make this clear.
I'm confused here. At one point you say "that's what declaration files are for, putting things in the global scope". Thrn uoubgononnto say "never put types in the global scope".
So, why? And what are you supposed to put in declaration files ifnit's.notnthe types you eant to share?
If you have types that are used throuout your projectnthen why eould you want to be importing them in every file? And why are you trying to put runtime code in your type declaration files anyway?
How about a video on why 40% of the people do this wrong. Is it bad documentation? Are the profession books teaching this wrong? Did everyone just learn it from some random youtuber?
TypeScript is the last gasp of OOP for real-world programming. You can skew OOP or FP, ya gotta pick one.
whats interesting is why people use .d.ts in the first place .. as a FE dev we always just used .ts for interfaces ... but the internet kind of suggested otherwise. If it seemed like convention - people will follow. But why did we follow this guide to begin with?
I use it for declaring types for our private js packages published by our organisation where they didn't bother to use typescript. 🤬
How to handle the npm lib which doesn't support TS. That's the reason i disabled the lib type check in config.
I hate how fastify forces me to make d.ts files and use declaration merging for their interfaces. I spend weeks to setup the tsconfig so my monorepo packages work when being used as a dependency.
I hate .d.ts files because any time you jump to definition it actually jumps to the types. great, i know the types of this function that i have no idea what kt does..
When i started at my new job i saw this .d.ts file nonsense and well continued the pattern, now i regret my decision 😅 volate your damn types or wirst case have a types folecto share types easily.
I hate how fastify is forcing me to use d.ts files when configuring for it in a more complex file structure like a monorepo is hell.
Thanks. I've not known what's the .d.ts for previously. Now I know.
Classic case of devs thinking they are smart. Keep it simple, folks.
Why would anyone put all their variable declarations in a separate file anyway? What a stupid thing.
I’m running to fix my code before my tech manager watched this video
File based organization of code is terrible period. Time to get rid of it and replace it with something more meaningful
Another problem you can run into, is that you can import non existing types to d.ts.
I've seen them of course, but I never understood what they did, so I never used them.
Yay me, I guess
So define types in .d.ts files for the sole purpose of not to manually import them else where is a bad idea?
I only use d.ts files to declare env variables or global things
in other news, opinions make coding hard. News at 11.
Thanks for the information, but I haven't seen the use of .d.ts files in any tutorial project other than declaring types and interfaces. However, if you create a types.d.ts file in the root of the project, you can use types and interfaces without importing them, but just by specifying types (interfaces), which in my opinion is very convenient.
I only use them for my types and interfaces never had a module there
My types go right before the variable, where they belong.
Hello, you're awesome. Great content dude!
I wish I had 50% of your knowledge
So we need to use .d.ts like .h files for c/c++ code? 😳
Hi @mattpocockuk - I watched the video more than once and I'm confused between the title of it and its content. Can I use an env.d.ts global file in my Astro app for example to declare a type that I know for a fact I'll use throughout my codebase? Is this not recommended?
Globals are just a bit iffy - but I suppose a global type is basically fine.
If your large code base has js files that are typed with .d.ts files then surely you want skipLibCheck to be false correct?
Yes, sadly
This is what a successful clickbait really means
I hate how the .d.ts files are often used in Express apps. The request object is given to middleware and the type of its data property is often defined using a .d.ts file. But all of the properties have to marked as possibly null since that's how the request object starts. And then every single middleware function has to type-check that property again for type safety.
Yeah it's not ideal. trpc does a much better job here.
Thanks Matt as per usual. The Typescript Don.
thanks to save my time buddy 👍🏻.
that's not completely true, if you export something from a .d.ts file it behaves like a module and not make your types globally accessible
Correct!
I think I have read about this in the docs...
Matt, I'm not kidding please write a ts book, I'll buy it instantly
Might be something in the works here...
i think a better explanation is that it is for compiled ts code that has become js, not for us to write directly
so you can have the actual runnable code, and the types for developers to use
This is what I got from the included link.
Hi, I didn't know that .d.ts files push the types in the global scope. Really love that feature. Love the video as well 🙏
It's a cool feature, but you will have to be careful naming your types, specially if you're using React, or any other library or framework, because you could be naming a type with a name that already being used by that library/framework, and if you're not paying attention, you could end up choosing the wrong type.
I put mine in a .t.ts file for just types
I got confused, It is OK to put my global types inside the types.d.ts file or not?
That pattern is sort of fine, but I'd prefer my types imported and exported.
Ty, my coworkers will listen to me now
I sometimes use global types for automatic declaration merging because I need to extend types that I share with my git submodule(s). This means i can share types with my submodule, but also extend these types with project specific stuff. I don't use .d.ts files for this, instead I use "declare global" in normal module files. Before watching your vid, I would have said it doesn't make a difference, but with your skipLibCheck advice, it does actually.
well this is just a bad language design
C# is an actual typed language 🙂
i always have a .d.ts file for my glsl files:
declare module "*.glsl" {
const value: string
export default value
}
is this the correct way to do this? or should i use plain .ts?
i like your channel
Would you advise against using d.ts to store global type helpers?
No - globals is what .d.ts files are for!
Pls bb, let me put just the type there.
Interesting! Is this somehow connected to "import type"?
No!