No actual type checking?

[Dave Townsend]

There are a couple of situations where you don't need to use tsc to compile your code to run as JavaScript. One is if you are using babel to build, another is if you are using JS comments to assign types.

I had expected that in these situations these packages would have allowed me to completely remove tsc from my workflow, I expected eslint to be able to flag type errors in my code but it seems that it does not and so now for the babel case I have a three step process to get my code running, run eslint to check some things, run tsc to check type correctness, run babel to build.

I don't know if this would be desired or not but it would be great if there were an eslint rule or something that could detect the type errors that tsc would find and error in that case. This would also mean that developers only need to set up editor integration for eslint in order to see problems, not typescript as well.

[Brad Zacher]

We purposely do not do type checking for a number reasons, namely:

• our vision for this project has always been to be a supplement to typescript's type checking, and fill in the gaps to make it more type safe.
• a lot of users don't use the parser with parserOptions.project, which means we physically cannot do type checking in those cases.
• we would only be able to do a half-assed job of it compared to typescript with its full diagnostic reporting and messaging infrastructure.

We have had a small number of users request this functionality, but it's not worth us reinventing the wheel and building one with square edges, when tsc --noEmit exists and is so straightforward to use.

I wouldn't want to speak on their behalf, but my understanding is that Babel has never been about type checking or code validation, because it's intended to be transpiler - it doesn't do any code validation. Them adding type checking logic would be even worse than us adding it, because where we are leveraging the typescript compiler API to parse files, they are parsing files themselves - so they would have to reimplement the entirety of typescript (instead of just having to parse type annotations as valid code, like they currently do). As it stands, babel doesn't even support all typescript features.

tl;dr - we won't be adding this functionality, because typescript does it better than we ever could.

---

This would also mean that developers only need to set up editor integration for eslint in order to see problems, not typescript as well.

You may not realise it, but because typescript's server is built upon LSP, you get more than just type checking - you also get access to all of the refactoring and code fix tooling that typescript builds. The IDE plugin you install will only do the job of starting and running a typescript server, and the server itself does the rest and tells the IDE about all of the features.