Linting Entire Projects

[w0rp]

ALE has been focused on linting a single file at a type as you type for a long time. The functionality of ALE for doing this has been working so well for my personal work that I haven't felt the need to add much of anything to ALE for about half a year: it does what I want and I don't want much else. I've been thinking of something I would like to see in ALE, and that's an issue that came up a long time ago: Linting entire projects. (The earliest issue I could find is #669, and the most recent is #3524.)

It's possible to add functionality to ALE for linting an entire project, provided the following restrictions are applied.

1. For a linter to to check an entire project it must either be:
   1. A linter with a new project_command option defined for it, optionally project_root.
   2. An LSP linter whose server supports commands to check an entire project.
2. The cwd for the command for running against the project will be set to the project root. A new ale_root option will deprecate and replace the ale_lsp_root option, and function in exactly the same manner, but for linters that check entire projects.
3. Results for projects will always populate the quickfix list, and in order to use a list for problems local to a file you will have to use the loclist instead. You cannot populate local errors in the quickfix list at the same time that you're populating the quifckfix list with project-wide errors.
4. Errors in projects will not show visual cues for them, they will just populate the quickfix list and possibly ALE's own lists so you can jump through errors. Linters should separately run on files as you type to point out problems that can be seen from looking at only one file. This can be amended in future, but only after just the most basic functionality is working first.
5. Problems parsed from callback functions will be discarded when running over a whole project if they are lacking the bufnr or filename keys.
6. Checking an entire project will only be invoked via an ALELintProject command, never automatically.

As a pre-requisite for this work, #2281 will have to be implemented first, so the working directory for commands can be separated from the commands, such that the working directory can be swapped out when running against an entire project.

The project_command option implies that some linters will have _project_options settings, in addition to _options, so separate arguments can be set when checking entire projects. I know I personally use two different ESLint configuration files for checking individual files and projects, because the full type-aware configuration is too slow.

The support table will have to be updated to indicate which linters support checking an entire project. They won't all support it overnight. ESLint will probably be the first linter that gets this kind of support just because I happen to use it.

[w0rp]

I've added the ale_root setting to deprecate ale_lsp_root. The old settings will quietly continue to be loaded until some time in the future when support for them can be removed.

[WhyNotHugo]

Given that ALE is a plugin inside an editor, I feel it would be very weird for it to operate on other files.

I definitely never want to know about issues on files different than the one I'm working on. The performance cost sounds like it would be non-negligible too.

This kind of functionality, IMHO, fits in better in things like pre-commit.

[mcmire]

This would be helpful for statically typed languages like TypeScript or Elm, where if you are making wide changes, you really want to get a sense of whether the entire project is in a good state before you attempt to run your code. The present alternative is to go through your files and save them one by one, checking for type errors, which is cumbersome. So I would find this functionality useful. Knowing that this would be an opt-in, on-demand feature is nice.

[skanev]

A massive +1 here.

I use ALE mostly for Rubocop, and it's great that it shows me the offences inline. However, especially when working with projects that don't fully lint, I'd like to get all the offences, load them in the quickfix list, and go through them one by one to see whether I have something fix quickly (pun not intended). Right now I just end up running rubocop piped to a file and then I load it with :cfile. Works, but annoying and not really ideal. Being able to run an occasional command to do that would be golden.

I actually started using neomake for that, but it has its troubles (getting rubocop to run with bundler, for example, is challenging; also no status indicators).

Adding a :ALELintProject (or :ALEProjectLint) would be amazing.

[w0rp]

@WhyNotHugo You'll never know the feature is there if you don't use :ALELintProject.

[w0rp]

I'm going to close this issue, as I have decided against it, because there's a much better solution I will work on in future. It is this: https://github.com/w0rp/report-alchemy

I won't say too much about that project, and I won't start on it probably any time soon, but here is my thinking.

1. Make it easy to convert results of all kinds of existing CI checks in codebases to various formats.
2. Enhance visibility of problems with code for more than just Vim users.
3. Later on... make it easy to populate quickfix or similar with results of a report, perhaps as an entirely separate plugin that can go alongside ALE.

As that little guy in The Mandalorian says, "I have spoken."

[w0rp]

To add a little more. I think it would be a great shame to complicate ALE's code with a totally different way of looking at projects. Shoving in "project wide linting" support would make it harder to maintain the simple "lint as you type" behaviour that ALE is good at. By keeping things separated, people will get a better experience all around later.