3 ms·

With flow you can do one better: type comments! https://flowtype.org/blog/2015/02/20/Flow-Comments.html https://flowtype.org/blog/2015/02/20/Flow-Comments.html

With flow you can do one better: type comments! https://flowtype.org/blog/2015/02/20/Flow-Comments.html https://flowtype.org/blog/2015/02/20/Flow-Comments.html 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 :)

Noseshine 10y ago
I figured if I start using Flow I may as well go all the way. My previous setup was to have JSDoc and Closure compiler style (inline) type annotations everywhere. The IDE - WebStorm - picked up on that. I filed tons of tickets with Jetbrains and got more and more issues resolved over time, but with the latest Webstorm there were some regressions and it seemed like they had difficulties with all of this. For example, I kept getting suggestions for properties picked up in clearly impossible places, autocompletion for the JSDoc types stopped working lately, etc. 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.
thejameskyle 10y ago
Comments is definitely the easiest way to get doing. But also if you're already using Babel and ESLint, you can add Flow in very few steps: 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 Then update your `.babelrc`: { plugins: ["transform-flow-strip-types"] } 2. Setting up with ESLint $ npm install --save-dev eslint-plugin-flowtype-errors Then update your `.eslintrc`: { plugins: ["flowtype-errors"] } Then just install `flow-bin` and create an empty `.flowconfig` file in the root of your repo and you're done. Now you have Babel compiling your code the same as always and you can use the Flow type syntax, and with ESLint you probably already have your editor all setup to show you warnings. 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.
- Noseshine 10y ago
  For eslint I'm using plugin "flowtype", and under "extends" I have "plugin:flowtype/recommended". Do you happen to know what's different compared to the eslint-flow package you mention? I took the first one I could find, didn't want to spend hours with the eslint part of using Flow since I was busy with all the errors reported by Flow during the conversion process. 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.

Noseshine 10y ago

I figured if I start using Flow I may as well go all the way. My previous setup was to have JSDoc and Closure compiler style (inline) type annotations everywhere. The IDE - WebStorm - picked up on that. I filed tons of tickets with Jetbrains and got more and more issues resolved over time, but with the latest Webstorm there were some regressions and it seemed like they had difficulties with all of this. For example, I kept getting suggestions for properties picked up in clearly impossible places, autocompletion for the JSDoc types stopped working lately, etc. 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.

thejameskyle 10y ago

Comments is definitely the easiest way to get doing. But also if you're already using Babel and ESLint, you can add Flow in very few steps: 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 Then update your `.babelrc`: { plugins: ["transform-flow-strip-types"] } 2. Setting up with ESLint $ npm install --save-dev eslint-plugin-flowtype-errors Then update your `.eslintrc`: { plugins: ["flowtype-errors"] } Then just install `flow-bin` and create an empty `.flowconfig` file in the root of your repo and you're done. Now you have Babel compiling your code the same as always and you can use the Flow type syntax, and with ESLint you probably already have your editor all setup to show you warnings. 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.

Noseshine 10y ago
For eslint I'm using plugin "flowtype", and under "extends" I have "plugin:flowtype/recommended". Do you happen to know what's different compared to the eslint-flow package you mention? I took the first one I could find, didn't want to spend hours with the eslint part of using Flow since I was busy with all the errors reported by Flow during the conversion process. 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.