Setup with TurboRepo

Has anyone tried to create a project in TurboRepo for a Rescript App?

Im actually testing turborepo with my project, i’ll give you feedback during the weekend i think :wink:

1 Like

good luck! looking forward to hear from your testing

@jorge Hello, so i tested my Rescript project with turborepo, and the result is not really encouraging.

To summarize, you can use Turborepo or Nx with Rescript but you will loose the DX (Developer Experience) with VsCode (i did not tested with Sublime / Vim / etc, but it should be the same).

Let’s explain the previous statement:

  • The VsCode extension does not work well with monorepo if you need to work on your dependencies when working on your main project
  • The fact that pinned-dependencies are not handled by rescript build -w, is also a pain point. Because you have to do a “watcher” by your own means, and you loose the pretty output from the console, and the editor handling for displaying errors.

Finally, i decided to not use workspace nor monorepo solution. I use simple symbolic link if i need to develop several projects which shares libs & tools.
When those libs & tools are stable enough IMHO, i’ll publish thoses to npm public registry, and in local i’ll use verdaccio :wink:

Hope it helps

2 Likes

oh ok, thanks a lot for sharing!
I’ve seen that their GitHub repo is having a lot of constant releases so probably it’s not that stable yet.
I’ll check out verdaccio

Fwiw we’re running on Nx, and we just use a single bsconfig in the root. There’s really not much benefit to the mono repo build tooling when the build is <1s for a non trivial mono repo

3 Likes

I also tried monorepo with workspaces with yarn-plugin-rescript, but concurrent dependency builds sometimes cause problems. Sequential topological builds may fast enough in ReScript projects.

1 Like

do you have an example of the tree structure of your files?

do you have multiple package.json or just one next to bsconfig?

I use https://nx.dev to manage the repo. so I have a bsconfig.json and a package.json in my root then I have ./{apps,libs}/**/*.res.

It has three major drawbacks in my mind.

  1. the rescript build needs to be executed outside the regular build tool rescript build && nx affected:build.
  2. It also prevents us from using buildable libraries (because imports end up being relative and across projects).
  3. we have to manually namespace things.

So far we’ve found these drawbacks acceptable

1 Like