Dependency handling/bootstrap + SDK management

[sh41]

Headline changes

• Mix deps tooling + dependency status

  • Dedicated mix deps status parsing and standardized usage across the codebase.
  • Deps checker service with debounced notifications + new actions for install/show status.
  • Mix deps install run configuration and action.

• SDK creation, dependency wiring, and Mise integration

  • New SDK creation/registration flow with explicit Erlang dependency wiring before setupSdkPaths.
  • Project Structure now persists the Erlang dependency on first Apply and immediately populates class roots.
  • Mise plugin integration for auto‑install/configure of Elixir/Erlang SDKs plus notifier updates.

This is dependent on 134130/intellij-mise#410 and is stacked on #3763. To test it you will need the dev version of the mise plugin attached here or you can build yourself from the PR.
intellij-elixir-23.0.2-pre+20260216230350.zip
mise-5.15.0-ep.zip

Very much a work in progress at the moment, feedback/bug reports very welcome.

Incidental / minor fixes

• WSL handling and path normalization

  • Centralized WSL path canonicalization via WslCompatService (prod + mock).
  • WSL‑safe command line handling improvements for Mix/SDK flows.

• Build/test tooling for SDK resolution

  • buildSrc SDK resolver/validator + tasks to resolve/prepare Elixir/Erlang SDKs.
  • Gradle wiring to pass resolved SDKs into testUI and related tooling.

• Threading/write action safety

  • Non‑blocking write actions in formatter and BEAM UI panels to avoid background/EDT exceptions.

• CLI/config robustness

  • Hardened CLI argument construction and related Mix/IEx/ESpec/ExUnit configuration handling.
  • Updates to mix runner and dialyzer service to align with new argument handling.

• UI/UX and notifications

  • Project wizard tweaks, setup notifications, and test UI bootstrap improvements.

[sh41]

I've dropped the mise plugin integration from this because there isn't a timeline for getting the EP merged.

I've reworked all of the SDK management code again and I think that I've figured out how to allow users to add an Erlang SDK and an Elixir SDK in the Project Structure dialog without needing to "OK" it and then go back in.

There are a few other fixes, as well that can probably be cherry picked if that's the preferred way forward.

It's still a work in progress while I test locally, so any feedback would be good to hear.

[sh41]

Hey @joshuataylor, I've had a chance to resolve the pipeline issues on this and made a quick recording of the testUI task to show the new "mix deps" notification and what happens when it runs.

It only installs in dev (or whatever MIX_ENV is set to) so the test that runs afterwards still needs to compile. I should also be able to update the test to not click OK between the Erlang SDK add and the Elixir add, but I don't have time to look at that right now.

Let me know what you think. If you're happy with it as it is right now, the branch is good to merge.

2026-02-28.Elixir.TestUI-small.mp4

[sh41]

Hi @joshuataylor,

I've culled some dead code and refactored some of the error handling for missing Erlang, I'm testing again now to try to flush out any bugs. Happy to receive any feedback you have on this.

[joshuataylor]

Awesome!

I'll take a look tonight!

BTW, been writing a fair bit of Elixir/Phoenix code in the past week, and have been using the previous pre-release version of the plugin, and now the current pre-release version, and it's been perfect. (MacOS, mise)

I haven't seen any weird mix build issues mentioned previously, Go-to-Definition works great, etc. NO RED IDE ERRORSS!!

(I don't use mix tasks etc, which I've been meaning to do, and I don't really use debugging in elixir (I just do IEx.pry, which feels weird compared to IDE Debugging).

I'll give this branch a go now.

[sh41]

What's your current thinking on SDK setup? Is the Java/Project Structure setup here to stay or is the plan to move to a different method?

This PR (and I think most of the current plugin) makes a broad assumption that the Elixir SDK at project level applies to everything, but there are plenty of places in the code where it could and maybe should be handled at module level. I've noticed a few instances, especially in umbrella projects when the sub-apps are configured as IDEA modules that they don't correctly pick up the project SDK when it is configured. I've been resolving it by manually setting them to the project SDK in each sub-app, but this might be something we can have the plugin do.

The only use-case I can think of for different modules in the same IDEA project requiring different elixir versions is a monorepo with multiple mix projects in sub folders. This feels like an edge case, so not sure it's worth specifically handling.

[joshuataylor]

Given it was a GIANT hack from the start for SDK support, and JetBrains themselves seem to be moving away from it (to support their Python SDKs, last time I was in the area for a related project -- this was the last big push I believe, and now they're working on uv (python package manager), we might actually get some work done with it.

I haven't touched it for a while, this was around trying to work with the Python SDK for a related project.

I've noticed a few instances, especially in umbrella projects when the sub-apps are configured as IDEA modules that they don't correctly pick up the project SDK when it is configured.

Same, but this also happens for me a lot with generic Gradle (Java/Kotlin) projects (Plugin development) and others, honestly the entire SDK stuff is a mess.

They want us to go to the Workspace Model, which funfact was introduced with DataSpell I believe.

I wonder if it's stable, and who's using it, worth a dig, and how much effort it'll be to migrate to SOMETHING. Might be worthwhile asking on the forums as well.

[sh41]

I've pushed a couple more commits to this. One was purely a refactor of maybeUpdateMixHome because when I revisited it I found it difficult to read. The other changes which environment variables are passed through the conversion process when running on WSL. Previously all env vars were converted, but I now realise that's wrong and can lead to strange behaviour. I have changed it to only convert the MIX_HOME & MIX_ARCHIVES variables that we add.