arrowresearch/vscode-merlin

"Unknown error" when working in monorepo

Opened this issue · 12 comments

jchavarri commented

If there is a setup like:

project
|- package-a
|    |- bsconfig.json
|    |- package.json
|- package-b
|    |- bsconfig.json
|    |- package.json
|- package-c
     |- bsconfig.json
     |- package.json

and we call code . from project folder, the extension will crash with "Unknown error."

I created the smallest repro I could think of in https://github.com/jchavarri/bsb-smallest-monorepo-example:

git clone https://github.com/jchavarri/bsb-smallest-monorepo-example
cd bsb-smallest-monorepo-example
code .
wokalski commented

A promise is rejected (uncaught) with:

"The manifest file doesn't seem to contain `dependencies` or `devDependencies` property"

in Esy.re:193.

ManasJayanth commented
rusty-key commented

@prometheansacrifice @wokalski, I think it's part of the bigger problem, the extension is not able to run multiple instances depending on the folder structure.

Imagine having bsb-project in package-a, esy — in package-b and opam — in package-c

ManasJayanth commented

@rusty-key Fair point. But, I think this issue concerns itself with yarn managed bucklescript projects (correct me if I'm wrong @jchavarri )

If so, my plan was to ensure each of the workspaces were bucklescript 7+ and use ocaml 4.06 toolchain

ManasJayanth commented

Tangential point: It's time we retire the 4.02 toolchain for the now deprecated <7 bucklescript setups and put a hard requirement there. But the time the plugin will be public, I think most would have migrated

wokalski commented

@prometheansacrifice you might want to consider rebasing your changes on top of #11. It seems like the changes are interconnected. Does supporting yarn workspaces require anything more than using multiple folders in a workspace? In both cases (I think) a new client should be created if a file is in its own sandbox (as defined by closest package.json).

rusty-key commented

I guess the general approach should be something like: traverse folder structure up from the file in use and try to detect projects in each of them and create a new lsp instance for every unique one.

This will also help with opening single files or directories inside the project btw

wokalski commented

Edit: im stupid

rusty-key commented

@wokalski, not sure I understand. You cannot traverse down from file :)

If you mean traversing down from workspace, I think it could be a problem. First of all, there are cases like this one, when you have multiple projects. Secondly, even if there is one project, it's much harder to go down each path to find a project then wait for some file to be opened and then traverse up.

ManasJayanth commented

@jchavarri Let us know if this issue is blocking you. We'll try to get in a quickfix so that you can continue using the plugin

jchavarri commented

@prometheansacrifice no rush at all :) I'm helping to test this extension for now as I'm interested in using it at some point, but I can still use Jared's one for most of the work I do.

But, I think this issue concerns itself with yarn managed bucklescript projects (correct me if I'm wrong @jchavarri )

The main use case I have is for Ahrefs monorepo, which contains both BuckleScript and native projects under same folder. But if it's easier to start with just BuckleScript projects first for some reason, that'd be a huge improvement already!

jchavarri commented

Thanks for all the work y'all are putting on this extension btw! 💙

  • 👍1