Resurrecting an old topic, oops!
I generally like dialyzer/dialyxir, especially when you can start a project with them from the beginning.
However, adding it mid-project for a large Elixir service is a major pain, especially when it comes to CI.
I’d love to be able to do something like:
To that end, I made a GitHub issue to ask for ideas on this subject:
If I had to pick I’d prefer writing specs for libraries, personally. Partially because it provides guidance for usage in ex_doc, and partially because the more that libraries do, the more value that spec-less applications can get from dialyzer via inference without writing a single spec, to make sure that library/framework dependency calls in your application are flowing the right input/output types to each other.
Just to clarify:
I think you’re right about type specs. They’re more valuable in libraries. But my comment was about dialyzer, which for libraries (aka in isolation) often has a hard time finding incorrect specs. Those incorrect specs will then surface in projects using those libraries being plagued by dialyzer errors, where in the worst case neither the users code, nor the library code is technically incorrect, everything works, but dialyzer complains. And dialyzer might even point to the users code for the warning instead of correctly identifying the incorrect typespec in the library.
I don’t think I’m using Dialyzer, just learning. I like types when they were made for the language. Bolt-on typecheckers often have the kind of holes you just descripted. The only one that sort of worked for me so far was typescript. And same as some others described for elixir type solutions above, adding that to an existing code base is non-trivial.