Not by hand (thank goodness). I made an elm-review-bot that is designed to run elm-review rules against Elm packages. It is hosted with Lamdera and is 100% written in Elm (the only things that aren’t Elm is a .gitignore and a README.md).
For now it only uses NoUnused.Dependencies. When someone publishes a new version of their package, it checks for unused dependencies in that package and if it finds any, it creates a pull request (here’s an example). This is to help reduce dependency conflicts for the end user*.
Some future things this bot could do are:
Fix incorrect Elm version ranges
Warn if any dependencies for a package get renamed or removed
Make sure that all the types used by exposed functions are also exposed
Check for dead links in documentation
In the long term I hope that the compiler will do some of these checks but in the meantime, hopefully this bot can improve the package ecosystem a little bit.
Thank you @jfmengels and @supermario for helping me with elm-review and Lamdera respectively.
*One thing I’m not sure about is if pull requests should be made when there’s only unused test dependencies. Test dependencies don’t affect anyone else but maybe it’s still useful to get rid of the ones you aren’t using? Or maybe it’s just annoying to be bothered with that?
When I ran the bot against the latest version of all the existing packages (roughly 1300 packages), it failed to parse 14 of them. I think in 5 cases it was because I found bugs in elm-syntax. In the other cases it was because of 0.18 test modules in an 0.19 package. I guess I could generate github issues for those (and also check for 0.18 examples) but it doesn’t seem like it happens so often?
Also got some PRs in the mail. Always pleasant to receive something free AND useful, and coming from elm-review I trust the results more than some of the other auto generated PRs I get from GitHub. Nice idea, thanks for doing it.
Hrm, if I just go by elm-package.json beeing there, it’s way more packages ~139. But some of these might be okay (still very confusing, to have 0.18 sources and 0.19 sources in one library branch)
Interesting. The elm-review-bot only checks modules that are in tests/ or are in src/ and are used by the package. I guess it’s possible that there’s 0.18 code living outside of those folders or maybe an 0.18 app is using the same code but the modules happen to be both valid 0.18 and 0.19 code. Or maybe the elm-package.json is the only thing left from the 0.18 package.
