[BUG] lsp.servers.nil_ls: No formatter configured

[pagusupu]

Field	Description
Plugin	lsp.servers.nil_ls
Nixpkgs	unstable

• [x] I have read the FAQ and my bug is not listed there.

Description

after updating the newest unstable the below config doesnt work anymore, instead i get this: [ERROR]...-format/init.lua:219 "nil_ls: -32603: No formatter configured. Set the nil.formatting.command LSP server setting." from lsp.log

Minimal, Reproducible Example (MRE)

programs.nixvim = {
  enable = true;
  plugins = {
    lsp = {
      enable = true;
      servers.nil_ls = {
        enable = true;
        settings.formatting.command = ["${lib.getExe pkgs.alejandra}"];
      };
    };
    lsp-format.enable = true;
  };
}

[khaneliman]

I'm using nil_ls and haven't seen this behavior, we also have unit tests setup with nil_ls that don't throw the error, and I tried using that MRE as one of the test cases. Might need more information about your configuration / setup of nixvim.

[pagusupu]

my full config is here

ive also not been able to see it any logs but i get the notification asking about flake archive which only happens with the plugin default null, and my config has it set to false

[khaneliman]

Looks like you have pkgs from stable and nixvim from unstable, curious if you see the same behavior by matching them up / not overriding nixpkgs from nixvim.

[pagusupu]

settings both nixpkgs and nixvim to follow unstable (with nixvim following under the name nixpkgs specifically) still has the same result

[MattSturgeon]

settings both nixpkgs and nixvim to follow unstable (with nixvim following under the name nixpkgs specifically) still has the same result

Sometimes it can be difficult to pin down exactly which nixpkgs version is being used by nixvim, and just setting the flake input follows isn't always enough to change what is used.

If you're using nixvim via a wrapper module then we currently default to re-using the pkgs from the "host" configuration.

If you're using our standalone nixvim function, then it defaults to our flake input (which can be overridden using follows) but can also be explicitly specified using the pkgs argument in makeNixvimWithModule.

Maybe it's worth having a trace "pkgs version is ${pkgs.lib.trivial.release}" foo somewhere in your config? Although to ensure you use nixvim's pkgs you may need to wrap that in a module function:

programs.nixvim = { pkgs, ... }: {
  extraConfigLua = builtins.trace "pkgs version is ${pkgs.lib.trivial.release}" "";
}

---

If necessary, you can explicitly tell nixvim which pkgs instance to use via our nixpkgs.pkgs option. Currently this is only available on our main branch though.

---

Also, did you check what happens when you switch between nixvim's main branch and its nixos-24.05 branch?

[pagusupu]

ive moved everything in my config back to unstable and adding the trace reports its using the correct version (25.05), and i dont think its a good idea to try using the 24.05 branch as i only moved parts of my config to stable after the release of 24.11 beta.

i also seem to use the nixpkgs.pkgs option correctly, how am i supposed to use it? im not very good with nix... i am on the main branch though.

[bpeetz]

I've encountered the same issue, and traced it down to nixos module values leaking into the init.lua. My init.lua, for instance, contains leaked lib.modules.mkIf attribute sets:

 395   │     local __lspServers = {
 396   │         { extraOptions = { settings = { _type = "if", condition = true } }, name = "texlab" },
 397   │         {
 398   │             extraOptions = {
 399   │                 settings = {
 400   │                     _type = "if",
 401   │                     condition = true,
 402   │                     content = {
 403   │                         ["rust-analyzer"] = {
 404   │                             check = { command = "clippy" },
 405   │                             typing = { autoClosingAngleBrackets = { enable = true } },
 406   │                         },
 407   │                     },
 408   │                 },
 409   │             },
 410   │             name = "rust_analyzer",
 411   │         },
 412   │         { extraOptions = { settings = { _type = "if", condition = true } }, name = "ruff" },
                 -- and so forth.

My full config is here.

[camelpunch]

Also see this issue as described by @bpeetz. FWIW nixd formatter config, which uses the same settings path, works.

[daagaak]

Looks like he mkIf leakage was introduced in 63cfc84abeec5f8995945098e30e2d8101133d18 (bisected by switching between that and c7b7b6481b129d31b5357b4529c28e2cc341b96e)

[khaneliman]

Looks like he mkIf leakage was introduced in 63cfc84 (bisected by switching between that and c7b7b64)

Thanks for bisecting, maybe @MattSturgeon has an idea?

[MattSturgeon]

That commit changed how the settings option is defined, wrapping it in a mkIf (via applyExtraConfig).

However I'm a little confused as to why the module system isn't resolving the mkIf wrapper in this instance...

[MattSturgeon]

This is caused by the internal plugins.lsp.enabledServers.*.extraOptions option using types.attrs, which is soft-deprecated because it doesn't correctly merge attr values.

Switching to types.attrsOf types.anything resolves the issue by ensuring definitions are merged recursively.