Unconsistent behavior of prefer_local and local_only

[drybalka]

Let us consider a situation where both a local and a global eslint are present and see which one of them is used for different settings:

1. null_ls.builtins.diagnostics.eslint - local. Ok, perhaps. However, the presence of prefer_local in the documentation suggests to me that the default should be global, no? The reason is that the dynamic_command is preferred over command here

   null-ls.nvim/lua/null-ls/helpers/generator_factory.lua

   Lines 271 to 275 in ac5f450

   	if dynamic_command then
   	resolved_command = dynamic_command(params)
   	else
   	resolved_command = command
   	end

   and the default dynamic_command for eslint is

   null-ls.nvim/lua/null-ls/builtins/diagnostics/eslint.lua

   Line 45 in ac5f450

   dynamic_command = cmd_resolver.from_node_modules(),

2. null_ls.builtins.diagnostics.eslint.with({prefer_local=false}) - local. Hmm, now that is strange. I would assume from the formulation that the global eslint should be used in this case. Is there a way to use the global eslint at all? In fact, setting prefer_local to false has no effect whatsoever according to this

   null-ls.nvim/lua/null-ls/helpers/make_builtin.lua

   Line 84 in ac5f450

   if prefer_local or only_local then

3. null_ls.builtins.diagnostics.eslint.with({prefer_local=true}) - global. Now this is unexpected =) The reason are these lines

   null-ls.nvim/lua/null-ls/helpers/make_builtin.lua

   Lines 84 to 93 in ac5f450

   	if prefer_local or only_local then
   	local maybe_prefix = prefer_local or only_local
   	local prefix = type(maybe_prefix) == "string" and maybe_prefix or nil
   	local resolver = cmd_resolver.generic(prefix)
   	generator_opts.dynamic_command = function(params)
   	local resolved_command = resolver(params) or (prefer_local and params.command)
   	return resolved_command
   	end
   	end

   The prefix in this context is nil and that's why the default (and correct for eslint) dynamic_command = cmd_resolver.from_node_modules() is substituted by cmd_resolver.generic(nil).

Similar behavior is also true for the local_only variable. In addition to that the situation is even more confusing when eslint_d uses the local version of eslint.

It would be cool if the behavior was better defined.

[jose-elias-alvarez]

The reason for the inconsistency is historical: originally, we had prefer_local and only_local, but as we moved closer towards sensible behavior out-of-the-box, we wrote command resolvers (and eventually set them as defaults once we had better solutions to avoid performance issues). For most cases, simply registering the built-in for Node-based sources should "just work," but as you've noted, there are a lot of weird cases where the options don't interact as expected.

Ideally, I'd like to phase out only_local and prefer_local completely in favor of the approach we are using for Node-based sources. Generally, I think local executables adhere to predictable project structures, and so I think handling them by default is ideal (and users with unusual needs would still be able to override the command).

[drybalka]

Isn’t eslint a Node-based source? Or what exactly do you mean?

[jose-elias-alvarez]

Yes. What I meant is that just registering eslint as a source should handle the majority of cases without needing to use prefer_local or only_local. Ideally, that should be the case for all sources where it's common to use project-local executables.