You actually wrap the type annotations in comments and flow will recognize them. You can use the source with the type comments in your browser!
As an example, the flow checker will read the annotations from `function f(n/:number/, s/:string/) { ... }` but since they are commented in the source code your JS engine ignores them.
This is amazing for typing existing code, since at every step you are merely inserting comments into your code. And your existing minification step will strip them out :)
1. Setting up with Babel: (note that if you are already using the "react" preset you don't have to do anything)
$ npm install --save-dev babel-plugin-transform-flow-strip-types
{ plugins: ["transform-flow-strip-types"] }
$ npm install --save-dev eslint-plugin-flowtype-errors
{ plugins: ["flowtype-errors"] }
We're trying to integrate more with tools like this so you don't have to go changing your entire workflow. It shouldn't be so hard to add types to your existing JavaScript code.
EDIT:
Ah I think I get it, it's for editors that don't interface with Flow but only with eslint. Well, since WebStorm has Flow support - even though it's new and there are a few tickets open - I guess I should stick with the plugin that I already chose.
So I had enough and started with Flow on one file, then two - then I spent a week converting everything to Flow. I actually found a few subtle bugs in my code, but also two or three minor ones in Flow (issues submitted). I also found clear limits for this type system, for example, when you clearly know 100% sure that a value cannot be undefined but Flow insists you add a type check before using the property because it does not follow your dynamic logic, only its types.
If you target ES6 with TypeScript and only write ES6-compliant code (plus types), you won't get any downleveling of features, so your code will always be the same as you wrote it (other than the removal of types).
If you use TS-specific features like 'enum' or 'namespace', there will necessarily be some rewriting of your code to turn it into usable JS, but those features are entirely optional.
It is kind of annoying sometimes actually, in that typescript can't support niceties like operator overloading or extension methods because that would require de-sugaring.
Yes and no.
Typescript does a little bit of filling in the gaps of some missing features if the target platform does not support a feature you used. So your compiled code will still be ES6 (or ES5), but it may have some boilerplate added to polyfill for something if ES6 or ES5 (or others..) do not officially support it.
https://github.com/Microsoft/TypeScript/pull/12160/commits/7...
Looking at the discussion on GitHub for the issue that lead to this commit I'm a little amazed at how much difficulty some people seem to have had with the simple concept. "Just pass it through without code changes, only remove type information." Why does that lead to such convoluted discussions? Oh well, it's been done.
The downside of using `esnext` everywhere is that someone might be employing a feature that is not widely supported in the target browser/JS engine. So it's pretty bad to start with that as a default without an understanding of the consequences.
"no code changes" implies you could potentially be creating
something that doesn't run where you want it to.
I'll be more careful about writing "one" instead of "you" next time.
Is it possible to have a setup with TypeScript where it is guaranteed that no code changes occur other than removal of the type information?
I started using Flow, found what it can and can't do and would like to try TypeScript. But only if I can have "types-only", I don't want my code "translated" in any way. I'm writing for the latest node.js version and not for x different browsers, I want to use exactly what that version supports and have no code-changing steps.
With Flow I use flow-remove-types (https://github.com/leebyron/flow-remove-types) to remove the types. It leaves spaces where there was type-related code and doesn't touch the code itself.