Needs an invalidation or clean mechanism

[davesmith00000]

Hi,

Context in case it matters, I'm doing Scala.js work.

Generally, the plugin is very stable. From time to time though, Atom or the SBT client plugin gets very confused about it's incremental compile state. SBT itself is quite happy (I run SBT in a terminal in the background, which I vastly prefer to the VSCode version that tries to run it for me!).

This happens a lot running unit tests with ScalaTest where instead of getting a nice error message when your tests are run, you actually get a linking error in JS. This is usually resolved by running clean, possibly with test:compile in the running SBT session.

Another instance where this happens is when you use global find and replace in Atom and it touches lots of files with auto-save. The diagnostics show errors where there are none and can only be invalidated with a hard restart of everything. I imagine a similar thing would happen with a big version control change, but I haven't tried it to know for sure.

For now I'd be overjoyed with a blunt "sbt: clean" task in the Atom command palette if such a thing is possible?

Dave

[davesmith00000]

Wondering if I could help, so fishing round the docs, looks like I'd need basically this:
https://www.scala-sbt.org/1.x/docs/sbt-server.html#request

...and a new command in the command registry?
https://atom.io/docs/api/v1.4.1/CommandRegistry

Am I looking in the right places or way off? :-)

sbt Reference Manual — sbt Server

Atom

A hackable text editor for the 21st Century

At GitHub, we’re building the text editor we’ve always wanted: hackable to the core, but approachable on the first day without ever touching a config file. We can’t wait to see what you build with it.