Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Finding types from external dependencies when using Yarn workspaces #5107

Open
TxHawks opened this issue Oct 14, 2017 · 7 comments
Open

Finding types from external dependencies when using Yarn workspaces #5107

TxHawks opened this issue Oct 14, 2017 · 7 comments

Comments

@TxHawks
Copy link

TxHawks commented Oct 14, 2017

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
Copy link

taion commented Oct 19, 2017

We're hitting this too. It looks like Lerna is tracking this issue as well on lerna/lerna#891.

@n1ru4l
Copy link

n1ru4l commented Oct 19, 2017

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
Copy link

ajhyndman commented Oct 21, 2017

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

ajhyndman added a commit to ajhyndman/fire-emblem-working-title that referenced this issue Oct 21, 2017
This isn't really ideal, but is a workaround for flow not having access to parent node_modules directories (for now).

See also:

facebook/flow#5107
@langri-sha
Copy link

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

@ajhyndman
Copy link

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

chmanie pushed a commit to JoinColony/colonyJS that referenced this issue Nov 28, 2017
@Inkdpixels
Copy link

@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
Copy link

goodhoko commented Jun 18, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants