Declare multiple time the same formatter but with different settings

[Nargonath]

I'm using prettierd as a formatter for many different filetypes. I use the default builtin prettierd object for yaml, json and markdown however for javascript I use a conditional since I need to either use eslint_d or prettierd depending on the configuration file present in the project root. Here is my attempt:

nullLs.config({
	sources = {
		require("null-ls.helpers").conditional(function(utils)
			local usesEslint = vim.fn.glob(".eslintrc*") ~= ""
				or (
					utils.root_has_file("package.json")
					and vim.fn.filereadable("package.json")
					and vim.fn.json_decode(vim.fn.readfile("package.json"))["eslintConfig"]
				)

			return usesEslint and nullLs.builtins.formatting.eslint_d
				or nullLs.builtins.formatting.prettierd.with({
					filetypes = { "javascript" },
				})
		end),
		nullLs.builtins.formatting.prettierd.with({
			filetypes = { "json", "markdown", "yaml" },
		}),
	},
})

The problem is that the prettierd formatter is not used for json, markdown or yaml anymore but only for javascript which means only the first conditional declaration is used. IMO I cannot merge both prettierd sources since I always want to use prettierd for files other than javascript and conditionally use it for javascript.

Is there a way to perform such a task that I'm not aware of?

Thanks for your help.

[jose-elias-alvarez]

It's dirty, but it's possible to do this by copying the built-in, changing the name, and setting _opts directly (since with references the original object):

local null_ls = require("null-ls")

local prettier = null_ls.builtins.formatting.prettierd
prettier._opts.filetypes = { "json", "markdown", "yaml" }

local prettier_javascript = vim.deepcopy(prettier)
prettier_javascript.name = "prettier_javascript"
prettier_javascript._opts.filetypes = { "javascript" }
setmetatable(prettier_javascript, getmetatable(prettier))

local sources = {
    require("null-ls.helpers").conditional(function(utils)
        local usesEslint = vim.fn.glob(".eslintrc*") ~= ""
            or (
                utils.root_has_file("package.json")
                and vim.fn.filereadable("package.json")
                and vim.fn.json_decode(vim.fn.readfile("package.json"))["eslintConfig"]
            )

        return usesEslint and null_ls.builtins.formatting.eslint_d or prettier_javascript
    end),
    prettier,
}

Definitely open to suggestions / PRs to improve this, since it's not pleasant to look at, but it should work. Ideally each built-in would be a unique copy from the start so you could do what you wanted to do originally.

[Nargonath]

Thank you @jose-elias-alvarez for your solution. I kinda expected there might be a solution by deep cloning the builtins but I wasn't sure how to perform it.

As a suggestion, it could be nice to expose this behavior as another method as with but naming it fork for example. This would have the same API has with so you can override settings but underneath it deep clones the object for you effectively creating a new copy of the built-in:

null_ls.builtins.formatting.eslint_d.fork('myNewForkName', { filetypes = {'javascript'} })

Another solution would be to do something like that:

null_ls.builtins.formatting.eslint_d.fork('myNewForkName').with({ filetypes = {'javascript'} })

Now with would be pointing to the new cloned builtin instead of the original object.

We could also change with so it never changes the actual source builtin but rather always deep clone.

What do you think?

[Nargonath]

The more I think about it the more I like the third option. Having an immutable behavior to with would IMO handle more different use case with minimal breaking changes while not cluttering the API with even more functions.

[jose-elias-alvarez]

I also like the third option, perhaps with a name like clone. I have to think about how to restructure with so that it references the cloned built-in and not the original object, but it should be possible.

[Nargonath]

So you'd want to rename with to clone? I thought you'd prefer not to introduce a breaking change for existing users but if you're okay with that I'd suggest fork instead. Usually we don't expect clone to take arguments, don't you think? I also think that we could keep with and just mention the new immutable behaviour in the documentation, that'd be fine.

[Nargonath]

Also there was something that didn't work for me in the code you gave above. I had to replace prettier._opts.filetypes = {...} by prettier.filetypes = {...} and same goes for prettier_javascript otherwise it works great.