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.