ReScript 12 Monorepo with Bun 1.3.x - Working Example

[joakin]

Hi @nojaf,

Following up on the forum discussion, I've created a working ReScript 12 monorepo example that demonstrates the current workarounds needed for Bun 1.3.x compatibility. You can find it here: https://github.com/joakin/rescript-bun-monorepo

Like I mentioned in the post, there are a couple of workarounds I implemented:

1. Bun Isolated Dependencies Fix

• I added workspace packages to root package.json dependencies to force symlinks in node_modules
• This allows ReScript's rewatch to find the packages since Bun 1.3.x uses isolated installs by default

2. Test Discovery Workaround

• I'm using .res.js suffix (as recommended in docs and the create-rescript-app thingy)
• I added explicit test scripts with glob patterns since Bun doesn't auto-discover .res.js test files and as far as I could see it is not configurable for now

test: bun test ./packages/*/src/**/*_test.res.js,
test:watch: bun test --watch ./packages/*/src/**/*_test.res.js

Before I submit this as an end-to-end test case, I'd appreciate your thoughts on:

1. Is that repo enough for you to make something useful in this one, or do you want me to submit it?
2. Should I keep the current .res.js suffix with the test script workaround, or switch to .js as you mentioned in the end-to-end repo? Not sure if I'm supposed to submit the default or the workaround fixed.
3. Is the workspace dependency approach acceptable for the end-to-end tests, or would you prefer a different solution (like configuring Bun with linker = "hoisted" in bunfig.toml)? Or leave it broken without the package.json dependencies on the packages/*?

What do you think?

[nojaf]

Hi @joakin, thanks for the sample. I'll try to take a close look this week. Much appreciated!

[nojaf]

Hello @joakin, I tried you approach in my own project and it worked for me.
I am, however, a bit puzzled about some thing you did in the package.json.
Looking at https://bun.com/docs/guides/install/workspaces#configuring-a-monorepo-using-workspaces you do seem to do things a bit differently than the guide says:

{
  "name": "rescript-bun-monorepo",
  "private": true,
// I had "workspaces": [ "package1", "package2" ] here, how did you know you can nest these options ?
// I'm have a toplevel catalog node, that also seems to be allowed.
  "workspaces": {
    "packages": [
      "packages/*"
    ],
    "catalog": {
      "rescript": "^12.0.0-rc.3",
      "rescript-bun": "^2"
    }
  },
  "scripts": {
    "build": "rescript build",
    "clean": "rescript clean",
    "dev": "rescript watch",
    "format": "rescript format",
    "test": "bun test ./packages/*/src/**/*_test.res.js",
    "test:watch": "bun test --watch./packages/*/src/**/*_test.res.js"
  },
// You add these here so that those packages become hoisted, right?
  "dependencies": {
    "@rescript-bun-monorepo/common": "workspace:*",
    "@rescript-bun-monorepo/app": "workspace:*"
  },
// The same thing here, because these exists, they are hoisted, which is what ReScript needs.
// Is there a link between them being both devDependencies and catalog?
  "devDependencies": {
    "rescript": "catalog:",
    "rescript-bun": "catalog:"
  },
  "packageManager": "bun@1.1.0"
}

Would love to understand how this works and update our docs as well.
Thanks for your feedback!

[joakin]

I believe I followed the advice from https://bun.com/docs/pm/catalogs

Indeed the dependencies on the monopo packages listed explicitly is so that they are actually hoisted.

For the dev dependencies I added rescript as dev because it's a devtool, and I don't want to use a global install, I rather have the project specify which version it uses. I added it to the top level because I use/invoke it in the top level with the scripts or cli. I didn't intentionally add it for it to be symlinked.

For rescript bun I'm not sure why I added it to the top level, I think it may have been because I wanted to add a scripts folder in the top level to run tasks for the monorepo like you have here, but I haven't gotten around to it yet.

No relation between dev dependencies and the catalog you can use catalog on both dependencies and dev dependencies.

For any deps that are going to be used across packages using the catalog sounds like a great idea, that's why I experimented with it.

[joakin]

I like the properties of isolated dependencies, in work projects I've had the issue where the code was depending on the package that was just installed transitively so it makes sense to me and it seems to make things faster.

But if it is so incompatible with the new build tool then it may be better to just recommend to use the hoisted linker avoid issues, instead of finagling to work around them.

[nojaf]

Interesting, it does seem like Bun doesn't have their doc story fully aligned.

I don't think the "devDependencies" at the root level is strictly required.
If you have "rescript-bun" as (dev)dependency of a package than it will be able to resolve it as well.

But if it is so incompatible with the new build tool then it may be better to just recommend to use the hoisted linker avoid issues, instead of finagling to work around them.

True, although I don't think it is that bad to set it up with isolated linker.
The key thing seems to be that we need a way to find local packages to map out the monorepo layout. And without having those local packages hoisted inside the toplevel node_modules folder we can't really piece this together. I think that is the essential part.

I added rescript as dev because it's a devtool, and I don't want to use a global install,

Yes and no, while the rescript tool is indeed a dev thing only, it also contains @rescript/runtime which is something you will end up needing in the browser for example. It does come with stuff you eventually use or bundle.

[joakin]

The key thing seems to be that we need a way to find local packages to map out the monorepo layout. And without having those local packages hoisted inside the toplevel node_modules folder we can't really piece this together. I think that is the essential part.

Indeed. If we could tell rewatch via rescript.json (or it would read package.json itself) the paths of packages, potentially with glob support, then it wouldn't need to rely on them being present in the node_modules folder.

Yes and no, while the rescript tool is indeed a dev thing only, it also contains @rescript/runtime which is something you will end up needing in the browser for example. It does come with stuff you eventually use or bundle.

Ah yes I forgot about that, you are right!

[nojaf]

Indeed. If we could tell rewatch via rescript.json (or it would read package.json itself) the paths of packages, potentially with glob support, then it wouldn't need to rely on them being present in the node_modules folder.

Maybe over time, if this becomes a widely adopted standard, we'll revisit it. For now we're not interested in adding more probing code to detect dependencies, especially if it targets a single package manager. The core team is still debating this, but there is an acceptable workaround. We'll add your sample to make sure it keeps working and update our documentation.