ElixirLS invokes the equivalent of mix compile (Mix.Task.run("compile", opts)) whenever one of the open files gets saved or changes in the watched files get detected. Instead of unreliable tracking of options passed to the task (which can change) I’d advise you to make your compiler detect changes and recompile only when needed. You can return :noop if e.g. the hash of files did not change since last successful compilation.

I took some time to properly debug what was going on here. I first nuked my .elixir_ls directories and upgraded to the latest version (0.17.10). Coincidentally, I see you released this version while I was typing up my last post!

I have found the source of the behavior I was seeing. It’s very specific to the way I happened to be testing my code, so I’ll explain in detail.

The corp_style project is meant to be used as a library (it generates scoped css styles for heex components). The output path (and a couple other things) are configured in a manner similar to the esbuild and tailwind packages that ship with Phoenix.

The config is placed under a “profile” with an arbitrary key, though currently I only support one such key (default). It looks like this:

config :corp_style,
  default: [
    out_path: "some/path/to.css",
  ]

Then the compiler loads the config by the usual method, Application.get_env(:corp_style, :default). If the result is truthy, it compiles the CSS. If the result is nil (i.e. the library has not been configured), it does nothing.

While testing, I renamed the key from default to something else to disable the compiler. However, the compiler was still running, which is the bug that led to me opening this thread.

I now see what is happening here is that elixir-ls is, in fact, correctly reloading the config and recompiling, but the config is merged instead of overwritten on reload. So, when I rename default to something else and elixir-ls recompiles, the default key still exists, and so my compiler still runs.

I find this merging behavior very surprising. I understand that Elixir’s config deep-merges keys, but I assumed (and I think most others would assume) that when you remove a key from your config that it’s actually gone. Perhaps this is why Phoenix enforces a server restart after a config change?

Anyway, now that I know what was actually causing the behavior I was seeing I can work around it more easily. Thank you for your help!

I put together a minimal reproduction. The bug only seems to occur with a dependency (note that I only tested a path dependency, not git or hex dependencies).

Steps to reproduce:

1. Clone these repositories into the same directory.

   https://git.sr.ht/~garrisonc/exls_bug_config_merge
   https://git.sr.ht/~garrisonc/exls_bug_config_merge_parent
   

   Note that the latter has a relative path dependency on the former
2. Open exls_bug_config_merge_parent/config/config.exs in an LSP-enabled editor.
3. Note that a warning message has been printed to the LSP log with a dump of the config keys for the child project. This message comes from the Mix compiler task.
4. Change the config key in the parent’s config.exs to any other value.
5. Note that the warning message now prints multiple keys, indicating that they have been merged.
6. Repeat steps 4 and 5 indefinitely.

Tested in neovim on macos via nvim-lspconfig.

Additionally, IIRC ElixirLS runs with MIX_ENV=“test” by default. You could always check the value of Mix.env() in your mix.exs and not add your compiler to the def project, do: [compilers: ...] list when it is "test".

However, the issue I was running into was that when I changed my config.exs to disable the compiler it was still being invoked by the LSP. I assumed at the time that the LSP was hot reloading the code similar to the Phoenix server, and so had to be restarted to re-read the config.

Config reload happens in elixir-ls/apps/language_server/lib/language_server/build.ex at 2d6c4b8784762e1c8183d0b73c0eeb1f93a6779e · elixir-lsp/elixir-ls · GitHub

For the record I did implement the --return-errors fingerprint hack, and it works fine for the time being, but I’m not happy with it either.

If you need to check it via fingerprint hacks, then setting an environment variable in ElixirLS configuration may be a better option.