I’m fairly sure the Elixir team doesn’t do this, it seems like it would require a lot of extra work and processing power on their part. As of now, they are recommending that people add the master branch to their CI systems so that libraries will be built against master and the authors/Elixir core team can catch issues similar to what you are describing. I agree it would be nice, but without a big company like Mozilla backing Elixir, I’m not sure they have the infrastructure/time for it.
Fun idea. Made it my evening project. GitHub - aseigo/hexagon
Am running it on my laptop right now with Elixir 1.7.1 and Erlang 21.0.4 … let’s see what happens. If the community feels it would be actually useful, I could run it regularly on servers at work. Could also extend it with other checks, e.g. perhaps harness credo to do some static analysis.
It is pretty bare-bones … perhaps logging with json would be nicer for later usage. Also just noticed it fails for rebar projects, which should be easy enough to fix. So rough edges, to be expected for a few hours thrown at a project, I guess … improvements welcome 
It has already found packages with problems, e.g.:
== 23:15:30.197
FAILED at compile: /home/aseigo/packages/ex_loader/0.4.1
errors: could not compile dependency :pre_commit_hook, "mix compile" failed. You can recompile this
dependency with "mix deps.compile pre_commit_hook", update it with "mix deps.update pre_commit_hook"
or clean it with "mix deps.clean pre_commit_hook"
Neat.
edit: bonus round … Since I had them on disk already, I ran cloc over the entire set of packages. https://exote.ch/~aseigo/state_of_hex.txt
11 Likes
It might be worth it to work something out with the hex.pm guys where you can update hex.pm project pages if you find vulnerabilities while doing the static analysis.
Yes, if I get this working sufficiently well I will definitely reach out to the hex.pm team. It will be most useful if we can provide some feedback loops, including notice of build breakage, e.g.
1 Like
