zls icon indicating copy to clipboard operation
zls copied to clipboard

Local ZLS config per project

Open BrookJeynes opened this issue 1 year ago • 13 comments

Remember to search before filing a new report

It would be nice to be able to include a zls.json file within a project to maintain styling on a per project basis.

BrookJeynes avatar Dec 25 '23 23:12 BrookJeynes

The strongest and only reason, to me, is being able to tell zls to use a specific zig version for a given project.

Con: Can't publish it - paths have to be absolute, preferences are subjective/should be personal choice.

What's viable: Make use of the version field in build.zig.zon - it would require new fields in zls.json, eg zig_011_exe, zig_012_exe, etc, with zig_exe_path being the default/fallback.

And it still would be subject to backwards compatibility availability.

llogick avatar Dec 26 '23 02:12 llogick

@BrookJeynes What config options do you intent to configure on a per project basis? Since you referenced "styling", the warn_style or highlight_global_var_declarations config options perhaps?

Techatrix avatar Dec 29 '23 04:12 Techatrix

@Techatrix yeah, pretty much just those currently. I was also thinking ahead of time if ZLS ever becomes something like clangs formatter where you can change bracket styles, etc.

BrookJeynes avatar Dec 29 '23 09:12 BrookJeynes

The warn_style and highlight_global_var_declarations config options are kind of an outlier here. I would rather have these options be removed from the ZLS/LSP options so that no per project config is necessary. Instead, these options should be part of a Zig Linter instead of ZLS/LSP. Of course a Linter can be part of/integrated into ZLS but it should definitely be separately configurable.

I was also thinking ahead of time if ZLS ever becomes something like clangs formatter where you can change bracket styles, etc.

Anything formatting related is out of our control since its based on zig fmt which deliberately has no config options.

Techatrix avatar Dec 29 '23 09:12 Techatrix

@Techatrix yeah, upon rethinking this, zls is more the lsp rather than a linter and so having a per project config doesn't really make sense here. sorry for the confusion on my part.

BrookJeynes avatar Dec 29 '23 10:12 BrookJeynes

I am using per-project zls.json files by providing the local file as a parameter when starting the server zls --config-path zls.json. This is useful for configuring build_on_save_step, which varies between projects.

lawrence-laz avatar Feb 19 '24 21:02 lawrence-laz

Hi, sorry for being confused here :) I want to use the nominated zig build (or any specific Zig build really) for my project, but also be able to have any other Zig version on my PATH (for bug reproing or whatever), is it possible to set up ZLS / VS Code for this? If so, could someone provide a guide?

Srekel avatar Mar 19 '24 07:03 Srekel

The VS Code extension will use whatever Zig binary set in zig.path so as long as you point that to your nominated Zig build it should just work.

Vexu avatar Mar 19 '24 09:03 Vexu

I am using per-project zls.json files by providing the local file as a parameter when starting the server zls --config-path zls.json. This is useful for configuring build_on_save_step, which varies between projects.

This is a great idea! Here's an example using Neovim + nvim-lspconfig:

require('lspconfig').zls.setup({
  on_new_config = function(new_config, new_root_dir)
    local zls_global_cfg = vim.fs.normalize('~/.config/zls.json')
    local zls_local_cfg = vim.fs.joinpath(new_root_dir, 'zls.json')
    local zls_cfg = vim.fn.filereadable(zls_local_cfg) == 1 and zls_local_cfg or zls_global_cfg

    new_config.cmd = { 'zls', '--config-path', zls_cfg }
  end,
  -- other setup options...
})

This will use the local zls.json config file if it's available in your project root, otherwise it falls back to ~/.config/zls.json.

weskoerber avatar Aug 16 '24 19:08 weskoerber