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!
