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.
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
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?
@@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
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.
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.
