refactor: rename "server_configurations" => "configs"

[justinmk]

Problem:
The name server_configurations is extremely verbose and irritatingly formal and dogmatic. This overlong name is a constant nuisance when reading, writing, and coding.

It's also not even correct: these configurations are just as much "client" configurations as they are "server" configurations.

Solution:

• Rename to a shorter name.
• Leave placeholder files for any old URLs that link to the old location.

[github-actions]

Note that server_configurations.md or server_configurations.txt will be regenerated by the docgen CI process. Edit the Lua source file instead. For details on generating documentation, see: https://github.com/neovim/nvim-lspconfig/blob/master/CONTRIBUTING.md#generating-docs

[sxyazi]

This should probably be a refactor! instead of a refactor because it changes the directory structure and breaks a lot of user code.

Not that it matters much, but it makes it harder to follow changes to the code here :)

[justinmk]

I am surprised to see code like https://github.com/LazyVim/lazyvim.github.io/blob/cfb8baecfa4ef136abe8a40d807ade3a9d3be438/docs/extras/lang/tailwind.md?plain=1#L55

local tw = require("lspconfig.server_configurations.tailwindcss")

The documented way to use configs has always been:

local tw = require'lspconfig'.tailwindcss

But I can add a compatibility shim if this change breaks things.

[sxyazi]

Thanks for your response @justinmk!

In my case, I want to get and reuse some default ESLint configs, specifically the filetypes and root_dir method - similar to the work done in tailwind.lua you linked.

Before I used:

local eslint_default = require("lspconfig.server_configurations.eslint").default_config

Now I've changed it to:

local eslint_default = require("lspconfig").eslint.document_config.default_config

It works, but document_config seems to be also an undocumented way - I can't find anything about that in docs. Can I use it safely?

[justinmk]

specifically the filetypes and root_dir method

Ok, I see that use-case is to get a config definition without activating it. I added config_def: #3335

(ideally this field wouldn't be needed, the result of require'lspconfig'.foo should just include the static info directly, but oh well)

[sxyazi]

Can confirm the new config_def works perfectly for me, thanks! 👍🏻

[WieeRd]

This should probably be a refactor! instead of a refactor because it changes the directory structure and breaks a lot of user code.

Not that it matters much, but it makes it harder to follow changes to the code here :)

Can confirm, it just broke my plugin 5 minutes ago and confused me lol.
But I think this was a good change 👍