Great stuff! Can you also do follow-up video on these video on using tsconfig for monorepos? For example what properties should go in the root config, what in some shared config and what config for the lib/apps themselves.
Got this recommended to me again. What a huge boon. This should be at the start of every TS tutorial. Thank you for making our lives easier EDIT: I made a comment about tsx (executable not JSX!) but I didn't realize you also mentioned it here! My bad. But seriously though that little gem has eluded me for sooo long but it's so helpful. I don't think I've seen much discussion about it (I always see ts-node). Or maybe there are but they're just not showing because of how unfortunately named it is 😅
Thanks, I never know what to put in the TSConfig when I'm making libraries and always seem to screw one of those up. Will be referring to this over and over again!
I’ve been digging into the tsconfig extensively during last couple of days and your cheatsheet has been very important source of information. I’ve got couple of questions though: The main question: Why do we need to set options for things that seem to be related to compilation via Typescript compiler when we DON’T use Typescript for compilation? What I mean - target “Sets the JavaScript language version for emitted JavaScript”. I understand that this applies when using Typescript for compilation. When NOT USING Typescript for compilation, (for example when using Next.js), why do I need target to be set? Similar with modules - it determines the module system for emitted JS when using Typescript compiler (at least in my understanding). Again, why do I need this when Next.js/SWC does compilation? Side questions: - “skipLibCheck” should be “true” so the .d.ts files in node_modules won’t be checked - if I have exclude: [‘node_modules’], do I still need this? - when using allowJs, do you recommend checkJS or not?
"target": You're absolutely right. I think you've caught a bit of faulty logic on my part. There's no practical reason why you should be setting target if you're not bundling. But if you don't set "target" you HAVE to set "lib" so TS knows what version of ES you're targeting. 1. RE: exclude: ['node_modules'], yes. 2. It's fine, you can use it or not. The key is if you're actually using JSDoc annotations inside .js files, then you MUST enable it.
@@mattpocockuk so that means we can simply leave "target" out in Next.js (with proper lib" option set), correct? And what about "module", can we leave it out as well?
This is my experience, it's useful if you're transpiling the ts through a bundler, some plugins will either ask for options similar to compilerOptions, but will also allow you to specify path to your tsconfig file and read your options from there.
@@branislavbrincko7237 Chatted to a member of the TS team about this and it's basically recommended to always specify target. Inferring it from "lib" is sometimes a bit dodgy, and other tools sometimes depend on reading a specific "target" value.
always using webpack together with babel to transpile, using tsc as the commande to transpile. Seems to me the most complete way to target most of the bowser's release
Matt! I'm trying to make a wrapper over a wrapper (over a wrapper...) over some data storage. A link to a playground with a very simplified version will be in the comments. When I return the inner wrapper, autocomplete and everything works fine. When I add a default value, the result is the same. When I try to use the default value inside a wrapper, TypeScript throws errors because it sees the union and not the exact wrapper type. I would appreciate it if you could show me how to convince TS that everything is ok (without using "as")
For anyone who get the "error TS1286: ESM syntax is not allowed in a CommonJS module when 'verbatimModuleSyntax' is enabled.", you just need to make sure that the package.json has "type":"module" set.
If I'm building a library/framework that I want to be used by projects that can be run in either node or browser (and I want different behavior from it based on that), what do you recommend I set `lib` option to? Include `dom` and `dom.iterable` and then do runtime checks if they are available?
Nice video. I also think that strict: true is must have. But what i dont understand is why for exampl nest.js is not strict by default. Any explanation for that?
i dont add "lib" and "types" inside the tsconfig, instead: - i make an `env.d.ts` - for libs i use `/// ` and others stuff in the file - and for types, i just import them, like: `import "@total-typescript/ts-reset"`, `import "bun-types"` and stuff this ^ way i can just copy paste tsconfig files. because everything environment specific are inside `env.d.ts` now also i use these a lot too: "noUncheckedIndexedAccess": true, "noPropertyAccessFromIndexSignature": true, "exactOptionalPropertyTypes": true
I think it's worth noting that none (?) of the Rust/Go based bundlers (SWC, tsup/esbuild) support emitting declaration maps, which makes building libraries with these tools a bit annoying in a mono repo setting, for the reason you mentioned with go to reference. If anyone knows how to get declarationMap to work with a fast bundler, please educate me.
When isolatedDeclarations lands in TypeScript, this will let library developers outsource the creation of declaration files and declaration maps to esbuild/swc. That'll be massive for the ecosystem, and solve the problem you're having.
@@mattpocockuk Is there any timeframe for when this will happen? I've spent day and night the past weeks trying to set up my "perfect" monorepo in TypeScript with pnpm, Turbo, tsup, ts-node with swc, all the cool stuff. I've been back and forth between different setups, and finally thought I had the perfect one. Then I discovered this quirk with the bundlers and I went back to just importing directly from src. While I have you here, I just wanted to say that you've been a huge inspiration for me the past year. Ironically your two latest videos (this one and the one about .js extensions) landed just days after I came to the same conclusions. I'm pretty confident now that I have a good setup, "backed" up by one of the leading figures in the ecosystem. Thank you!
So, are the options of "If transpiling with TypScript" (moduleResolution, module, outDir, sourceMap) no needed if the transpiling is done by esbuild instead of tsc? I have a Vite (v5) project and I want to know if I should add or not those options.
@@mattpocockuk I was trying to use jsx to make UI for a game without a library so I ended up with some edge cases, but the jsx option in ts config was confusing with jsxFactory and jsxFragmentFactory. In the end it wasn't too bad but it gets more complicated when trying to set it up with a bundler. It gets worse when trying to make the JSX.d.ts with , importing types in a d.ts file and declaring the correct types for JSX.Element and JSX.IntrisicElement. it was a good exercise to understand how the sausage is made but a confusing one at the beginning
Do you have any tips on migrating a legacy code base to strict mode? I have tried an eslint plugin and a TS plugin with not desireable result (the TS plugin had a tendency to kill the TS server)
Followed this and am still pretty confused... I want to create a simple backend app (won't run in the browser). Went to console.log something and instantly it gave a warning saying that the console object is not present. Type safety is for junior devs like myself I feel like but yet the learning curve is huge to print a console.log app lol
I still want a way to say "Here is a string that is the content of a typescript file, strip it of all the typescript type system, and return the valid javascript" method or process.. Rather than point TSC at a file, and it create another file somewhere else.. I want a string in, string out... Still waiting for this to happen..
@@mattpocockuk This is looking very promising.. I haven't worked out how to pass a file content 'in' yet as a string, but I can atleast use 'write: false' to have the content.. Only thing worrying me now is it's turning some of my numbers from `-0.005` into `-5e-3` which, I guess works, just looks ugly as hell
noUnusedLocals and noUnusedParameters - should be turned off - you have eslint for that. noUncheckedIndexedAccess - is turned off on perpoise and you don't need to turn it on. exactOptionalPropertyTypes - not covered in the video, you should turn it on. Also explanations in video are unclear - didn't get anything new from it.
The tsconfig file has always been one of the hardest parts to figure out in TypeScript. Thank you for your explanation.
What..? Their documentation literally explains every option...
Hi guys anyone had ideas or idea of what app matt used for recording thanks 😊
This is gold, really some options I missed. Thank you
Great stuff! Can you also do follow-up video on these video on using tsconfig for monorepos? For example what properties should go in the root config, what in some shared config and what config for the lib/apps themselves.
This! 🔥
Second
That is exactly what I need right now.
Thank you Matt! 😊
yep me too 😋
Got this recommended to me again. What a huge boon. This should be at the start of every TS tutorial. Thank you for making our lives easier
EDIT: I made a comment about tsx (executable not JSX!) but I didn't realize you also mentioned it here! My bad. But seriously though that little gem has eluded me for sooo long but it's so helpful. I don't think I've seen much discussion about it (I always see ts-node). Or maybe there are but they're just not showing because of how unfortunately named it is 😅
Super useful! Thanks Matt!
Thanks, I never know what to put in the TSConfig when I'm making libraries and always seem to screw one of those up. Will be referring to this over and over again!
I’ve been digging into the tsconfig extensively during last couple of days and your cheatsheet has been very important source of information. I’ve got couple of questions though:
The main question:
Why do we need to set options for things that seem to be related to compilation via Typescript compiler when we DON’T use Typescript for compilation? What I mean - target “Sets the JavaScript language version for emitted JavaScript”. I understand that this applies when using Typescript for compilation. When NOT USING Typescript for compilation, (for example when using Next.js), why do I need target to be set? Similar with modules - it determines the module system for emitted JS when using Typescript compiler (at least in my understanding). Again, why do I need this when Next.js/SWC does compilation?
Side questions:
- “skipLibCheck” should be “true” so the .d.ts files in node_modules won’t be checked - if I have exclude: [‘node_modules’], do I still need this?
- when using allowJs, do you recommend checkJS or not?
"target": You're absolutely right. I think you've caught a bit of faulty logic on my part. There's no practical reason why you should be setting target if you're not bundling. But if you don't set "target" you HAVE to set "lib" so TS knows what version of ES you're targeting.
1. RE: exclude: ['node_modules'], yes.
2. It's fine, you can use it or not. The key is if you're actually using JSDoc annotations inside .js files, then you MUST enable it.
@@mattpocockuk so that means we can simply leave "target" out in Next.js (with proper lib" option set), correct?
And what about "module", can we leave it out as well?
This is my experience, it's useful if you're transpiling the ts through a bundler, some plugins will either ask for options similar to compilerOptions, but will also allow you to specify path to your tsconfig file and read your options from there.
@@branislavbrincko7237 Chatted to a member of the TS team about this and it's basically recommended to always specify target. Inferring it from "lib" is sometimes a bit dodgy, and other tools sometimes depend on reading a specific "target" value.
Thanks, tsconfig is a big pain in monorepos.
Amen on the strict: true it's been my recommendation for years now ! 😂😂😂 Hopefully more and more people adopt it
Shared with the engineering team, thanks Matt, this is great
Thank you for your work. Very helpful!
Thanks Matt, I was literally struggling to copy some random tsconfig file for my side project right now.
For all the times I've been crying internally "SOMEBODY just tell me what to set in this *!_^$#*@# FILE" - Bless you sir !
So useful! I'd also love a short one on jsx options
this video is gold.
You are not the hero we deserved but better
always using webpack together with babel to transpile, using tsc as the commande to transpile. Seems to me the most complete way to target most of the bowser's release
Matt!
I'm trying to make a wrapper over a wrapper (over a wrapper...) over some data storage. A link to a playground with a very simplified version will be in the comments.
When I return the inner wrapper, autocomplete and everything works fine.
When I add a default value, the result is the same.
When I try to use the default value inside a wrapper, TypeScript throws errors because it sees the union and not the exact wrapper type.
I would appreciate it if you could show me how to convince TS that everything is ok (without using "as")
mattpocock.com/discord is the place to ask this!
One of the main reasons I hate TS is the config file nightmare 😂😂
For anyone who get the "error TS1286: ESM syntax is not allowed in a CommonJS module when 'verbatimModuleSyntax' is enabled.", you just need to make sure that the package.json has "type":"module" set.
Thanks for the video 👍
Would be interesting to look at config files for sveltekit, next, vue etc
Instant click, this is such a pain point. I'm always clueless about it every time I start a new TS project lol
THANK YOU
Kind of new to typescript, what do you think of useUnknownInCatchVariables?
What do you recommend for setting up path aliases with nodenext?
If I'm building a library/framework that I want to be used by projects that can be run in either node or browser (and I want different behavior from it based on that), what do you recommend I set `lib` option to? Include `dom` and `dom.iterable` and then do runtime checks if they are available?
Yep, exactly.
@@mattpocockuk Thank you :). Love the vids :P
Nice video. I also think that strict: true is must have. But what i dont understand is why for exampl nest.js is not strict by default. Any explanation for that?
i dont add "lib" and "types" inside the tsconfig, instead:
- i make an `env.d.ts`
- for libs i use `/// ` and others stuff in the file
- and for types, i just import them, like: `import "@total-typescript/ts-reset"`, `import "bun-types"` and stuff
this ^ way i can just copy paste tsconfig files. because everything environment specific are inside `env.d.ts` now
also i use these a lot too:
"noUncheckedIndexedAccess": true,
"noPropertyAccessFromIndexSignature": true,
"exactOptionalPropertyTypes": true
I think it's worth noting that none (?) of the Rust/Go based bundlers (SWC, tsup/esbuild) support emitting declaration maps, which makes building libraries with these tools a bit annoying in a mono repo setting, for the reason you mentioned with go to reference. If anyone knows how to get declarationMap to work with a fast bundler, please educate me.
When isolatedDeclarations lands in TypeScript, this will let library developers outsource the creation of declaration files and declaration maps to esbuild/swc.
That'll be massive for the ecosystem, and solve the problem you're having.
@@mattpocockuk Is there any timeframe for when this will happen? I've spent day and night the past weeks trying to set up my "perfect" monorepo in TypeScript with pnpm, Turbo, tsup, ts-node with swc, all the cool stuff. I've been back and forth between different setups, and finally thought I had the perfect one. Then I discovered this quirk with the bundlers and I went back to just importing directly from src. While I have you here, I just wanted to say that you've been a huge inspiration for me the past year. Ironically your two latest videos (this one and the one about .js extensions) landed just days after I came to the same conclusions. I'm pretty confident now that I have a good setup, "backed" up by one of the leading figures in the ecosystem. Thank you!
Is there any list which "lib" version like "es2022" is available and supported by bun?
So, are the options of "If transpiling with TypScript" (moduleResolution, module, outDir, sourceMap) no needed if the transpiling is done by esbuild instead of tsc? I have a Vite (v5) project and I want to know if I should add or not those options.
Correct. Vite does the transpilation.
God bless u
Looks like I'm doing some things incorrectly in my config, thanks Matt!
This is useful
what does "moduleResolution":"bundler" even do? Last time I messed around with that this option did not exist.
are some of these needed when using tsup ?
I would love a video on the mess that is JSX, i know thay when i was looking into it it was really hard to understand what was foing on.
What were you confused about?
@@mattpocockuk I was trying to use jsx to make UI for a game without a library so I ended up with some edge cases, but the jsx option in ts config was confusing with jsxFactory and jsxFragmentFactory. In the end it wasn't too bad but it gets more complicated when trying to set it up with a bundler. It gets worse when trying to make the JSX.d.ts with , importing types in a d.ts file and declaring the correct types for JSX.Element and JSX.IntrisicElement. it was a good exercise to understand how the sausage is made but a confusing one at the beginning
For monorepo, do you also add declaration:true? Or this is only for « simple » library?
Yep, you do
Do you have any tips on migrating a legacy code base to strict mode? I have tried an eslint plugin and a TS plugin with not desireable result (the TS plugin had a tendency to kill the TS server)
Is there any tool that does that automatically with sane defaults?
Followed this and am still pretty confused... I want to create a simple backend app (won't run in the browser). Went to console.log something and instantly it gave a warning saying that the console object is not present. Type safety is for junior devs like myself I feel like but yet the learning curve is huge to print a console.log app lol
You have for sure misconfigured something. This will help.
Also make sure you have @types/node installed
www.totaltypescript.com/tsconfig-cheat-sheet
What options would you recommend when using tsc solely to type check a JS repo that uses JSDoc?
"checkJS": true,
"noEmit": true,
"moduleResolution": "NodeNext",
"module": "NodeNext",
Thanks a lot. You’re a legend ❤️
Having decalarationMap didn't help my VSCode to navigate to the actual source code and not to the build .d.ts files 😬 Help on this?
Would need more info. Head to mattpocock.com/discord and we'll help out.
declarationMap didn't work in our Monoreo project.
Could you elaborate?
incrementalCompilation? Missed?
I'm not sure it's a sensible default, I've been bitten by the cache a few times.
Numpty award for the day... when I tried to cut-n-paste an option off of the screen! :/
I still want a way to say "Here is a string that is the content of a typescript file, strip it of all the typescript type system, and return the valid javascript" method or process.. Rather than point TSC at a file, and it create another file somewhere else..
I want a string in, string out...
Still waiting for this to happen..
Pretty sure esbuild exports a function that can do this very bloody fast.
@@mattpocockuk !!!! Wizard... Hunting for it now.. !!!!
Isn't that how Bun runs .ts files? Maybe you can use that somehow
@@mattpocockuk This is looking very promising.. I haven't worked out how to pass a file content 'in' yet as a string, but I can atleast use 'write: false' to have the content..
Only thing worrying me now is it's turning some of my numbers from `-0.005` into `-5e-3` which, I guess works, just looks ugly as hell
@@ColinRichardson That must be configurable.
Babel can also do this, as well as swc. I'm sure something will work.
JavaScript has many problems, but all the damn config files are definitely one of its worst
Don't teach people to cheat!
PS: I still need your head size.
noUnusedLocals and noUnusedParameters - should be turned off - you have eslint for that.
noUncheckedIndexedAccess - is turned off on perpoise and you don't need to turn it on.
exactOptionalPropertyTypes - not covered in the video, you should turn it on.
Also explanations in video are unclear - didn't get anything new from it.
What are your arguments against noUncheckedIndexedAccess?
Just curious, as we're currently thinking about activating it.
I never use strict: true - it gets in the way, and I know what's gonna be nullish or not in my codebase 😜
Oh my lord
Strict false 😅
Eek
Don't you need the `composite` only when using `references`? Or am I missing something?