jay-babu / mason-null-ls.nvim

Hi there 👋

Quotes I love

From the Ashes comes the Phoenix 🐦‍🔥

mason-null-ls.nvim's Issues

Remove / decrease the need for source.lua

Most of the sources in source.lua map to mason.nvim package names exactly or by simply changing _ => -. The goal of this is to have mason-null-ls do this check secretly and not require to be exist in source.lua.

1. If exists in source.lua then use that
2. If package name with _ => - exists in mason.nvim, then use that

https://github.com/jay-babu/mason-null-ls.nvim/blob/main/lua/mason-null-ls/mappings/source.lua

Contradictory documentation

The README.md section "Setup" reminds to make sure the setup functions are called in this exact order: 1. mason 2. null-ls 3. mason-null-ls.
However, the section "Setup handlers usage" gives an example in which null-ls's setup is called after mason-null-ls's setup.

Should the default setup function have something in it?

I have added automatic setup in the order mason, null-ls, mason-null-ls as noted in your preferred method.

The two formatters which I have a specific function for work with no issue, however any other formatters I install don't show up in NullLsInfo. My guess here is that the default function being empty effectively means nothing is running and it should contain something along the lines of:

null_ls.register( null_ls.builtins.formatting[source_name] )

But then with variations for things that aren't formatters.

Is there a function that should go here or is the default option just not supported?

Editor config checker issues

Hi, there seems to be a problem with the default config for the editor config checker and the executable name more specifically. Mason renames that executable to editor-checker but null ls expects by default it to be ec instead.

Automatic null-ls registration

With the work going on at mason-nvim-dap are there plans to add automatic null-ls registration as well? This would be super great and extremely easy especially with the new commit to return the supported methods.

AstroNvim does this with a very simple default setup handler:

function null_ls_register(source, types)
  local null_ls_avail, null_ls = pcall(require, "null-ls")
  if null_ls_avail and not null_ls.is_registered(source) then
    vim.tbl_map(function(type) null_ls.register(null_ls.builtins[type][source]) end, types)
  end
end

mason_null_ls.setup_handlers({ null_ls_register })

I think it would make sense to move this into mason-null-ls with an automatic setup configuration option similar to the work we are doing with mason-nvim-dap. And could be rewritten in the functional format that you are using as well.

Why are not all sources supported?

I see that lua/mason-null-ls/mappings/filetype.lua lists all the null-ls supported sources but some of these are commented out, why is that, how do you auto generate this file? I also see that lua/mason-null-ls/mappings/source.lua has some custom mappings which don't simply adhere to - and _ substitution, the thing I need in my project is ansiblelint which for Mason is ansible-lint, and it currently does not work with ensure_installed. I'd be happy to help out, just want to know if this is intended, todo or missed? Thanks!

unknown source error on setting up handlers

[mason.nvim] mason-null-ls.setup_handlers: Received handler for unknown null-ls source name: beautysh.
[mason.nvim] mason-null-ls.setup_handlers: Received handler for unknown null-ls source name: zsh.

i get the above error messages on startup. relevant parts of my config:

mason-null-ls.lua:

local ok, mnl = pcall(require, "mason-null-ls")
if not ok then
    print("failed to load mason-null-ls")
    return
end

mnl.setup({
    automatic_installation = true,
    ensure_installed = { "beautysh", "zsh" },
})

local nullls = require("null-ls")

mnl.setup_handlers({
    function(source_name) end,
    beautysh = function()
        nullls.register(nullls.builtins.diagnostics.beautysh)
    end,
    zsh = function()
        nullls.register(nullls.builtins.formatting.zsh)
    end,
})

nullls.setup()

lua/miki/plugins.lua:

    -- package manager
    {
      "williamboman/mason.nvim",
      config = "require 'miki.configs.mason'",
    },
    {
      "williamboman/mason-lspconfig.nvim",
      after = "mason.nvim",
      config = "require 'miki.configs.mason-lspconf'",
    },
    {
      "jayp0521/mason-null-ls.nvim",
      config = "require 'miki.configs.mason-null-ls'",
      after = "null-ls.nvim",
    },

i'm on NVIM v0.9.0-dev-16-g56998feeb. the plugin has been working fine so far otherwise. what do i do wrong?

Lazy plugin manager

I feel that maybe the problem is due to my lack of knowledge, but I did the following for Lazy.nvim.

{
     "jay-babu/mason-null-ls.nvim",
     dependencies = {
            "williamboman/mason.nvim",
            "jose-elias-alvarez/null-ls.nvim",},
     lazy = false,
             config = function()
			 require("packages.null-ls")
		         end,
},

What happens is that mason, null-ls and mason-null-ls are installed correctly and are even activated in the initial run (in staline the name of the formater package can be seen), but if you want to do the formatting operation Do it, you will encounter the null-ls not found message.

My English writing is not very interesting, please forgive me.

ensure_installed doesn't appear to work

👋🏻

I have the following null-ls configuration:

      null_ls.setup({
        sources = {
          require("null-ls").builtins.formatting.lua_format, -- https://github.com/Koihik/LuaFormatter
        }
      })

When writing a lua buffer I see the error:

command lua-format is not executable (make sure it's installed and on your $PATH)

So I've added lua_format to the following mason-null-ls configuration, but it doesn't seem to work still.

  use {
    "williamboman/mason.nvim",
    "williamboman/mason-lspconfig.nvim",
    "neovim/nvim-lspconfig",
    "Afourcat/treesitter-terraform-doc.nvim",
  }
  use {
    "jayp0521/mason-null-ls.nvim",
    requires = "jose-elias-alvarez/null-ls.nvim",
    config = function()
      require("mason-null-ls").setup({
        ensure_installed = {
          "autoflake",
          "autopep8",
          "checkmate",
          "codespell",
          "commitlint",
          "fixjson",
          "flake8",
          "goimports_reviser",
          "golangci_lint",
          "isort",
          "lua_format",
          "markdown_toc",
          "mdformat",
          "mypy",
          "ocdc",
          "semgrep",
          "shellcheck",
          "shfmt",
          "taplo",
          "terraform_fmt",
          "write_good",
          "yamlfmt",
        }
      })
    end
  }

  require("mason").setup()
  local mason_lspconfig = require("mason-lspconfig")

  mason_lspconfig.setup({
    ensure_installed = {
      "bashls",
      "eslint",
      "gopls",
      "jsonls",
      "marksman",
      "pylsp",
      "rust_analyzer",
      "sumneko_lua",
      "terraformls",
      "tflint",
      "tsserver",
      "yamlls",
    }
  })

  mason_lspconfig.setup_handlers({
    function(server_name)
      require("lspconfig")[server_name].setup({
        on_attach = function(client, bufnr)
          require("settings/shared").on_attach(client, bufnr)
          require("illuminate").on_attach(client)

          if server_name == "terraformls" then
            require("treesitter-terraform-doc").setup()
          end
        end
      })
    end
  })

duplicate setup of standardrb

nvim-lspconfig supports standardrb as LSP server. If I use automatic setup with mason-null-ls, standardrb would be setup again using null-ls.builtins logic even I do not mean to use standardrb in null-ls.

It might be helpful to mention this behavior on README. I'm using handlers = { standardrb = function() end } to avoid the unexpected setup.

Feature request: Border style support

Please add support for rounded/single/double border similar to Mason, if possible.

Server getting registered with null-ls even when I don't configure it

I only want NVIM to set up LSP for servers I explicitly mention in the config. I have the following lazy.nvim configuration currently:

  {
    "null-ls.nvim",
    dependencies = {
      "typescript.nvim",
    },
    opts = function(_, opts)
      local nls = require("null-ls")

      return vim.tbl_deep_extend("force", opts, {
        sources = {
          nls.builtins.code_actions.eslint_d,
          nls.builtins.code_actions.shellcheck,
          require("typescript.extensions.null-ls.code-actions"),

          nls.builtins.diagnostics.alex,
          nls.builtins.diagnostics.cmake_lint,
          -- nls.builtins.diagnostics.markdownlint,
          nls.builtins.diagnostics.ruff.with({ extra_args = { "--line-length", 79 } }),
          nls.builtins.diagnostics.yamllint.with({
            extra_args = {
              "-d",
              "{extends: default, rules: {document-start: {present: false}, line-length: {max: 79}}}",
            },
          }),
        },
      })
    end,
  },
  {
    "jay-babu/mason-null-ls.nvim",
    event = { "BufReadPre", "BufNewFile" },
    dependencies = {
      "mason.nvim",
      "null-ls.nvim",
    },
    opts = {
      automatic_setup = false,
      automatic_installation = true,
      handlers = {},
    },
  },
  {
    "jose-elias-alvarez/null-ls.nvim",
    keys = {
      { "<leader>cn", "<cmd>NullLsInfo<cr>", desc = "Null LS Info" },
    },
  },

I have seen this issue with markdownlint where it shows up in the diagnostics even if I comment it in the config. How do I fix this behaviour?

Future plans given the archiving of null-ls

Thank you for integrating null-ls with mason. The mason ecosystem is clearly improving my workflows, particularly as I transition from my vimscript configurations.

I'm hoping that you might let users know you POV on how to proceed given the dependency of this plugin on a now archived repo.

Thank you!

Mason-tool-installer is dependency and it should not be

Automatic installation behavior contradicts documentation

I'm currently using the first method (primary source of truth is mason-null-ls) for automatic setup, but it does not seem to work when using the order specified in the README.

-- Using lazy.nvim plugin manager
return {
    {
        "williamboman/mason-lspconfig.nvim",
        dependencies = { "neovim/nvim-lspconfig", "mason.nvim" },
        opts = {
            ensure_installed = { "lua_ls" },
            handlers = {
                function(lsp)
                    require("lspconfig")[lsp].setup({})
                end,
            },
        },
    },
    {
        "jay-babu/mason-null-ls.nvim",
        dependencies = { "nvimtools/none-ls.nvim", "mason.nvim" },
        opts = {
            ensure_installed = { "stylua" },
            handlers = {},
        },
        config = function(opts)
            require('mason-null-ls').setup(opts)
            require('null-ls').setup({
                sources = {
                    -- none
                }
            })
        end,
    },
    {
        "williamboman/mason.nvim",
        opts = {},
    },
}

Running :NullLsInfo shows that there is no attached language server. Getting rid of the config function entirely seems to fix the issue, but then the setup for null-ls is not executed, so I don't have access to the functions it exposes (e.g. :NullLsInfo). Requiring null-ls first inside the config function doesn't fix the issue, but, strangely enough, adding an opts = {} entry to the dependency specification for null-ls gets it to work.

    ...
    {
        "jay-babu/mason-null-ls.nvim",
        dependencies = { { "nvimtools/none-ls.nvim", opts = {} }, "mason.nvim" },
        opts = {
            ensure_installed = { "stylua" },
            handlers = {},
        },
    },
    ...

From my understanding of lazy.nvim, this means that null-ls will be setup before mason-null-ls, which is the opposite of what the README says is needed when using mason-null-ls as the source of truth. I'm confused though why this method worked, but swapping the order of the require-statements inside the config function did not.

I'm new to Lua, so I don't yet know how everything works, but I'm concerned that this could be a race condition between the setup of null-ls and mason-null-ls and that I'm only observing it when the setup routines for both modules are executed closely together in the config function.

Thank you for your time, and please let me know what is the correct way to enable automatic setup using mason-null-ls as the source of truth.

unsuccessful `ensure_installed` installation fails **silently**

require("mason-null-ls").setup({
	ensure_installed = { "stylua" },
})

in this example, stylua needs unzip as an available command to install.
unzip isnt in system path currently.

when you open nvim, [mason-null-ls] installing stylua is in cmdline.
the installation failed in the background, but no response.
(ig this is what you call "silent")

issue?

i have no idea if it installed, or didnt + i dont know why it failed

idk its not really an issue (more of an enhancement), but giving feedback to an error saves you
from going into mason manually and having to find the error there.

plus, you could be really confused at why something that is supposed to be installed doesnt exist.

anyways, thx for this plugin, good stuff :)

Add a function to querry the supported lsp features

Hi,
I'm using your plugin to install null-ls sources.
I have the problem that I don't know if a source supports formatting, code_action etc.
Since null-ls has some builtin lsp sources I already requested a method in this issue to test if a builtin source exists.
I think it would be useful to have a method in your plugin with which one could query what lsp features the source supports.
Thanks for considering this feature request.

Not automatically installing or automatically setting up

I don't know if something changed in null-ls that broke this, but right now the only way I can get this to install things is to list them out in ensure_installed. I've tried both methods of setting this up (null-ls canonical and mason-null-ls canonical) and neither one work for me...

This is with the latest versions of both null-ls and mason-null-ls.

jose-elias-alvarez/null-ls.nvim to be archived on 2023-08-11

jose-elias-alvarez/null-ls.nvim#1621

Clean readme

Hello, you've made very cool projects as extensions to Mason, though I'm finding the readme for this one a bit confusing as it seems like you have copied it from the dap plugin and just changed things arround. I'd appreciate if you ensured everything is correct so it's clear.

Don't install if the required packages already exist in the PATH

I have stylua in my system. But mason-null-ls.nvim still install stylua through mason.
I know I can prohibit it from installing stylua by changing the config.
But I wonder if there is a smarter way that is suitable for all packages.

Is `setup_handlers()` deprecated?

If it's deprecated, then what is the alternative?

deno_fmt not autoinstalled

Just a minor edge-case I noticed. deno_fmt source for null-ls does not auto-install deno through mason.

Future of this plugin with null-ls being archived?

With null-ls being archived in the near future, and up until now new maintainer in sight, I wanted to ask what the future of this plugin is going to be?

I personally work with three different devices, and I find the ensure_installed feature of this plugin immensely useful to ensure I have formatters/linters etc. installed at all devices.

Will this plugin continue ensuring installation of linters/formatters, even without null-ls? Right now, null-ls is still listed as a requirement for this plugin, but technically, null-ls isn't really needed, since this plugin mainly interfaces with mason to install stuff, right? 🙏

Use nvim-lint now that null-ls will be archived?

I believe something like mason-nvim-lint might be a successor to this repository.

Keep getting `mason.nvim/lua/mason-registry/init.lua:67: bad argument #1 to '?' (string expected, got nil)` error in mason.log

Basically williamboman/mason.nvim#789

I opened the issue in mason repo first because I had no idea mason-null-ls.nvim was (apparently?) the culprit.

Exclude list of tools from automatic installation

It would be really helpful to be able to exclude some tools from automatically installing. Unfortunately, Mason is unable to install some tools on some platforms such as Termux(Android) and FreeBSD/OpenBSD but it would be really nice to still take advantage of this plugin to automatically install the majority of compatible plugins.

It would look like mason-lspconfig.nvim implementation of this feature:

    -- Whether servers that are set up (via lspconfig) should be automatically installed if they're not already installed.
    -- This setting has no relation with the `ensure_installed` setting.
    -- Can either be:
    --   - false: Servers are not automatically installed.
    --   - true: All servers set up via lspconfig are automatically installed.
    --   - { exclude: string[] }: All servers set up via lspconfig, except the ones provided in the list, are automatically installed.
    --       Example: automatic_installation = { exclude = { "rust_analyzer", "solargraph" } }
    automatic_installation = false,