Yarn Workspace + ReasonML: How to get bucklescript to resolve hoisted node modules?

#1

Hi all,

I’m trying to setup a monorepo using yarn workspaces with multiple reason projects. I’d like to make use of yarn’s node_modules hoisting feature.

So far my structure looks like this:

packages/
  - app-one/
    ...
    - package.json
    - bsconfig.json
  - ui-components/
    ...
    - package.json
    - bs-config.json

app-one/bsconfig.json declares bs-dependencies as follows:

  bs-dependencies": ["bs-css", "reason-react"]

These dependencies are also listed in <root>/packages/app-one/package.json

Due to yarn’s dependency hoisting, when I run yarn install at root, bs-css and reasonreact get installed to <root>/node_modules

So when I run bsb -make-world, bsb can’t find bs-css or reason-react.

This makes sense to me since bsb is looking for those dependencies in <root>/packages/app-one/node_modules and doesn’t see /node_modules.

Is there anyway I can get bsb to recognize the hoisted dependencies? Or is there another way to setup this project to get things to build correctly?

#2

Hi Lewis, I’ve ran into a similar issue and here’s my solution for it:

  "workspaces": {
    "packages": [
      "packages/pkg1",
      "packages/pkg2",
      "packages/pkg3"
    ],
    "nohoist": [
      "pkg1/**"
    ]
  },

Put this block in your root package.json

#3

I see this option — but I was wondering if there is a way to get bucklescript to resolve packages from another directory other than {root}/node_modules. In this case I’m looking for {root}/../node_modules.

I think with the nohoist config on shared external dependencies like bs-css. I’d end up running into name collision warnings?

#4

Get bucklescript to resolve packages from another directory other than {root}/node_modules…

That’d be cool, I wonder if @bobzhang has any thoughts on that.

I think with the nohoist config on shared external dependencies like bs-css. I’d end up running into name collision warnings?

Short answer is yes. By specifying pkg/** is pretty heavy-handed, I’m pretty sure you can be specific and cherry-pick the few bs-* dependencies into the “nohoist” blob, but it is maintenance overhead nontheless.