Your workflow with VSCode?

How do you cope with the OCaml integration within VSCode?

I mostly just run dune build . in the terminal and seldom use the errors highlighted by OCaml platform because either everything is red (because it couldn’t compile parts of the code) or errors don’t make sense compared to what I see in the terminal.

I also often restart the LSP client by reselecting my switch, which fixes artifacts.

I gave up on finding implementations or references, and mostly use the search.

What’s y’all workflow if you use vscode?

1 Like

I’m sorry to hear your problems! I’m just a user of the integration, but it works well for me. It pushes me to quickly address warning-level and unclosed-scope-level issues, which maybe is suboptimal but maybe not. Go-to-definition works well, even with library code it will often but not always show me the source. I often use dune build -w. I never needed to restart the LSP client so far.

Edited: I forgot to mention, I find this command useful: Terminal: Open Detected Link (I have it bound to a shortcut). Unfortunately, VS Code currently does not support detection of locations using File "...", lines A-B syntax; only File "...", line A works.

P.S. Shameless plug: Navi Parens structured navigation

1 Like

This smells strongly of a configuration problem or a lack of necessary opam packages in the active switch, or something along those lines.

I do always have dune build -w ... running in some form or another (because I’m running tests on save, or want my Dream server to restart after save, etc). The errors shown in buffers are always consistent with what is emitted by dune, though there are times where I need to change a buffer for it to “sync up” with the actual state of things.

Find-declaration works about 90% of the time if I’m leaving my project(s), but close to 100% otherwise. Typical failures involve symbols/references from the results of functor applications, or some oddball situations where an upstream package is still somehow carrying munged module names due to a build process detail.

1 Like

Quite well, IMO. The only bugs are that I have to dune build by hand and I have to resave files in VSCode by hand to get the latest feedback on them. I’m ok with that and still find OCaml to be extremely productive.

Mind blown. I’ve always done:

dune build ./bin/my_stupidly_long_project_name.exe

I don’t have to do anything like that.

I find completion extremely good for exploring APIs. For example, I just found a gamma function quickly and easily thanks to opam, dune, VSCode and the integration.

1 Like

You can do just dune build. Also, you can do dune install, which appears to be roughly equivalent to opam install . but I’m not sure. (My guess is that opam install ., once you have a version set, uses the state of the last git commit, while dune install uses current content.)

1 Like