Prevent the "Start a build for this project to get the freshest data?" notification from spamming

[banacorn]

It pops up every time when a file is opened.
I don't even know what this notification means.

There should be an option for disabling this notification (in fact, every notification)
This is just annoying.

[banacorn]

It seems like the notification would appear only when the .bsb.lock is missing.

rescript-vscode/server/src/server.ts

Lines 144 to 147 in 9bbacb4

	// check if .bsb.lock is still there. If not, start a bsb -w ourselves
	// because otherwise the diagnostics info we'll display might be stale
	let bsbLockPath = path.join(projectRootPath, c.bsbLock);
	if (firstOpenFileOfProject && !fs.existsSync(bsbLockPath)) {

The notification becomes spammy if .bsb.lock is too short-lived.
Sometimes my .bsb.lock would keep getting deleted, but I don't know who did it.

[alex35mil]

IIRC .bsb.lock gets created/delete by compiler. As long as some bsb process is watching, .bsb.lock exists.

Sometimes my .bsb.lock would keep getting deleted, but I don't know who did it.

It might happen when you rebuild project often.

[chenglou]

It should only pop up for the first file of a project you open? Is that not the case for you? Got a video?

[banacorn]

Unfortunately I can't seem to reproduce it.

It happened after I converted everything from ReasonML to ReScript.
The problem only occurred in the first few hours, but I'm not sure what I did to stop it from spamming.

@Arafatamin, @thezjy, @mickeyvip, @BlueHotDog, @darenju, @kgtkr, @FilipKittnar.
Hey sorry for tagging you, could you share your experiences and observations about this problem?

[darenju]

Now that you mention it, I think I had the same problem than you: converting from ReasonML to ReScript.

I have not tried to make a new project using ReScript directly (partly because of the incomplete syntax highlighting), so I cannot say if the problem goes away after some time, or just after the first file was open.

[FilipKittnar]

It should only pop up for the first file of a project you open? Is that not the case for you? Got a video?

@chenglou , this happens very inconsistently but this morning it actually happened so I took a video. It can be seen how the .bsb.lock keeps appearing and disappearing when switching between .res files. But as I said, this happens inconsistently. Yesterday it was fine.
https://u.pcloud.link/publink/show?code=XZ9oY4XZA5FnABEd1qf7DraQFzJsbYaIlday

[banacorn]

I'm suspecting that this happens when there's only ONE .res file opened at a time.

[banacorn]

I'm suspecting that this happens when there's only ONE .res file opened at a time.

If that's the case, then I think it's a logical design rather then a bug.

But we still need to make it less annoying.
We need some sort of "debouncing" to make .bsb.lock live longer.
I'm wondering if it's possible to store "timestamp" in .bsb.lock (now it's just some number)

[FilipKittnar]

I'm not 100% sure about this but it seems to help to really wait a while (around 1 minute) after you click "Build" and before you switch to another file. After that it seems that the .bsb.lock file doesn't disappear.
Or of course you have the good old way of disregarding the plugin build and do your own bsb -make-world -clean-world -w .

[cristianoc]

There's some design discussion on an alternative workflow that does not depend on starting a watcher from within the editor. Still, it's speculative at the moment.

[em]

I'm using vercel with vercel dev and this already has fs watching built in that looks for changes in any file . If not for this nag, I think I could have a single development terminal and even include rescript in my yarn build script.

As I stands now I always need 2 terminals. One for rescript -w, and one for everything else through vercel dev / yarn build.

[b0o]

I agree that it would be nice to be able to turn this off entirely. I feel that it makes assumptions about the user's workflow that may not be correct. I personally prefer to run a separate build/watch process and I don't want to be reminded inside my editor.

[zth]

Happy to help guide anyone interested in taking a stab at contributing a PR that makes showing that dialog configurable.

[carere]

@zth Hello :) I would be happy to start my journey of becoming a contributor to rescript ecosystem with this issue.

[zth]

@carere awesome! 😄 I'll get back to you this weekend with some ideas of how I think this one could be implemented.

[zth]

@carere ok, here's a rough breakdown of the task as I see it. This can be a bit tricky due to a few reasons, so bear with me (cc @cristianoc so you can weigh in on the solution too).

Essentially, what we'll want to do is:

1. Register a global configuration option for disabling the message.
2. Ensure that the message never shows unless the configuration allows it.

A crash course in how the extension works (this is only half true, but should be enough for this task):

• There's a client and a server. The client and the server communicates back and forth via messages.
• Our client is very thin - it's essentially just the stock VSCode language server client, and a few other things bolted on top. The server itself (server.ts) is what's doing all of the heavy lifting.

For this particular functionality, what happens is the server initiates in a new ReScript project, sees the compiler isn't running, and sends a message to the client to show a window message asking if the user wants to start the compiler. This is all done here: https://github.com/rescript-lang/rescript-vscode/blob/master/server/src/server.ts#L186-L210

The client will present that message with an action that sends another message back to the server, asking the server to start the compiler. That's done here: https://github.com/rescript-lang/rescript-vscode/blob/master/server/src/server.ts#L916-L938

Now, configuration options are defined in VSCode, which the client has easy access to, but not the server. Therefore, I think we'll need to change the architecture slightly for this to be as simple as possible (which I think we should make sure it is, so we don't complicate things more than we need). Keeping the server from needing to know about the config option means we don't need to sync state back and forth between the server and client, given that the configuration option can change at any time, and the server would need to know about that, etc.

This is what I envision:

1. Register the new configuration option in the extension.
2. Register a new command (but don't expose it via package.json) that will do the same prompting for starting the compiler as is done automatically now via the window/showMessage message, but after checking the global configuration option.
3. Change the server so that it sends a message to the client to invoke the new command we just registered (plus whatever config it needs to present the message), instead of the current window/showMessage message that prompts the user directly. (you can check out the language server spec for how to tell the client to invoke a command)

This way we avoid the server needing to know about the configuration option all together.

Does that make sense? Please feel free to open a WIP PR as soon as you want, and we can continue the discussion in there.

[mununki]

@zth I have a small question about your envision. It seems that all we need is a global configuration before prompting the showMessage Start build only in client side. Can you explain your design to change the server?

[zth]

Looping back to this, me and @cristianoc talked some and we think it's best if we do indeed forward configuration to the server, because we'll have other use cases for that too. So @carere if you don't mind, please hold off on this for a little while as we sort out how we'll handle configuration on the server, and the work here will be much more straight forward.

Will reply back here once we've fixed that centrally.

[zth]

@zth I have a small question about your envision. It seems that all we need is a global configuration before prompting the showMessage Start build only in client side. Can you explain your design to change the server?

Forgot to answer this, sorry... 😄 I think we mean the same thing, but call them different names. This is my view:

1. The client is the thin, stock VSCode language client we start in extension.ts
2. The server is in server.ts, and is a standalone process that the client communicates with via messages/responses
3. The analysis bin is the OCaml binary we use for more advanced functionality, and is a fully separate binary that the server calls into

[zth]

@carere I ended up fixing this in #432 because I needed something to test my changes with, and this was the only config I could figure out 😅

[carere]

Ok, well I was waiting for further info since your last message 😅, anyway great news. I'll tag you on another issue 😉

[zth]

@carere yes, sorry, I know I told you to wait. I'll make it up to you in the next one, I promise!

[cristianoc]

@carere if you're still looking for issues, there's one: if you miss accepting the notification when the editor is started, and the notification is gone, there's currently no way to start the build later (except restarting the language server). Also, presumably now that one can opt out of it via config, there's no way to start it manually just once, without going into the config.

[carere]

@cristianoc Ok, so I guess we have to create a new command which can launch the build process in background?

[cristianoc]

I guess so. Another option is having a button just like the one for "Stop Code Analyzer".
It's totally possible to create too many of these things and clutter things up, so worth thinking about what's best. E.g. there's more real estate for commands than for buttons, and I don't know if all the rescript-specific things that look like a button can be grouped together etc.

Perhaps @zth. has some thoughts on this.

[zth]

My 5c - I'm not a fan of running processes automatically like this from the extension. I've done a lot of this previously in the RescriptRelay extension, and I've had so many issues with orphaned watch processes staying around etc that I had to remove that feature. So my inclination would be to avoid auto running the watcher process at all because of the complexity/potential issues it brings.

[cristianoc]

There's also the completely opposite approach in the spectrum.
I.e. assume that it's always the user's responsibility to start the build and give the user hints on how to start a build if it's not started already. But don't do anything in the editor except for this information dialog.
In addition, offer some "advanced" setting where the build is always started automatically without asking, so it's always the editor's responsibility and never the user's. If the user wished to opt into that.

[cristianoc]

In that scenario, one also needs to define what happens if it's not inside a project. Should the editor tell the user that the file is not part of a project.

[carere]

We may create another issue and continue there ?
But it seems that the scope is more about handling the opening of a rescript file or a project folder.

[cristianoc]

@carere it's now possible to turn this off by config.
Are there any outstanding issues?

[carere]

@cristianoc oh yes, it's possible, but when I saw your recent messages, it feels like you were talking about what the extension should do when opening a file or a project.
Anyway, I'll work on the setting 😉