The #TypeScript compiler might not be the fastest - but why is that such a big problem?
"We have a large project" - I get that, but there are other things you can do that will impact development speed and DX:
"We have a large project" - I get that, but there are other things you can do that will impact development speed and DX:
1) decouple type checking from development
Coupling your dev server start & reload with type-checking is not only slow and mostly unnecessary, it's also hindering. Comment out one line of code, see an error in the browser because of unnecessary import... why?
Coupling your dev server start & reload with type-checking is not only slow and mostly unnecessary, it's also hindering. Comment out one line of code, see an error in the browser because of unnecessary import... why?
TS6133: 'IconArrowRight' is declared but its value is never read.
I know, I'll fix it later. Who cares? TypeScript is perfectly capable of emitting JS even though you have type errors. Use that!
I know, I'll fix it later. Who cares? TypeScript is perfectly capable of emitting JS even though you have type errors. Use that!
I mostly rely on red squiggles I'm seeing in my editor, and then the CI pipeline for usages that I've missed. It's good enough. I rarely run the "type-check" command for the whole repo locally.
2) Chunk your "large project"
If your repo is big and everything needs to be type-checked all the time, you'll have other problems as well:
- everyone can import from anywhere, leading to a big mess that's hard to untangle
- you'll also test and lint everything all the time
If your repo is big and everything needs to be type-checked all the time, you'll have other problems as well:
- everyone can import from anywhere, leading to a big mess that's hard to untangle
- you'll also test and lint everything all the time
The solution: A monorepo with dedicated packages for features. This not only defines clear boundaries and dependencies, it also means you can add a task runner like @NxDevTools or @turborepo to speed things up.
A change in featureA should never need to trigger type checking / linting / testing of featureB, unless B depends on A.
This is probably the biggest speed gain for CI and locally you can get.
This is probably the biggest speed gain for CI and locally you can get.
Our monorepo has 24 packages and it's growing. A change in our design-system is kinda expensive because it is used in almost all packages. We're talking about 30 seconds to type-check everything here. Not great not terrible.
For most teams, type-checking takes less than 5 seconds, and our CI pipeline got a lot faster since we switched to @NxDevTools and parallel execution.
The @typescript compiler is a very complex tool that is hard to replace. I don't think it will happen unless the TS core team decides to do it themselves. I fully agree with this:
https://twitter.com/kitsonk/status/1582233957705211905
β’ β’ β’
Missing some Tweet in this thread? You can try to
force a refresh
γ
