Base config isn't importable by plugin user

[briandipalma]

Description

I added an eslint.lua file in my after/lsp directory and I copied the code inside this repos eslint.lua to setup running LspEslintFixAll on save. I used the base_on_attach and called it first just like the code example and this killed LSP functionality as I ended up in an infinite loop as my new on_attach overwrote the one in this repo as it seems the after/lsp code is loaded over and over.

I'm not sure if this is considered a bug but to me as an end user it's a poor experience. I'm not really sure how to deal with this issue other than continuing to provide the old style exports from this repo or expecting users to just copy the code into their config or not use after/lsp.

[pisetski]

@briandipalma, could you please add code snippets of what you tried? Also, please check https://github.com/neovim/nvim-lspconfig#bug-reports.

Per docs:

The configs live in the lsp/ directory. vim.lsp.config automatically finds them and merges them with any local lsp/*.lua configs defined by you or a plugin.

After you install nvim-lspconfig, the configurations from it will be automatically detected. You don't need to manually copy-paste them, unless you want to rewrite the configuration.

[briandipalma]

I'll try it when I'm back in work on Monday but I think it was this:

local base_on_attach = vim.lsp.config.eslint.on_attach

return {
	on_attach = function(client, bufnr)
		if not base_on_attach then
			return
		end

		base_on_attach(client, bufnr)
	end,
}

inside /nvim/after/lsp/eslint.lua, you can imagine that if that file is executed over and over again then you end up in a longer and longer loop as local base_on_attach = vim.lsp.config.eslint.on_attach ends up being your on_attach...

If you just write

local base_on_attach = vim.lsp.config.eslint.on_attach
vim.lsp.config("eslint", {
...

in your config then it won't be a problem but I'd much prefer to have my config specified via individual filetypes and language server files as it's simpler/cleaner.

[pisetski]

It looks like you are causing an infinite loop by referencing vim.lsp.config.eslint from your after/lsp/eslint.lua.

When you access vim.lsp.config.eslint, neovim resolves the config by loading files from lsp/*.lua and after/lsp/*.lua. This creates circular recursion. Maybe someone more experienced will correct me, but I think you are not allowed to call vim.lsp.config.eslint from eslint.lua config files because of the aforementioned reason.

If you're copy-pasting the entire nvim-lspconfig eslint config into after/lsp/eslint.lua, you already have the on_attach code - there's no need to reference vim.lsp.config.eslint.on_attach. Just modify your after/lsp/eslint.lua as needed.

If your goal is to extend the base on_attach without duplicating the original code, then after/lsp/ can't do this cleanly because of the resolution cycle 🤷‍♂️

[briandipalma]

I didn't know about the late resolution but I was pretty sure it was an infinite loop so that makes sense. It's a pity that configuration placed in after/lsp can't extend configuration from this repo. This is why I suggested keeping an export path for configuration when using this repository. Is there some architectural reason for discouraging importing from this repo? I guess it's because lua doesn't offer relative imports so you couldn't easily export the configuration inside lsp?

[pisetski]

It seems this is not an architectural decision, but a limitation. It is being tracked upstream in neovim/neovim#33577. See neovim/neovim#33577 (comment) specifically.