When I arrived at Inato, the codebase was written in ES6. Then, we added some robustness with Flow. It helped us perform major refactors and lower our bug count. We were happy… until problems showed up.

Problems we had with Flow

• Flow takes a lot of RAM and computing resources (we witnessed > 10 Go of RAM).
• The integration with text editors is not state-of-the-art. We could not find a way to make auto-completion and auto-imports work in VSCode.
• There is no official support for exporting type definitions from a module (this is painful when we split our code into different modules)
• For some npm packages, either typings are missing in flow-typed, or typings are incomplete / out of date. For instance formik and styled-components have poor flow definitions. This makes the code less safe.

Project-specific problems we had with Flow

• React typings are bound to Flow’s version. After we upgraded React to 16.8.4 in order to use hooks, we wrote some unsatisfying $FlowFixMe

• In thereact-relay library, the typing of createFragmentContainer is wrong, and breaks the type safety for numerous components. (see the GitHub issue)

Exploring alternatives to Flow

What are the other typed languages that compile to Javascript? Typescript and ReasonML seem to be the best candidates.

• ReasonML produces very safely typed code. The syntax is quite different from ES6 though, and the ecosystem looks young.
• Typescript is a great typed language with a large community. The ecosystem is mature and the syntax is similar to ES6. This is obviously the best choice for us.

How to migrate to Typescript

• If you use Flow, you probably use Babel. Upgrade to babel 7 to use the Typescript preset.
• Install typescript (yarn install typescript)
• Add a tsconfig.json file at the project root. Use"strict": false in the compiler options.
• Change the file extensions from .js to .ts (or .tsx if your project uses JSX). You can run this command to rename all files at once in the .ts extension:

find src -name "*.js" -exec sh -c 'mv "$0" "${0%.js}.ts"' {} \;

• Monitor the errors: yarn tsc --noEmit --watch. You will see a lot of syntax errors. You can fix most of them with a couple of regexes:

Search and replace:

{| ⇒ {
|} ⇒ }
import type ⇒ import
$ReadonlyArray ⇒ ReadonlyArray
$NonMaybeType ⇒ NonNullable

Regexes:

\+(\w+) ⇒ readonly $1
: \?(\w+<?\w*>?) ⇒ : $1 | null | undefined
<\?(\w+)> ⇒ <$1 | null | undefined>
\$PropertyType<(\w+), ('?\w+'?)> ⇒ $1[$2]

• After your syntax errors count has gone to 0, you will see a lot of new errors. These are type errors ! There is no generic way to fix them, handle them one by one (this is the longer part of the process).
• Update your babel config. It should look like this:

{
  "presets": ["@babel/env", "@babel/typescript"],
  "plugins": [
    "@babel/proposal-class-properties",
    "@babel/proposal-object-rest-spread"
  ]
}

• Update your linter. If you’re using ESLint, use @typescript-eslint
• Update your test suite. If you’re using Jest, use ts-jest

Is it worth it?

YES! Definitely!
We’ve eliminated almost all problems we had with Flow. We’re still having small issues with composite projects, but overall it’s a great improvement.

• The Typescript integration in VSCode is impressive: auto-imports and auto-complete work.
• We have no more inconvenient RAM usage.
• DefinitelyTyped contains a lot of typings and the quality of these typings is great overall. No more problems with react and react-relay typings.
• It’s easy to export type definitions => it encourages developers to split their code into smaller packages (which I think is a good practice)

It’s too soon to witness the impact on our productivity, so I measured the impact on the “Developper Happiness” among team members. I’m assuming that happy coding is correlated with less problems and higher productivity. Here are the results:

Conclusion

Flow is a great tool a lot of people are happy with. But it has some limitations when the codebase becomes big. If you’re experiencing the same problems as we did, I strongly recommend to migrate.

Migrating from Flow to Typescript: Why ? How ? Worth it ? was originally published in inato on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Inato, we organize our codebase by building several modules inside a “mono-repo” with yarn workspaces. Also, we always work on improving our developer experience, because we think that it leverages our team’s productivity.

In a previous article, I explained how to achieve cross-library hot-reloading for a front-end application.

Flow is one of the tools we use to maintain high code quality, and we rely on it to ship our code with confidence. However, flow does not support yarn workspaces yet, it’s designed to work with just a standard project (there’s an open issue here).

Here are the 2 main issues that we identified:

• 1: The type definitions of your dependencies are not detected by flow.
• 2: The type definitions are not detected when you import something from one module into another.

As frustrating as it could be, our temporary fix was to stub all these libraries with flow-typed:

It was obviously a big hole in our swiss cheese model, so we looked for solutions.

Why are dependencies’ type definitions not detected?

Flow doesn’t detect the type definitions of your dependencies when using yarn workspaces, because the packages are hoisted in the root package.

Basically, with this file architecture:

.
├── package.json
├── packages
│   └── app
│       ├── node_modules
│       └── src
│           └── index.js
│   
│       
└── node_modules

In the app module, flow will look for type definitions of the dependencies inside ./packages/app/node_modules but the packages are actually in ./node_modules .

How to use dependencies’ type definitions

The solution is to use a tool called flow-mono-cli.
It will fix the problem above by creating symlinks from ./packages/app/node_modules to ./node_modules.

To do so, just follow the documentation. Roughly:

• install flow-mono-cli at the top level
• run flow-mono create-symlinks

We fixed the first issue, let’s tackle the second one now !

Why are type definitions not detected when we import something from one module into another?

When a module is used by another module, we expose only the lib folder which contains the source code transformed by babel. Unfortunately, babel strips out all the type definitions, so the lib folder does not contain them.

.
├── package.json
└── packages
    ├── app
    │   ├── package.json
    │   └── src
    │       └── index.js
    └── ui
        ├── lib
        │   └── component.js // does not contains type definitions
        └── src
            └── component.js // contains type definitions

For instance, if we consider the above architecture, when you write import { Component } from 'ui/lib/component' in the app module,Component will not be correctly typed.

The solution to this problem is to export the type definitions in the lib folder, along with code transformed by babel.

How to export flow definitions

Exporting flow definitions in the lib folder is surprisingly easy!

What you need to do is copy your source files containing the flow definitions next to the transformed files in the lib folder, and rename them with a .flow extension.

.
├── package.json
└── packages
    ├── app
    │   ├── package.json
    │   └── src
    │       └── index.js
    └── ui
        ├── lib
        │   ├── component.js 
        │   └── component.js.flow // copy of src/component.js
        └── src
            └── component.js // contains type definitions

Now, when you write import { Component } from 'ui/lib/component', Component will be correctly typed.

In order to automate this copying process, I suggest that you use flow-copy-source. You can run flow-copy-source src/ lib/ or flow-copy-source src/ lib/ -w with the convenient watch option!

One last step: include your dependencies in your .flowconfig

When you change something in the ui module and babel/ flow-copy-source write new content in the lib folder, flow in the app folder may not understand that something changed at once.

In order to have a seamless experience, include your dependencies in the .flowconfig file of the app module:

[include]
../ui/lib/**/*.js.flow

Conclusion

We’ve put some effort at Inato to improve our developer experience with flow, and I hope that our learnings will help you as well :)

Taking a step back, I feel like flow is a great type-checker, but it lacks tooling and we have to use non-official tools like flow-mono-cli and flow-copy-source to get basic things done.
Also flow is quite slow sometimes, and we have to use small hacks like [include] in the .flowconfig to have a decent experience.

Considering typescript‘s bigger ecosystem, we currently wonder if migrating to typescript would be a rewarding investment. If you have experienced similar problems with typescript, please let me know!

How to use flow in a mono-repo was originally published in inato on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

At Inato, we are creating a product that includes several front-end applications. All these apps are located in a single mono-repo which we manage with yarn-workspaces, where each app is a javascript module.

For example, let’s imagine that we have 2 front-end modules, app and back-office. The file structure would look like this:

.
├── package.json
├── packages
│   ├── app
│   │   ├── package.json
│   │   └── src
│   │       └── index.js
│   │
│   └── back-office
│       ├── package.json
│       └── src
│           └── index.js
│       
└── yarn.lock

For each of these front-end app, we have a nice developer experience with hot-reloading, so we have a quick feedback when we design new components, especially when we write styles.

At some point, we discovered that some UI components were duplicated across different apps. So, we decided to refactor all these components into a new UI-dedicated module, enforcing code unicity and UI integrity:

.
├── package.json
├── packages
│   ├── app
│   │   ├── package.json
│   │   └── src
│   │       └── index.js
│   │   
│   ├── back-office
│   │   ├── package.json
│   │   └── src
│   │       └── index.js
│   │   
│   └── ui
│       ├── package.json
│       └── src
└── yarn.lock

In this article, I will explain how you can build the ui module while keeping a great hot-reloading experience.

How to build the module with hot-reloading

The standard way is to process and copy the source files into a lib folder. Using babel, a command like babel src --out-dir lib will do the trick.

Then,you can import your components in your app and back-office front-end modules with: import { SomeComponent } from 'ui/lib/SomeComponent'.

In order to build the files each time they are edited, you can add a “watch” option in the babel command :

babel src --out-dir lib -w

Now, when you change something in ui, the processed files are updated in lib, and hot-reloading is triggered in app and back-office!

The end

I hope you enjoyed this short article. If you have any question, just drop a comment below.

In my next article, I will explain how to export flow definitions from a javascript module.

Also, if you are curious about Inato activities, we are currently hiring software engineers! Check out the open positions: https://angel.co/inato/jobs.

How to write your own components library with hot-reloading, using yarn-workspaces and webpack was originally published in inato on Medium, where people are continuing the conversation by highlighting and responding to this story.