jaredly / jaredly/reason-language-server
Allow configuring esy path
- Dominant language
- OCaml
- Stars
- 649
- Forks
- 85
- PR merge metrics
- No merged PRs in 30d
Description
Presently, `src/analyze/BuildSystem.re` (and maybe a few other places, I haven't checked too deeply) does not allow a configurable path to find `esy` and assumes that `esy` is in `$PATH` (or system equivalent) on launch.
This prevents a few different workflows:
* esy installed globally, but with a unique npm `prefix` set to a directory that's not in a default `$PATH` (This is what I'm seeing. It's installed in `~/.local/bin`, which I must push into `$PATH` by hand on OSX)
* esy installed globally without overriding `prefix`: This just means that `/usr/local` isn't in `$PATH`
* esy installed locally (and thus in `/node_modules/.bin`): This is also pretty common and works amazingly with direnv (but unless that shell also starts rls, we're in trouble.
I am, admittedly, blissfully unaware of how hard this would be. It looks like `BuildSystem.inferPackageManager` and `BuildSystem.detectFull` are the only two places that `Error("Couldn't get esy version")` is thrown, but I have no idea where those functions are used (or if there're any other non-qualified uses of `esy`)
Contributor guide
No contributing guide indexed for this repository
Research direction
Start in src/analyze/BuildSystem.re, especially BuildSystem.inferPackageManager and BuildSystem.detectFull, which the issue identifies as throwing the esy version error. Trace their callers and search for other unqualified esy lookups. Done means esy can be found through a configurable path for the global and project-local installation workflows described.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- ocaml
- Domain
- devtools
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100