PnP and Flow resolution

[goodmind]

We had this discussion in yarnpkg/website#869 (comment)

Let's track it here

Do you want to request a feature or report a bug? Bug

What is the current behavior?

Cannot resolve module
/Users/goodmind/Library/Caches/Yarn/v4/npm-react-16.7.0-b674ec396b0a5715873b350446f7ea0802ab6381/node_modules/react/inde
x.js.

     1│ //@flow
     2│
     3│ import * as React from 'react'
     4│ import styled from 'styled-components'
     5│ import {Tag} from '@blueprintjs/core'
     6│ import type {Scope as ScopeType} from '../service'

If the current behavior is a bug, please provide the steps to reproduce.

https://github.com/goodmind/pnp-flow-resolving

What is the expected behavior? Resolving packages

Please mention your node.js, yarn and operating system version.

node v11.7.0
yarn v1.13.0
macOS High Sierra 10.13.6

[goodmind]

It only works if I manually add this path to [include] section of .flowconfig

[arcanis]

Oh I see! Yes, sorry I didn't think about mentioning it, but the cache folder must (by design) be included in the Flow-covered paths indeed (ie the [include] section, as you mentioned). My bad!

Does that make sense?

[goodmind]

@arcanis, it doesn't, should I add all packages manually?
What if I reset cache? What to do on another computer?

[langri-sha]

Maybe a .yarnrc in the project directory could work. yarn config current shows absolute paths, but perhaps we can use relative paths when configuring.

[alexkrolick]

Which paths need to be added? This is still erroring for me.

.flowconfig

[include]
.pnp

[meatwallace]

didn't spend much time on it but to get everything working running flow via a package.json script, i used the following setup:

.pnp.sh - ensure to make executable via chmod +x ./.pnp.sh:

#!bin/sh

NODE_OPTIONS='' node ./.pnp.js

.yarnrc:

cache-folder ".yarn-cache"

.flowconfig:

[include]
.yarn-cache
; ...other directories

[options]
module.resolver=<PROJECT_ROOT>/.pnp.sh
module.system=haste

package.json:

  "scripts": {
    "run-flow-as-a-script": "flow"
  },
  ...

@arcanis - is all of this required / the recommended way to get things working / recommended workflow in the current state?

[goodmind]

This doesn't make sense, would cache live in project folder? Then what the difference with node_modules?

[meatwallace]

@goodmind - i'm far from an authority on this so it would be good if someone can confirm or advise, but my conclusion:

yes, this config puts yarn's cache in the project folder - this doesn't seem ideal to me either, but if flow requires your cache is included by design, then i'm not sure you would want to use your global cache. in dev, if you're working on other projects/use global modules etc, then flow will potentially include unrelated code. i think this would still occur (likely slower) using a project-specific cache if you never cleaned it, unless yarn prunes it (?)

in CI, you've lost your cache anyway unless you're explicitly preserving it, and in that case the location becomes irrelevant as you can persist and remount it however you choose.

i don't know PnP intimately enough to list all the benefits, but unless you're blowing your cache away all the time, you should see a speed up as you're minimizing disk I/O with a warm cache. if rebuilding your cache is time intensive, then you could look into setting up yarn's offline package mirror to minimize network I/O.

[paul-soporan]

Closing as Flow PnP support is tracked in yarnpkg/berry#634.