Getting merlin to work with esy and VS Code?

Ecosystem
1

I’m really excited about esy because it handles dependencies exactly the way I want (global cache, project-specific deps, built-in pinning, ability to easily package up all dependencies with the source), but the one thing I can’t get working in Merlin integration with Visual Studio code.

I was able to get dune to generate the .merlin files by setting esy.buildsInSource = "_build" (had to create an entire package.json since esy won’t let me set that in .opam right now), but the Visual Studio Code integration isn’t picking up any of the libraries. It’s possible this has something to do with needing a custom OCAMLPATH but I have no idea how to set that up in my editor (especially on a per-project basis).

Has anyone got this to work?

2

I think that opening VS Code with esy code . should do the trick, i.e. VS Code will inherit the environment set up by Esy. Also do make sure that you have @opam/merlin in your devDependencies.

In any case I’m CCing @andreypopp who knows a lot more than I do :slight_smile:

3

You should be able to develop opam projects with package.json like this:

{
  "source": "./my.opam",
  "override": {
    "buildsInSource": "unsafe",
    "devDependencies": {"@opam/merlin": "*"}
  }
}

That way you won’t duplicate info between package.json and *.opam files but it still allows you to customise esy configuration for the package.

As for VS Code plugin — can you provide more details which VS Code plugin you are using (there are multiple exist). But the main ones: vscode-reason & vscode-reasonml should work out of the box.

You certainly don’t need to set OCAMLPATH or similar, this is managed by esy/dune automatically for you. Check with:

% esy env | grep OCAMLPATH
3 Likes
4

This is required, yes, my package.json shows how to add that to opam metadata.

1 Like
5

Ah nice, adding this package.json did it:

{
  "source": "./reader_server.opam",
  "override": {
    "buildsInSource": "_build",
    "devDependencies": {
      "@opam/merlin": "*"
    }
  }
}

Thanks a lot!

1 Like
6

Great! You don’t need buildsInSource: _build though. It’s going away soon, set it to "unsafe" for opam project and leave unspecified for esy projects. This setting controls how esy guards project’s source tree from built artifacts — in case of opam project we just turn this off.

7

One more question: Is there a way to specify opam deps in git without needing a package.json in the remote repo? For example, if I wanted to pin cohttp-async to the git repo. Even if I could convince upstream to add a package.json, there are several .opam files in that repo and having just one package.json wouldn’t be very helpful.

EDIT: Oh I see that this can be done using “resolutions”. I’ll try that.

8

Yeah, it’s possible.

See https://esy.sh/docs/en/using-repo-sources-workflow.html#with-opam-packages

Copying the example from there:

"dependencies": {
  "@opam/lwt": "*",
  "@opam/lwt_ppx": "*"
},
"resolutions": {
  "@opam/lwt": "ocsigen/lwt:lwt.opam#abc342",
  "@opam/lwt_ppx": "ocsigen/lwt:lwt_ppx.opam#abc342",
}

If repo contains multiple opam files and you need all of them you need to specify each one individually now though.

2 Likes
9

Thanks for all the help! I have all of the project I wanted to use working with it now :slight_smile:

1 Like