The thing I think all of these dialyzer packages could use is a “Getting Started” guide that handles a bunch of common issues that show up when using it with Elixir. I’ve tried to use it on various projects before and it raises all kinds of issues about protocols, various functions that are missing, etc.

I can get used to reading the erlang output of the errors themselves, I just don’t know what to do with all the “missing function x” stuff where x definitely exists.

Hey, thanks contributing in this space. I wish you’d consider contribution to dialyxir but competition is healthy too.

Still, there are only two other dialyzer solutions for Elixir that I know of, and one of them is dormant and redirects to Dialyxir, which I maintain. So, when you say in your README “Existing Solutions may not…” - its hard not think of it as referring to anything else; but maybe that’s just my perspective.

Anyway, for the record:

These features you mention exist in Dialyxir:

• ANSI-colored output.
• Exits non-zero when dialyzer produces warnings (good for continuous integration usage).
• Calls the dialyzer OTP library directly rather than shelling out to the executable (it used to shell, but hasn’t since 0.5 which was released in February).

These do not:

• Defaults to the strictest set of warnings available in Dialyzer, except for the few that are overly expensive. - This is a non-goal and in fact how Dialyxir behaved for its first couple of years of life. Fish’s argument convinced me its not the best for the community (and some of the costs are externalized from the project mainter, to Stackoverflow, IRC, and the forums). Of course you can turn on more flags, and I could see adding strict options to turn that set on all together but if you want a different default, maybe we need two different packages…

• Layered PLT files - Dialyxir maintains separate Elixir and Erlang PLTs but combines them with the application dependences in the project directory - Using multiple separate files at runtime is a better idea and would be worth adding.

• Ability to ignore acceptable warnings based on match patterns. - This is probably worth adding to Dialyxir. The current string-based ignore matching is easy to understand and use but not as flexible.

Finally, I’d encourage you to read Jose’s issue on Dialyxir. Interpretation and explanation of the error messages produced by Dialyzer is one place there is really a lot of room of improvement and innovation in this space.

I like the idea and have long thought it is needed. Still, there are lots of details to work out. The warning could get fixed in another module - e.g. in the function head rather than the call site, so I don’t think just looking at the time-stamps would quite do it. Also should it go on reporting warnings in files that haven’t changed? I would guess a language server doesn’t have to worry about that because the editor can maintain the list of previously reported warnings, but probably a mix task should go on reporting them.

Honestly I had not kept up with Elixir-LS, its really come quite far. Editor integration is how Dialyzer should ideally be used for interactive purposes.

The mix tasks are good for CI but maybe we need to focus on getting Elixir-LS into every editor and rally around that.

Thanks for that comment, Ben. One thing that I personally forget sometimes is that I’ve worked for a long time with Dialyzer and understand most of the warnings. I’ll prepare a guide to them soon.

Last week I updated dialyzex to use the “onion” PLT construction pattern described by James, meaning that the mix task will still build three PLTs, but they are no longer disjoint. To illustrate:

This should be nearly as fast as before when constructing PLTs, and the analysis phase seems unaffected.

Version 1.1.0 is available on Hex.