fix(pack): docker-language-server to dockerls

[jay-babu]

No description provided.

[github-actions]

Review Checklist

Does this PR follow the [Contribution Guidelines](development guidelines)? Following is a partial checklist:

Proper conventional commit scoping:

• If you are adding a new plugin, the scope would be the name of the category it is being added into. ex. feat(utility): added noice.nvim plugin

• If you are modifying a pre-existing plugin or pack, the scope would be the name of the plugin folder. ex. fix(noice-nvim): fix LSP handler error

• Pull request title has the appropriate conventional commit type and scope where the scope is the name of the pre-existing directory in the project as described above

• README is properly formatted and uses fenced in links with <url> unless they are inside a [title](url)

• Entry returns a single plugin spec with the new plugin as the only top level spec (not applicable for recipes or packs).

• Proper usage of opts table rather than setting things up with the config function.

• Proper usage of specs table for all specs that are not dependencies of a given plugin (not applicable for recipes or packs).

[github-actions]

Review Checklist

Does this PR follow the [Contribution Guidelines](development guidelines)? Following is a partial checklist:

Proper conventional commit scoping:

• If you are adding a new plugin, the scope would be the name of the category it is being added into. ex. feat(utility): added noice.nvim plugin

• If you are modifying a pre-existing plugin or pack, the scope would be the name of the plugin folder. ex. fix(noice-nvim): fix LSP handler error

• Pull request title has the appropriate conventional commit type and scope where the scope is the name of the pre-existing directory in the project as described above

• README is properly formatted and uses fenced in links with <url> unless they are inside a [title](url)

• Entry returns a single plugin spec with the new plugin as the only top level spec (not applicable for recipes or packs).

• Proper usage of opts table rather than setting things up with the config function.

• Proper usage of specs table for all specs that are not dependencies of a given plugin (not applicable for recipes or packs).

[jay-babu]

  {
    "williamboman/mason-lspconfig.nvim",
    opts = function(_, opts)
      opts.ensure_installed = opts.ensure_installed or {}
      -- filter out the kotlin_language_server if it is already installed
      opts.ensure_installed = vim.tbl_filter(
        function(server) return server ~= "kotlin_language_server" end,
        opts.ensure_installed
      )
      opts.ensure_installed = vim.tbl_filter(function(server) return server ~= "sqls" end, opts.ensure_installed)
      table.insert(opts.ensure_installed, "tsp_server")
    end,
    config = function(_, opts)
      require("mason-lspconfig").setup(opts)
    end,
  },

I really don't know why but my mason-lspconfig setup function is not running till I manually added the config function. This is likely why no one has seen this error for 7 months as this is when this was committed. As soon as I did it started running again.

[wert2all]

I really don't know why but my mason-lspconfig setup function is not running till I manually added the config function. This is likely why no one has seen this error for 7 months as this is when this was committed. As soon as I did it started running again.

Maybe I'm doing wrong, but on a clean install of nvim, I got docker-compose-language-service and dockerfile-language-server LSPs. Steps for reproduce:

1. Change docker-language-server to dockerls
2. rm -rf ~/.local/share/nvim && rm -rf ~/.local/state/nvim && rm -rf ~/.cache/nvim
3. start nvim
4. docker-compose-language-service and dockerfile-language-server installed.

On my clean config, without you fix, I got docker-language-server only. Maybe docker-language-server installs other pack, which I am using.

[azdanov]

I think it's my fault here.

Since astronvim v5 uses mason-lspconfig v1, which doesn't have docker-language-server.
v1: https://github.com/mason-org/mason-lspconfig.nvim/blob/1a31f824b9cd5bc6f342fc29e9a53b60d74af245/lua/mason-lspconfig/mappings/server.lua#L48 and https://github.com/mason-org/mason-lspconfig.nvim/blob/1a31f824b9cd5bc6f342fc29e9a53b60d74af245/lua/mason-lspconfig/mappings/filetype.lua#L48

But v2 has https://github.com/mason-org/mason-lspconfig.nvim/blob/3d89e7c92fbd96c5e10e0298fc2b006f21cf9428/lua/mason-lspconfig/filetype_mappings.lua#L50

So, need to probably hotpatch mason-lspconfig to recognize the new docker-language-server lsp to make it work.

There is some confusion here in the thread between docker-language-server, dockerfile-language-server and docker-compose-language-service which are 3 different LSPs. The previous update that I did was to replace the community LSPs (dockerfile and compose) with official https://github.com/docker/docker-language-server.

[azdanov]

Here's an example of hotpatching (thanks to mehalter for providing this technique):

astrocommunity/lua/astrocommunity/pack/oxlint/init.lua

Lines 23 to 42 in 9ee60b5

	{
	"AstroNvim/astrolsp",
	opts = {
	mason_lspconfig = {
	servers = {
	oxlint = {
	package = "oxlint",
	filetypes = {
	"javascript",
	"javascriptreact",
	"javascript.jsx",
	"typescript",
	"typescriptreact",
	"typescript.tsx",
	},
	},
	},
	},
	},
	},