Support PnP in order to use with Yarn 2

[kaushalyap]

Proposal

Getting rid of one of the blockers mentioned by @arcanis in here

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).

Use case

Using Flow with Yarn 2

Related:

• [Case Study] Flow yarnpkg/berry#634

[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. The React team has publicly stated that they have no immediate plans to support Yarn 2. There's a more thorough discussion here.

Edit: Note that the Twitter discussion linked contains members of both the React Native and React Core teams.

[kaushalyap]

Thanks for the info, I'll keep this open since they may want to support it in the future when Yarn 2 is stable

[gaearon]

To be clear, React itself has no opinions about PnP or Yarn 2. If it works for people, that's great. However, the React Native repository currently doesn't run with PnP, and we currently don't have plans to support that (because making a huge repository compatible is a lot of work).

[nicolo-ribaudo]

I think that a solution is to add two options: module.resolver and module.loader. They would contain a command used to launch a third-party script to resolve/load modules.
I don't think that this command should be run for every file since it would kill performance: it should be spawned in background once and it should communicate with the flow process.

The module.resolver script would take two inputs (the specifier used in require/import, and the path of the file which contains the import statement) and output a resolved path. module.loader would take as input the resolved path, and output the file contents.

---

EXAMPLE

Consider this project, in the /project/ directory.

// index.mjs
import start from "./server";

start();

// server.mjs
import * as log from "logger";

export default function () {
  log.blue("Started!");
}

// "logger" (stored somewhere by Yarn)

export function blue(msg) {
  console.log(msg);
}

This is what would happen:

[jedwards1211]

@AndrewPardoe if import maps ever get standardized, do you think Flow would want to support them? As far as I understand the import maps would be static files, so resolution code could be implemented in OCaml instead of spawning node processes to call custom loaders.

And @gaearon same question about react-native, do you think react-native team would want to support import maps?

If so then this would be a good argument in favor of standardizing import maps to add to that linked discussion.

[SamChou19815]

Closing for similar reason as #7014.