You mean Visual Studio Code?

There is no integration. If you are using a Mix project, a simple mix compile on the command line should do the trick. Then to run your application, a simple iex -S mix should load an Elixir shell and your application, so you can do commands from there.

This will be an unpopular opinion to some, I’m sure, but I’m of the opinion that classic “step debugging” is largely useless in BEAM applications. The problems you encounter will more often than not have something to do with how you’ve laid out your actual process infrastructure.

What step debugging means for execution in processes is that you’ll be holding up a process live system, so it in fact doesn’t help for the actually important issues you’ll be investigating, as they’ll probably show up mostly under load where several processes need to interact. Obviously, if you freeze a process that might need to interact with other processes and as such won’t be responding to requests from elsewhere, you’re now actually the one breaking the system and your debugging has caused effects far beyond what a normal bug could.

It’s something akin to how you can’t determine the spin of an atom (?) without stopping it, thus actually influencing it.

There are other, better ways of debugging, like tracing, that will actually intercept messages between processes and give you information about the state changes in those processes.

If you’re not referring to debugging in the sense previously mentioned, could you please clarify what it is you mean?

Anyone know of a Visual Studio Code extension that will compile the current open Elixir window without having to type out the compile command each time?

I do not know about such a plugin. But you could use eye_drops to have a compile on save. Or anything similar. Guard from the ruby world will do as well but might be hard to integrate correctly.

If VSCode can take Atom plugins (wasn’t there a plugin for VSCode that lets you run a bulk set of Atom plugins?), all I do in Atom is hit save (Ctrl+s), that will then compile the file, run credo over it, and a few other things, with all errors and warnings appearing in the linter view that pops up at the bottom if there are any issues.