"Unknown error" when working in monorepo

[jchavarri]

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]

A promise is rejected (uncaught) with:

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

in Esy.re:193.

[ManasJayanth]

Thanks for looking into this. I'm on it. Yarn workspaces is a new setup - working on a refactor. Will get to this right after that. The error message seen from the wrong assumption that root manifest files always contain the dependencies - since yarn workspaces wasn't supported then The rejig should help us support more setups (lerna? reason-native monorepo?)

…

On Wed 22 Jan, 2020, 11:55 PM Wojtek Czekalski, ***@***.***> wrote: A promise is rejected (uncaught) with: "The manifest file doesn't seem to contain `dependencies` or `devDependencies` property" in Esy.re:193. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#29?email_source=notifications&email_token=AAXUDOQB2X2VYNWECPDHD3DQ7CFRJA5CNFSM4KKCFMM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJUTKKY#issuecomment-577320235>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXUDORLIOWXOS7RT5C4HFDQ7CFRJANCNFSM4KKCFMMQ> .

[rusty-key]

@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]

@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]

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]

@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]

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]

Edit: im stupid

[rusty-key]

@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]

@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]

@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]

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