Currently, `elm-review` only looks at a single file at a time, and when it looks at another file, it has forgotten about the previous file. This is fine for a number of rules, but in a lot of cases, if you want to report problems completely, then you need to be able to know what is happening in multiple files.
Here are a few examples:
- You want to know when a module is never used. For that, you need to go through your whole project, register the used modules, and report the ones that were never imported.
- You want to know when a type constructor of an custom type is never used. If the type is opaque or not exposed, this can be done currently without needing to look at other files. But if the type's constructors are exposed, then you need to know if other files use them.
## Problems to fix
- [X] Be able to have a list containing single file and multi-file rules.
Users should not have to care if the rule is for a single or multiple files
- [X] Be able to create a multi-file rule
- [X] Be able to specify a multi-file rule's file visitor
- [X] Using the same functions as for a single rule
- Solve cases where you may want to re-review a file
- Need to know what the interface of a module is (what do `import Html exposing (..)` and `import A exposing (B(..))` bring into the scope?).
- Providing the signatures of modules should suffice.
- For internal files, https://package.elm-lang.org/packages/stil4m/elm-syntax/latest/Elm-Interface
- For dependencies, load them one way or another (TBD)
- Need to know the contents of a function body (does this function use `Html.lazy`?) or type (does this type alias to or wrap a function?)
- The imported files should be analyzed before the importing file, and the resulting context should be available using `withInitialContext` or a similar function.
- This may warrant a different function or an additional parameter to create the rule, so that `elm-review` knows in which order files should be analyzed. (Maybe `withInitialContext` and its alternative can do that job)
- When loading the files, it's probably worth creating an acyclic graph of files by the way they import themselves imports can probably be created so as to know the order in which. The code using `elm-review` should only have to collect the files, but should not have to create the graph itself. This might be a bit similar to what is being done with https://package.elm-lang.org/packages/stil4m/elm-syntax/latest/Elm-Processing#ProcessContext.
- When a file gets updated, the files importing it get re-evaluated, and so on (until the resulting context is the same as before).
- It should be possible to add or remove files from the graph/list of files, to prepare for a potential watch mode.
