[Case Study] Flow

[lhorie]

What package is covered by this investigations?

flow-bin

Describe the goal of the investigation

It should be possible to use flow in a codebase.

Investigation report

I've put together a small repo demonstrating that flow doesn't work with yarn v2: https://github.com/lhorie/flow-berry

# repro steps
git clone git@github.com:lhorie/flow-berry.git
cd flow-berry
yarn
yarn flow

Produces this error:

internal/child_process.js:366
    throw errnoException(err, 'spawn');
    ^

Error: spawn ENOTDIR
    at ChildProcess.spawn (internal/child_process.js:366:11)
    at spawn (child_process.js:551:9)
    at Object.<anonymous> (/Users/lhorie/Documents/flow-berry/.yarn/cache/flow-bin-npm-0.114.0-2e7dec7caf-1.zip/node_modules/flow-bin/cli.js:14:3)
    at Module._compile (internal/modules/cjs/loader.js:776:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:787:10)
    at Module.load (internal/modules/cjs/loader.js:653:32)
    at Function.external_module_default.a._load (/Users/lhorie/Documents/flow-berry/.pnp.js:7963:14)
    at Function.Module.runMain (internal/modules/cjs/loader.js:829:12)
    at startup (internal/bootstrap/node.js:283:19)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:622:3)

I've also tried suggestions from this thread, but without success.

Flow works w/ yarn 1.x and npm

[arcanis]

This will be difficult (and I won't implement it).

Two blockers:

• Flow is written in OCaml. This means that we cannot mount the zip file system on top of fs. Because of that, Flow has to have native support for zip archives. I pushed for it when I was at FB but it never happened, so I don't expect it to change anytime soon.

• FB doesn't use PnP at the moment as they hit integration issues with their Buck setup, and noone really dared to confront it. As an unfortunate side effect, Flow silently removed support for the custom resolvers a few months ago (in 0.110, apparently).

On the other hand TypeScript is written in JS, so even if they don't support PnP natively (yet, but we're working with them to find an appropriate way that satisfies both sides) we can implement it through PnPify, which simulates a n_m folder.

I realize it's not the answer you hoped for, and I'm really sorry not to have better news in this regard ...

---

One last thing of interest is that @larixer is working on implementing a n_m linker for Yarn 2 (you can follow the development in #470). This will allow your projects to keep using node_modules until you're ready to migrate to PnP. Unfortunately this also means that you won't benefit from the PnP perf, stability improvements, and some features, but ... tradeoffs tradeoffs. At least you'll get the rest of the CLI improvements, and will be able to use the Yarn plugin interface etc.

[kaushalyap]

I also need this in order to move to Yarn 2, any workarounds?

[arcanis]

The only one is to use the node_modules linker until Flow implements PnP support (if ever):

.yarnrc.yml

nodeLinker: node-modules

[AndrewPardoe]

The Flow team has no plans to adopt support for Yarn 2 or PNP. The primary use case for Flow at Facebook is in support of React code. Christoph Nakazawa of the React Native team has publicly stated that they have no immediate plans to support Yarn 2. There's a more thorough discussion here. Dan Abramov, from the React Core team, concurred, "We’re still using 1.x at FB and there are no immediate plans to switch to 2.x as that would be a ton of work."

@arcanis, I've edited my comment to be more precise. Feel free to reach out to me directly in the future.

[sberney]

As an unfortunate side effect, Flow silently removed support for the custom resolvers a few months ago (in 0.110, apparently).

Is not at all expected. It took me a long time to hunt down this not-really-a-solution; especially since I came across a few examples of using custom resolvers (which didn't work). It might be useful to have a prominently featured partial list of common tools that don't work with yarn 2.

Please make it all work together!

[arcanis]

Yep, that's a good idea - we have a compatibility table, PRs welcome to track tools that are still missing (I'll open one for Flow and React Native myself).

[ylemkimon]

I'm not sure why, but I'm unable to reproduce the issue. Flow still cannot resolve any dependencies, but without dependencies, it's working fine.

[ylemkimon]

It seems the original issue, Error: spawn ENOTDIR, is fixed in @yarnpkg/cli/2.0.0-rc.28.

[merceyz]

It seems the original issue, Error: spawn ENOTDIR, is fixed in @yarnpkg/cli/2.0.0-rc.28.

@ylemkimon That would be because Yarn started automatically unplugging dependencies with specific file types in #853 and #912

[b-jsshapiro]

Eleven months is kind of a long time. Any hope of a resolution on this? What still needs to be done?

[nicolo-ribaudo]

You can help convincing the Flow team to allow using custom resolvers: facebook/flow#8292, facebook/flow#7014

[psychobolt]

Had to create a separate sub yarn project to manage my flow dependencies:

https://github.com/psychobolt/react-pie-menu/tree/master/shared/flow-deps

and symlink-dir the path to the root.

[options]
module.system.node.resolve_dirname=flow-deps-modules

Not sure if ideally long term as I plan to switch to full Zero-Install completely. Works for me as I can easily opt-in to node_modules and install libraries that ship and support .flow files along with sources. For other libraries, I either stub or install their flow types. Maybe feature it for flow-mono-cli to manage flow workspaces.

[edoardo-bluframe]

We use Yarn Berry and PNP in a lot of projects where we also use Flow!

Solution - a little cumbersome but works:

• Have a root flow-typed folder
• Every package has a symlink flow-typed => ../flow-typed
• Use flow-typed to install as many types as we can
• Maintain the ones that aren't available in flow-typed by hand
• Yeah. Literally. Maintain the types for the other packages by hand

It takes awhile but once we have them we have them - and they work!

As let's face it - flow isn't gonna support Yarn Berry probably ever

Right?