Finding types from external dependencies when using Yarn workspaces

[TxHawks]

I'm running into an issue when using flow in a yarn workspaces enabled monorepo

After installing polished with yarn workspace workspace-name add polished I have a dependencies.polished entry in my workspace-name's package.json, and a polisheddirectory under the repository's root node_modules directory, as expected.

Having a file in the workspace directory with:

import {  rgba, } from 'polished';

Spits out:

import { rgba, } from 'polished';
                      ^^^^^^^^^^ polished. Required module not found

It all works just fine when run Flow from the root directory, to which node_modules directory Yarn installs all the different workspaces' dependencies into.

I'd expect Flow to look for type definitions in node_modules directories up the tree, in line with how npm and Yarn work.

Flow version : 0.57.2 node version: 8.4.0 Yarn verson: 1.2.1

[taion]

We're hitting this too. It looks like Lerna is tracking this issue as well on https://github.com/lerna/lerna/issues/891.

[n1ru4l]

This is confusing. It worked for me all the time, but somehow today it stopped working and I can not comprehend what I changed.

Edit Lol it was me adding the dist folder of my packages to ignore section inside my .flowconfig.

How it works

The build process of my packages creates a.js.flow file which gets copied to dist. (You will have to rebuilt it every time after making changes). Also my package.json main field points to the dist folder. I am using yarn workspaces backed by lerna

[ajhyndman]

It does seem like the obvious solution here would be for flow to adopt the node module resolution algorithm.

[langri-sha]

Has anyone managed to get this working? I'm trying to use module.system.node.resolve_dirname to no avail 🤕!

[ajhyndman]

Is there any chance someone could point me in the right direction, and I can try to open a PR?

[Inkdpixels]

@TxHawks @ajhyndman @langri-sha @taion @n1ru4l FYI there is a CLI called flow-mono-cli which solves most of the issues when working with flow in a mono-repo. Check it out, if you have any additional feature requests or feedback I am more than happy to hear from you guys! :)

[goodhoko]

Until yarn workspaces get supported by Flow there's an workaround: use yarn's nohoist option to stop yarn from hoisting dependencies of workspaces that use flow.

Eg. if you have a monorepo like

package.json
packages
|- A
|- B

where workspace A uses Flow, you can put this into your root package.json

"workspaces": {
    "nohoist": [
        "A/**"
    ]
}

Which will make yarn keep all A's deps in packages/A/node_modules where they can be found by Flow.

Note that this somehow contradicts the motivation behind workspaces. The nohoist post linked above explains:

A word of caution

While nohoist is useful, it does come with drawbacks. The most obvious one is the nohoist modules could be duplicated in multiple locations, denying the benefit of hoisting mentioned above. Therefore, we recommend to keep nohoist scope as small and explicit as possible in your project.