You don't lose it. You use type checking like a linter, to highlight issues as you type.
If you also want to use it as an enforcer, you set it up as a pre-commit hook or a CI step or whatever you want.
The idea is not to be forced to typecheck on every little incremental build during development. Sometimes I _know_ what needs to be done to get typechecking to pass (I can see the type errors highlighted in my editor after all) but I don't want to have to fix it before running my code to see how it behaves, because maybe I'm just playing around with an idea.
There are pros and cons to typechecking and not typechecking, which is why both kinds of language exist. Annotation-
stripping lets you get the best of both worlds.
Babel makes it possible to do compilation that TS doesn't do. E.g., you can use esnext language features that TS doesn't support, like do expressions. You can also use babel plugins that add utility, like the Babel power-assert plugin.
The only counter-example that I know of is that async/await were initially only supported when transpiling to ES6, but this is not true since at least 2.2 (https://github.com/Microsoft/TypeScript/issues/5210).
One of the common pattern I use when developing with TS is: Change a type definition, look for red squiggles in the current file and fix them then save and build.
The error log shows me the rest of the files that need fixing.
It's fairly common practice with Flow to run type-checks as a part of the build or test step in a standard build/test/deploy workflow in CI, which largely removes the possibility of bad merges arising from type errors. With TypeScript, using the TypeScript compiler, type-checking would simply happen in lockstep with your build step, whereas with the new Babel preset and a separate type-check process, you still have the option of running them in lockstep as 2 separate commands, but you also have the option of running them as separate jobs in parallel, likely leading to significantly shorter build times. It's definitely going to be a huge net improvement to my own workflow, but you're certainly free to stay with the status quo if you feel it suits you better.
If you also want to use it as an enforcer, you set it up as a pre-commit hook or a CI step or whatever you want.
The idea is not to be forced to typecheck on every little incremental build during development. Sometimes I _know_ what needs to be done to get typechecking to pass (I can see the type errors highlighted in my editor after all) but I don't want to have to fix it before running my code to see how it behaves, because maybe I'm just playing around with an idea.
There are pros and cons to typechecking and not typechecking, which is why both kinds of language exist. Annotation- stripping lets you get the best of both worlds.