Importantly, types do not affect TypeScript emit[1]: you can take a TS program, replace every type with Banana and the compiler will have the same output.
(I am not sure, but I think the TypeScript emitter does use a "type checker" object for type-adjacent things like resolving scopes. But it does not use such an object for checking types during emit. Another way of saying this is that type checking can be done during emit but conceptually it's a an optional segue on the side, not the box immediately leading to .js files.)
[1]: http://neugierig.org/software/blog/2016/04/typescript-types....
Yeah, look like I get the relation between Emitter and Type Checker in the reversed way [1] :D The type checker should provide an EmitResolver. I'll update the post and the diagram!
[1]: https://basarat.gitbook.io/typescript/overview/checker#assoc...
The maybe too subtle point I was trying to make is that, even though the TypeChecker object literally provides an EmitResolver (I think? something like that?), in terms of the conceptual layout of the compiler, if you have a box labelled "Type Checker" it's natural for the reader to think it's where type checking happens.
In other words, the graph is something like
TypeChecker object -> EmitResolver -> js files
|
v
type checkingI wish more tech blogs were this well-written and focused.
I haven’t used it for a while, but I remember Balsamiq being a great tool, especially for quick low-fi UI wireframing.