Current state of affairs
elm-review only looks at a single project at a time at the moment, so it is not possible for it to work with multiple projects at once.
What I would probably do in your shoes is to treat the third project as a package, as you suggested. In this case, I think you only have to ignore the
NoUnused.Exports rule for that source directory, meaning you would not lose out on too many reports, especially if you have an IDE which shows you how many times something is used in the rest of the codebase. I’m not sure that the Elm Language Server and the IntelliJ.plugin give you that out of the box, but I know that some plugin for Atom does that
You can potentially try to run
elm-review from time to time without doing that, to notice and manually remove the elements that are unused in both of the other projects.
In the future?
I don’t think allowing for multi-repos is impossible, but it would require quite some work on the tool itself, and likely some setup on the user’s side too.
What does a “multirepo”-style setup mean? It means that we would run
elm-review by targetting multiple
elm.json files, which has several implications.
Finding the elm.json files
The user now needs to run the
elm-review CLI (or in their IDE when we get to that point) by configuring it to run with all of the
elm.json files. Sometjing like
elm-review --elmjson project1/elm.json,../../project2/elm.json,project3/elm.json. I would imagine that this is error-prone, because if you forget to include one project (or include one too many ) , then you can get false positives or false negatives.
elm-review loads the dependencies of a project. When we look at a single project, it is relatively simple. But when we look at multiple
elm.json, we somehow need to merge the dependencies of each project, with potentially some conflicts.
For instance, if one project depends on package A v2, and an other depends on package A but v1, but where the code compiles because they only use the unchanged API present in both versions. Our dependency solver wouldn’t be able to resolve a correct set of dependencies.
Alternatively, we could make it so that
elm-review rules (like
NoUnused.Exports) are aware of the multiple projects and know which files is included in which
elm.json's source-directories, with
elm-review not trying to resolve dependencies to a single set, but I think that would introduce a lot of complexity and I’m not sure that would even work out.
I don’t know if there is a good solution to this honestly. I’m very curious as to what @brian came up with and whether it’s something that
elm-review can leverage out of the box, and learn whether it causes a set of false positives or false negatives.
I would love some ideas, but this will probably not be addressed for a while, considering I have little insight in how to resolve it at the moment.
If you know of similar tools that solved this problem in other languages/ecosystems, I’d love to know!