dense-analysis / ale

Check syntax in Vim/Neovim asynchronously and fix files, with Language Server Protocol (LSP) support
BSD 2-Clause "Simplified" License
13.57k stars 1.44k forks source link

Whole Project Linting #4613

Open w0rp opened 1 year ago

w0rp commented 1 year ago

I've thought about how to handle whole project linting for years, and I think I finally have a good idea of how to handle it.

  1. Allow an optional project_command key to be set for linters to define a command to explicitly use for running linters over an entire project.
  2. Allow project_root to be defined for non-LSP linters for setting the cwd to use for a project command. We can make this optional for tools that don't require a specific work directory, and define that any configured root will be used as the cwd of a project command, such as through ale_root.
  3. Discourage use of quickfix for storing the results for a single file at a time, and make errors for a whole project available in quickfix. Note in documentation that you probably can't use both at once.
  4. Note in documentation that Language Server Protocol currently does not offer a way to get a list of all problems for an entire project.
  5. Require an explicit command to be run to get problems for an entire project. There can be no automatic linting of an entire project.
  6. Allow project_command and callback to be defined for language server linters, so they can separately launch an executable to find all errors. See Pyright for example.
  7. We will define that callback may be called for either file-specific or project-wide errors if a linter is configured to permit project wide linting.
  8. Note in documentation the subset of linters that specifically implement project-wide linting.
  9. Print a warning when no linters enabled for a buffer support project-wide linting.

The implementation details are complicated, but we can implement this. It will be complex, but worth doing.

My recommendation for implementing how to get ALE to display project-wide problems across different buffers is to implement project wide collection of problems in its own file and define it to use the "other sources" API as if it were a separate plugin. That will prevent the engine code from being complicated by project-wide linting, and will make the addition of project wide linting nearly zero added cost for users who don't use it.

We can make project wide linting populate quickfix while sending the problems per-buffer to ALE's usual rendering of problems.

w0rp commented 1 year ago

Another detail I'm considering, which doesn't have to be a part of the first version: allow linters to be defined as solely project-wide linters.

I think it will also be good to use the word "sticky" in documentation to describe problems from project wide linters. Problems for them will stick around until you re-run them. We will probably need to finally add a command that just clears problems for a linter, project-wide or not. There's possibly a command from Syntastic we can name our command after, if it makes sense.