Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set the cwd for each linter #646

Closed
lopi-py opened this issue Aug 29, 2024 · 3 comments
Closed

Set the cwd for each linter #646

lopi-py opened this issue Aug 29, 2024 · 3 comments

Comments

@lopi-py
Copy link
Contributor

lopi-py commented Aug 29, 2024

Let's say I have a project with the following structure:

project/
├── src/
│   ├── init.lua
│   └── foo.lua
├── selene.toml
└── subproject/
    ├── src/
    │   ├── init.lua
    │   └── bar.lua
    └── selene.toml

Currently, nvim-lint will set the cwd to the Neovim cwd, project in this case, but when trying to edit subproject/src/init.lua, the cwd should be project/subproject so selene will pick the correct configuration file

My proposal is to add a cwd field to the linter config

return {
  cmd = "selene",
  ...
  cwd = function(config, bufnr)
    return require("lint.util").root(bufnr, "selene.toml")
  end,
}

Would you be open to a PR to address this?

@xudyang1
Copy link
Contributor

xudyang1 commented Sep 26, 2024

The following config may help you:

local opts = {
  events = {
    -- loading buffer after nvim-lint: event="BufReadPost"
    "BufReadPost",
    -- some linters require saving file
    "BufWritePost",
    "InsertLeave",
    -- more aggresive (e.g., undo)
    "TextChanged",
  },
  linters_by_ft = {
    lua = {
      "selene",
      -- "luacheck",
    },
    github_action = {
      -- Static checker for GitHub Actions workflow files
      "actionlint",
      -- general yaml linter
      "yamllint",
    },
  },
  root_patterns_by_ft = {
    lua = {
      selene = { "selene.toml", ".git" },
      -- luacheck = { ".luacheckrc", ".git" },
    },
    github_action = {
      yamllint = { ".yamllint.yaml", ".yamllint.yml", ".yamllint" },
    },
  }  
}

local lint = require("lint")
local api = vim.api
local fs = vim.fs
lint.linters_by_ft = opts.linters_by_ft

---Set cwd for linters specified by opts.root_patterns_by_ft[filetype]
---@param linter_root_patterns table<string, string[]>? a mapping of linter to patterns
local function set_linters_cwd(linter_root_patterns)
  for linter, root_patterns in pairs(linter_root_patterns or {}) do
    local root_path = root_patterns and fs.root(0, root_patterns)
    if root_path then
      lint.linters[linter].cwd = root_path
      -- you can set cwd to buffer's parent dir if no root is found
      -- else
      --   lint.linters[linter].cwd = fs.dirname(api.nvim_buf_get_name(0))
    end
  end
end

local lint_augroup = api.nvim_create_augroup("nvim-lint", { clear = true })
api.nvim_create_autocmd(opts.events, {
  group = lint_augroup,
  callback = function()
    if filetype == "yaml" and string.find(path, ".github/workflows/") then
      set_linters_cwd(opts.root_patterns_by_ft.github_action)
      lint.try_lint(opts.linters_by_ft.github_action)
      return
    end
    set_linters_cwd(opts.root_patterns_by_ft[filetype])
    lint.try_lint()
  end,
})

@mfussenegger
Copy link
Owner

I have no plans to allow setting the cwd on a per linter level but try_lint already takes a cwd option.

@fredrikaverpil
Copy link
Contributor

fredrikaverpil commented Oct 3, 2024

I'm not sure I understand... it's already possible to set the cwd per linter...?

{cwd?} (string)

handle, pid_or_err = uv.spawn(cmd, linter_opts, function(code)

Note that uv.spawn (or vim.loop.spawn) supports cwd, just as it is currently passed into it today (uv.spawn docs).

I'm actually doing it myself for one linter I'm debugging at the moment. I can set the cwd (just like how I set args) and then in the parser function, I'm printing the linter_cwd to verify that this cwd is indeed used.

What's not currently supported is to provide the cwd as a lua function, which is what I'd like to do too actually, so I opened up this PR: #674

or... did I misunderstand something?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants