Flag to enable type checking per file in a project about gradualizer HOT 6 CLOSED

I think it is a good suggestion. I would like a type checker to be able to detect as many badarg errors in runtime as possible.

This can already be done in the build scripts and tools for each project. For small projects, I think it can be enabled in one go. It could be enabled using configuration in the rebar config file or Makefile. For larger projects, a build tool can make use a list of files to type check. A continuous integration tool can keep track of the number of errors and to highlight new errors introduced by a commit or a build.

In the long run, I think is a reasonable that a typechecker (this or another) becomes part of the Erlang compiler. Compiler options such as nowarn_type_error could be added. Erlang has a syntax for types that the compiler doesn't check, apart from the syntax of the types. It seems like the language designers have somehow prepared for a type checker which doesn't exist yet. (Dialyzer doesn't really use the type specs. The annotations are basically just used for documentation, by tools like EDoc.)

Compile options can also be added in each file, using e.g. -compile(nowarn_type_error).

from gradualizer.

I agree this is a good, practical idea. Gradualizer itself already works on a per module basis (gradualizer:type_check_file) so this could be the responsibility of the build tool plugins. The cli you created already takes a list of files as arg so it already supports this "large project one-by-one" approach.

from gradualizer.

@Zalastax, good idea! I've created an initial page and given you permission to edit. Knock yourself out :-)

from gradualizer.

@gomoripeti I think you're absolutely right! If I understand the source correctly, gradualizer mostly (only?) reports errors for the modules you list and there isn't really a need to add the concept of a project since gradualizer keeps a database of types running in between the separate calls to gradualizer:type_check_file.

Is there anything actionable here or should we just keep this in mind for the future? I feel there might be some nugget worth documenting but not sure what exactly.

from gradualizer.

@Zalastax, the actionable thing might be to document this in a user documentation. We currently don't have any such documentation sadly, apart from the rudimentary info in the README. Feel free to create some initial documentation if you're up for it.

from gradualizer.

I think the Wiki could be a good initial place for that. @josefs can you enable it / create an initial page / let me edit it?

from gradualizer.