feature request: an optional `mason` mapping attribute

[noirbizarre]

Did you check existing requests?

• I have searched the existing issues

Describe the feature

Hello 👋🏼

I would like to add an optional mason attribute to the formatters' definition when the Mason registry entry is not the name of the formatter.

Provide background

I made a plugin, https://github.com/noirbizarre/ensure.nvim, to automatically install dependencies using Mason and I realized that I need to maintain a mapping between conform.nvim formatter names and Mason's.
When I checked a bit how it was done by similar plugins, they are doing the same.

The problems with this approach:

• n separate initiatives leading to n separate maintenance efforts
• each plugin will only have new mapping based on each userbase usage
• onboarding new users using a new formatter requiring a mapping leads to failure on first usage

Having it directly into conform.nvim formatters registry would benefit all those plugins while being very low maintenance (no extra code logic in conform.nvim)

What is the significance of this feature?

nice to have

Additional details

I'm willing to contribute this if you are OK with it.

Note

There is 2 possibles approaches in my option:

1. have a mason attribute only when name is different
2. have a mason attribute as soon as a package is present in Mason registry

Approach 2. has the benefit of bringing an additional info: "this formatter is present in Mason registery" in addition to "here's its name in Mason registry", but it means more mason attributes to maintain.
If you are OK with the contribution, I would take the approach you prefer.

[glmlm]

This is just my personal perspective, but I’m not entirely comfortable with putting the responsibility of inspecting the mason-registry on conform.nvim itself.

That said, speaking purely as an individual user, I would of course be happy if this problem could be addressed without having to maintain a separate mapping table. For reference, the discussion in #104 might also be relevant.

With that in mind, I tried exploring how far this could be handled using only the existing API in my own dotfiles. Below is a minimal example based on that approach:

-- requires mason.nvim and conform.nvim
local all_pkg_specs = require("mason-registry").get_all_package_specs()
local all_formatters = require("conform").list_all_formatters()
local iter = vim.iter
local tbl_keys = vim.tbl_keys

local mason_bin_table = iter(all_pkg_specs)
  :filter(function(pkg_spec)
    return type(pkg_spec.bin) == "table"
  end)
  :fold({}, function(acc, pkg_spec)
    iter(tbl_keys(pkg_spec.bin)):each(function(bin)
      acc[bin] = pkg_spec.name
    end)
    return acc
  end)

local formatters = tbl_keys(iter(all_formatters)
  :map(function(fmt)
    return { mason_bin_table[fmt.name], mason_bin_table[fmt.command] }
  end)
  :flatten()
  :fold({}, function(acc, pkg)
    acc[pkg] = true
    return acc
  end))

vim.print(formatters)

Given conform.nvim's current design, where either name or command contains the actual executable name, this approach ends up being somewhat inelegant. It feels like this is where the discussion should be.

To illustrate, I configured the following settings on my Windows machine:

require("conform").setup({
  formatters_by_ft = {
    html = { "prettier" },
    python = { "ruff_format" },
  },
})

With this configuration, the result of :lua vim.print(require("conform").list_all_formatters()) is as follows:

{ {
    available = true,
    command = "prettier.cmd",
    name = "prettier"
  }, {
    available = true,
    command = "ruff",
    name = "ruff_format"
  } }

I hope this is useful as a reference.

[noirbizarre]

Closing as, following @glmlm advice, I found a better alternative that doesn't require maintaining a mapping.

If you are interested, you can see it in ensure.nvim:

• mason plugin: build a mapping between commands and packages
• conform plugin: resolve tools using this mapping
• nvim-lint plugin: same, resolve tools using the same mapping

Your solution is actually superior:

• works for any kind of Mason package tool (scale to LSP servers too)
• doesn't require maintaining any mappings in repository
• works with custom registries
• works with user custom formatters/linters if they exist in Mason

So thank you @glmlm !!

[glmlm]

@noirbizarre Glad to hear this was helpful. I’ve opened a feature request in mason.nvim regarding this(see mason-org/mason.nvim#2047). If it gets accepted, the implementation may become much easier.