Normally when I do JavaScript development I leverage TypeScript, its been my goto for a few years now. But for a new project at work we are deciding to forgo Typescript and leverage pure JavaScript. As we are going to focus on using ES6 this is not a problem as much of the Typescript syntax is now available in ES6 (thanks to Babel we can transpile to ES5). But one thing that is not available is typing which sucks cause, having a type checker can really help developers avoid errors.

After much discussion we decided this is a great opportunity to play with Flow, which is a static type checker for JavaScript. The rest of this article will focus on getting flow running and VSCode validating your JS with type safety.

Let’s add Babel & Flow

Babel makes everything so nice, allows me to use the ES6 syntax in Node (v7.x has most of it but there are a few things). For Flow, it is recommended you install the following packages as dev dependencies:

babel-cli babel-preset-flow flow-remove-types

The last one can be confusing since their install docs do not call it out explicitly. In addition, you will want to add:

babel-preset-env flow-bin

Probably the trickiest thing for me was wrapping my head around flow-bin since it was not immediately clear. It basically allows you to have Flow locally in the project, which is the recommended approach over a global install.

Now, we need to update the package.json so that we can build using babel which will remove our type annotations. The command is simply:

babel src/ -d dist/

I am assuming here that all source files are in a directory called src and the transpiled final version will go into dist.

The final thing is to create the .babelrc file with the follow contents:

{
    "presets": ["flow", "env"]
}

These presets will strip out type annotations (since they are not valid JavaScript) and transpile our ES6 code into ES5 which is recognized by Node.

Integrating Flow

The absolute first thing you need to do is run the initialization script to create the default config file (.flowconfig) recognized by Flow.

yarn run flow init

You can leave this file be for the most part, wont be modifying it here.

Here is the code I wrote with flow:

/* @flow */

export default class Calc {
    static add(num1: number, num2: number): number {
        return num1 + num2;
    };

    static sub(num1: number, num2: number): number {
        return num1 - num2;
    };

    static mult(num1: number, num2: number): number {
        return num1 * num2;
    };

    static div(num1: number, num2: number): number {
        return num1 / num2;
    };
}

Its very simple and effectively creates a library of mathematical functions. Next, use this script as your index.js, I have included a couple type errors for flow to catch.

/* @flow */

import calc from './lib/calc';

console.log(calc.add("5", 6));
console.log(calc.sub(5, 6));
console.log(calc.mult(30, "20"));
console.log(calc.div(40, 20));

To run the follow command use yarn (or npm):

yarn run flow

You will need to invoke yarn (or npm) since, I assume, you used flow-bin package which means your Flow is packaged inside your project.

Against the code above, flow should pick out the two cases where a string was passed and the error is similar to what you would receive in a language like C# if you made the same error.

Add Some Scripts

The thing, as I said, about Flow code is its not JavaScript and so if you run it straight it will fail every time. The Flow preset from Babel stripes out the type annotations when building to leave valid JavaScript. Since this is the case, we should define an NPM script that we can run each time. Open package.json and add the following line to your scripts section.

“build”: “flow && babel src/ -d dist”

This command does two things:

1) it tells Flow to check the files with the @flow annotation for errors – if it finds any the process will fail.

2) it runs the code through Babel to both strip out type annotations (for all files under src/) and transpiles to ES5.

To execute this simply do

yarn build

or

npm run build

If you then examine the files under dist/ you will see a stark difference from the code you wrote; this is the power of Babel.

Let’s Configure VSCode

Ok, so at this point we can run everything from the command line, we get type checking and its all good, right? Well no. VSCode is probably going nuts because its still trying to parse the code in your .js files like its pure Javascript. We need to make it aware of Flow. Turns out, that is pretty easy.

Click the “Extensions” icon on the left hand navigation column and search for ‘Flow’. One of the items that will come up is Flow Language Support (below).

After installing you will notice the errors are still present. But why? Well, its because VSCode (correctly) assumes you are still working with pure JavaScript, we need to disable this. But because Flow is not a global part of our environment (and shouldnt be) we dont want to change settings for the editor, we want to do it for our workspace.

To do this, you need a settings.json file. Best way to create that is to indicate you want to override the default language settings.  First, click your current language from the lower right portion of the application status bar (below).

This will bring up a menu where you need to select to configure the language based settings for JavaScript (might also want to do this for JSX if you are using React and any other derivative JavaScript extensions).

This bring you into the settings.json file editor (it is a special file after all). From the right hand side of the top bar select ‘Workspace Settings‘.

You are now in your local settings.json file. Here is the absolute minimum that I recommend to support Flow.

flow.useNPMPackagedFlow just tells the extension to look in node_modules for the flow binary.

Basically, we are disable the internal JavaScript validator in favor of the Flow one. I do have a sidebar on this below since I believe you need to be aware of what this means. But regardless, after doing this, Visual Studio should cease seeing Flow type annotations as JavaScript errors. Congrats. That is it.

My Sidebar

I generally recommend that developers exclude .vscode from source control. However, there is an obvious problem in this case – without the settings.json file code will appear broken in VSCode for developers that dont have the right settings.

This goes one step further when everyone is using different editors (in our case we expect VSCode, Sublime, and WebStorm to be in play). Its not a huge deal really, you just need to make sure you communicate the usage of this library; I would really hate writing the type annotations just to get red squiggles all over my code, even though its valid.

So the point here is communicate and make sure that everyone can use Flow effectively. Its a great tool, but not something a single developer can use without the rest of the team, I feel, at least not easily or naturally.