ElixirLS goes into a compile loop about mix_gleam HOT 4 CLOSED

Thanks for the quick reply! Makes sense.

I searched a bit but couldn't find an ignore option in ElixirLS so I solved it with this simple workaround, that excludes the gleam compiler when ElixirLS is running. Since ElixirLS will most likely only run in a developer context and the :dev environment includes the gleam compiler, gleam code should already be up to date when ElixirLS compiles the rest.

Mix.exs (golf version, could be replaced with a proper if-else block):
compilers: ((Mix.env() == :elixirls && []) || [:gleam]) ++ Mix.compilers(),

VSCode settings:
"elixirLS.mixEnv": "elixirls"

In a more complex project (e.g. in my Phoenix project) a config/elixirls.exs is needed. This could simply import one of the others:

use Mix.Config

import_config "test.exs"

from mix_gleam.

For anybody coming to this now, changing compilers in mix.exs no longer works.

Do this instead:

mix.exs:

Change this:

aliases: MixGleam.add_aliases(aliases()),

To this:

aliases: (Mix.env() == :elixirls && []) || MixGleam.add_aliases(aliases()),

VSCode settings:

"elixirLS.mixEnv": "elixirls"

from mix_gleam.

Hiya! It looks like the ElixirLS is detecting the generated Erlang created by the Gleam compiler and is triggering compilation again. ElixirLS will need to ignore the gen directory to avoid this.

A later version of Gleam will change where Erlang is written to so this shouldn't be a problem after that point, but ElixirLS will need to handle it until then.

from mix_gleam.

Ran into this issue as well but it turns out I could have emacs ignore whatever. Maybe this issue would be useful for others.

from mix_gleam.