ESLint equivalents in Elm

[jfmengels]

In the JavaScript community, ESLint is a widely adopted linter for JavaScript that is a huge help in making JS code more maintainable.

In the Elm community, the closest equivalent is elm-review, but that one has a lot less rules than ESLint (and not because I’m not writing them). That is somewhat understandable because we already have a compiler checking for some of those issues, and we have elm-format to handle styling-related issues.

@supermario and I thought it would be really interesting to see how many of the ESLint rules applied in the Elm ecosystem. So I went through every single one of the 263 “core” ESLint rules (not from packages, there are so many that it’s not even funny to consider doing) and noted that down.

It was a bit hard to categorize everything (some things can fit into multiple categories), but I tried my best to be objective.

The results can be found below. Huge thanks to @supermario for editing the article and talking me into researching this. Note that some of the things are interactive

ESLint equivalents in Elm

[dta]

Thanks for doing this work! I noticed that the spaced-comment rule is not marked as being handled by elm-format, and is also not marked as a potential improvement for that tool. That one seems like it would be an improvement if it’s not already implemented.

[jfmengels]

The spaced-comment rule is there to enforce that after the comment start characters you always (or never) have a whitespace. In Elm that would be like

-- This is a comment

Could elm-format add a whitespace when there isn’t? Absolutely

--Before
-- After

But there are a few downsides to that, because there are things you wouldn’t be able to write anymore:

1. Use --> to indicate a result. This is used for instance by elm-verify-examples

1 + 1
--> 2

2. Sections or blocks

-------------------------
--        Model        --
-------------------------

or even just lines

-------------------------

Because that would result in

-- -----------------------
--        Model        --
-- -----------------------

You could also try drawing a diagram and the spaces could mess things up.

If you look at the ESLint rule, there is a lot of available configuration. You can choose “always” or “never” to always or never have a whitespace, and then you have an option to add exceptions and exception “markers”.

Here is how a full configuration can look like:

{
  "spaced-comment": ["error", "always", {
      "line": {
          "markers": ["/"],
          "exceptions": ["-", "+"]
      },
      "block": {
          "markers": ["!"],
          "exceptions": ["*"],
          "balanced": true
      }
  }]
}

So all to say: it’s not that clear-cut of an improvement.

I am always wary of stylistic issues like these that are not necessarily better. A hint (not necessarily a red flag, but a smell) for that is when the rule allows you to do something or the exact opposite. Like “what are you recommending to me?”

All in all, IMO this would not be necessarily be an improvement. I think elm-format could do it probably with some reasonable defaults, but it would require a bit of thought. If you think this is a good idea, you could open an issue in elm-format.

[dta]

For the first example, I don’t think the proposed rule would cause a change in formatting since this would be inside of a multiline comment, and presumably the single-line comment indicator should have no effect there.

For the second example, I think that the proposed rule would lead to an improvement in the code since it would cause you to put those three lines which are actually a multiline comment inside of the multiline comment indicators so that they are not treated as three single-line comments by the tooling.

I am certainly a fan of not having these tools be configurable, but I don’t think the proposed rule would need to be.