Finding types from external dependencies when using Yarn workspaces
TxHawks opened this issue ยท 7 comments
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 polished
directory 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
We're hitting this too. It looks like Lerna is tracking this issue as well on lerna/lerna#891.
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
It does seem like the obvious solution here would be for flow to adopt the node module resolution algorithm.
Has anyone managed to get this working? I'm trying to use module.system.node.resolve_dirname
to no avail ๐ค!
Is there any chance someone could point me in the right direction, and I can try to open a PR?
@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! :)
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.