Analyzes Elm projects, to help find mistakes before your users find them.
Go to file
2017-01-29 22:53:31 +01:00
example Add lintSource function that lints a file with a list of rules 2017-01-29 21:49:05 +01:00
src Add documentation for every rule inside the source 2017-01-29 22:50:48 +01:00
tests Add documentation 2017-01-29 21:35:00 +01:00
.gitignore Init project and copy example from bogdanp/elm-ast 2017-01-07 18:30:16 +01:00
elm-package.json Add documentation 2017-01-29 21:35:00 +01:00
README.md Remove license in README 2017-01-29 22:53:31 +01:00

elm-lint

An Elm linter written in Elm. Get your code from correct to better. You can learn about the API and the rules it provides on the package documentation.

Try it

This is a prototype, so there is no CLI yet, but you can test elm-lint online here. Enter your source code in the top-left box, and see the reported errors in the bottom-left box.

Please note that the tool that analyzes your code has parsing issues and valid code may not be considered as such.

What does this tool do?

elm-lint analyzes your Elm source code, and tries to recognize patterns that may be considered harmful. If you are familiar with ESLint from JavaScript, this is pretty much the same idea.

You can read the slides for my presentation of this tool to learn more about it.

Rules

  • DefaultPatternPosition - Enforce the default pattern to always appear first or last.
  • NoConstantCondition - Forbid the use of expressions in an If condition whose value are always the same.
  • NoDebug - Forbid the use of Debug before it goes into production.
  • NoDuplicateImports - Forbid importing the same module several times in a file.
  • NoExposingEverything - Forbid exporting everything in your modules module Main exposing (..), to make your module explicit in what it exposes.
  • NoImportingEverything - Forbid importing everything from your module. This can especially be confusing to newcomers when the exposed functions and types are unknown to them.
  • NoNestedLet - Forbid nesting let expressions directly.
  • NoUnannotatedFunction - Ensure every top-level function declaration has a type annotation.
  • NoUnusedVariables - Reports variables that are declared but never used.
  • NoUselessIf - Reports when both paths of an If expression result will lead to the same value.
  • NoUselessPatternMatching - Reports case expressions that can be simplified. Either when all patterns will lead to the same value, or when a pattern will lead to the same value as the default pattern.
  • NoWarningComments - Detect comments containing words like TODO, FIXME and XXX.
  • SimplifyPiping - Simplify piped functions like List.map f >> List.map g to List.map (f >> g)

More rule ideas in this slide and the ones below it. Note that some rules were implemented but may not be good ideas. Think for yourself and ask the community whether you should enable them.