Feature idea: better workflow for watch-mode and promotions

[yminsky]

Playing a bit with the vscode plugin, I started thinking about things I miss from Jane Street's tooling. Here's a common workflow:

• Start a polling build, which in Dune, is turned on with -w, typically targeting the equivalent of @all @runtest @fmt
• Then, when an error pops up, go to it via next-error
• If it's an expect-test or cram failure, hit a key to display the diff.
• Depending on what the diff looks like, hit a different key to accept the promotions, just for the file in question.

It would be great to have this workflow available in vscode as well.

[avsm]

Do you ever need to customise the targets? I.e. do you really want runtest going in polling mode?

I was thinking that for polling mode, something incremental could be useful -- run a fast dune build @check continuously, and then when that goes quiet (i.e. the typing stops), run a dune build @install and then the tests.

[yminsky]

That's a good question. The ordinary thing is to set up some build targets, and mostly just leave them there as you go.

But there is an easy workflow for dynamically changing what's built. We have a special start file that contains the current targets that are being built, and we have some keyboard shortcuts for extending that list. So, I can hit a few keys and add all tests for the given directory, or add the target for building a native-code executable, or a target for building the javascript executables.

There's also a neat trick that looks at the PR you're on, and initializes the start file with the default targets on all directories that are changed by that PR. This is great for code review purposes, since it ensures that you get build artifacts for everything you are going to look at.

All that said, I think changing the targets is rare enough that it would be fine to have a workflow where you could adjust the set of targets and restart the build when you needed to.

[rgrinberg]

The features here require deep integration with dune. I'm sketching out a plan on how to improve dune on this front: https://github.com/ocaml/dune/issues/3517

[rgrinberg]

A full year later, I can offer a progress update on this issue. A workflow resembling this issue will be possible with dune 3.0 and a subsequent release of ocamllsp.

Obviously we'd like to implement the efficient workflow described in this ticket, but we must strike a balance between what using the LSP protocol to provide editor agnostic functionality versus vscode specific functionality. I have the following split in mind. First, the following will be available to all LSP clients

• Running dune (with or without watch mode) will populate the diagnostics window with build errors.
• For every build error that may be resolved with a promotion, the LSP server will offer a code action to promote.

Since the LSP protocol is unaware of diffing, we'll need to implement a vscode specific command to display the diff. To make this possible, we need to make vscode aware that some diagnostics correspond to diffs. The data field should be useful to make this happen.

Key bindings will obviously need to be to be vscode specific. I'm thinking that we can create two bindings for diffing and promotion. Both of these commands could offer a menu to select which file to promote/diff.

[smorimoto]

Is this already solvable with dune 3.0?