EEP-74

[elbrujohalcon]

So, elp comes with a linter now. And they are proposing a standard for linting and other error reports across all tools in the community: The Erlang Error Index.
They already maintain what could be its first version: https://whatsapp.github.io/erlang-language-platform/docs/erlang-error-index/

So, the question is: What should we do about it?

Subquestions being:

1. Should we work on adding our rules to the index currently hosted by WhatsApp?
2. Should we wait until the index is officially supported by the OTP Team and then add our rules there?
3. Should we push to keep our mostly descriptive rule names as the "codes" for our rules or should we start working on adding the somewhat obscure codes that EEP-74 recommends (e.g. ELV-0015)?
4. Should we try to match elp's codes or keep our own ones (e.g. L1318 instead of ELV-#### / no_successive_maps)?
5. [Slightly unrelated, but…] Should we try to add our rules to ELP's linter? If so, how? Adding a bridge in elp so that it can check modules with elvis or rewriting our rules in Rust?

[elbrujohalcon]

@bormilan / @paulo-ferraz-oliveira : I'll wait for your answers before posting mine to keep my mind open to your suggestions :)

[paulo-ferraz-oliveira]

First thing that comes to mind: more maintenance. You have to:

1. assign a code,
2. do two PRs (one for e.g. elvis_core, one for the error index)

Note: moving the documentation away from the code also makes it more difficult to maintain, and might be prone to external "interference" that wouldn't otherwise happen, if we maintain full control.

---

That said:

1. I like lists
2. I like organisation/standardisation
3. if it benefits the community at large (I think that's Elvis' goal) maybe we should consider it, at least (or even try it out and see what comes out of it)

If all it brings "as extra work" is the extra PR (when implementing new rules or tweaking existing ones), but at the same time the burden of maintaining the documentation is slightly shifted toward "the community" I'm for it.

I've recently tweaked all of the rules' documentation and it wasn't always easy to find the correct words, especially since I'm not a technical writer, and the number of people proof-reading is limited.

We also already implement most of the mentioned concepts: links to pages with further documentation, unique error codes, lines/columns, ...

[paulo-ferraz-oliveira]

For the subquestions:

Should we work on adding our rules to the index currently hosted by WhatsApp?

I could wait.

Should we wait until the index is officially supported by the OTP Team and then add our rules there?

Yes, let's gather more feedback.

Should we push to keep our mostly descriptive rule names as the "codes" for our rules or should we start working on adding the somewhat obscure codes that EEP-74 recommends (e.g. ELV-0015)?

Codes could be 0001, 0002, based on the date of implementation, for example. It'd be some work to figure it out, but not much, depending on how accurate we want to be

Should we try to match elp's codes or keep our own ones (e.g. L1318 instead of ELV-#### / no_successive_maps)?

I don't have a strong preference, but I'd lean toward ELV-...

[Slightly unrelated, but…] Should we try to add our rules to ELP's linter? If so, how? Adding a bridge in elp so that it can check modules with elvis or rewriting our rules in Rust?

I'd prefer to keep writing Erlang, but I'd be Ok to shift toward Rust if that were necessary. I feel we're not setting a good example, though, when we move away from the tool we're trying to lint by using another tool (is Erlang that limited?).

[elbrujohalcon]

I agree on waiting until this becomes official and officially maintained by the OTP Team.
I agree on preferring our own codes, like ELV-####. I do prefer the atom ones (e.g. no_successive_maps), but it's not a deal-breaker.
I agree on using Erlang to check Erlang, too… Even more now that writing rules here is a walk in the park.
The only thing that WhatsApp's Rust environment brings to the table (from my perspective) is the highly performant AST parser. Their tools to parse Erlang AST and work on it are faster than erl_scan, erl_parse, erl_syntax, epp_dodger, etc.… and they're less clunky in regards to macros, too. Thir framework also allows you to write linting tools that go beyond the scope of a single file (they're run project-wise, like Hank, not module-wise, like Elvis).
FWIW, and for the record: I would not start migrating our rules to the elp linter any time soon. I think this project is healthy and our tool is working very well as it is right now. As much as I would like to have just one linter for the whole community, I think (even with its limitations) I still prefer this one 😎

[bormilan]

I agree on using Erlang to check Erlang, too… Even more now that writing rules here is a walk in the park.
The only thing that WhatsApp's Rust environment brings to the table (from my perspective) is the highly performant AST parser.

I agree too. I feel like having both is the perfect choice for the community,

I feel that I am too young to speak on this topic in general, so I agree with you on the first two points.
I like the idea, so I'm interested in how we will implement it.