Expose range of lines and columns for errors about ember-template-lint

[rwjblue]

I agree that this would be nice, but it is not obvious where a given error ends. For example, for an indentation error is the error with all text on that line or just the first char?

[joukevandermaas]

@rwjblue I know that e.g. jshint reports these as the whole line being wrong. Ultimately the decision for those cases is just bikeshedding. In other cases this would add a lot of value.

[rwjblue]

ya, I definitely want to end up using this for editor highlighting. I'll dig into how eslint does this a bit...

[rwjblue]

I believe that @binhums and @mmun were also thinking about adding range support. I'd definitely love their feedback....

@MattEddy and I are working on an atom linter. We definitely agree with the motivation, e.g. in our first stab we had a go inferring ranges - it didn't go so well 😛

It would appear that ESLint does not provide ranges. There is code in the ESLint atom package about ranges but I believe this is actually about auto-fixing rule violations.

But the Atom plugin looks fine highlighting the entire line:

The question for me is, for what rules would highlighting a range be more useful than highlighting an entire line. E.g. an invalid attribute or an inappropriate MustacheStatement rather than a missing attribute.

@MattEddy anything I missed here?

My concern is that this may be difficult for rule writers to provide. A rule writer is chiefly concerned with AST rather than the source code itself. The AST provides the start and end locations of the node.

I'd be interested in seeing a rule converted to return a meaning range. For example getting the block-indentation rule to return the range of the end block.

If we did provide ranges would we want to allow falling back to a [line, column] location if implementation a range is difficult for a given rule?

[joukevandermaas]

@binhums I understand and agree. I think it's better to have an approximate range for most rules than no range at all. In my opinion those rules can just report the whole line. It's always possible to improve later.

[rwjblue]

Having some rules with range and others without seems pretty annoying to me 😝 . I'd prefer to expose a single "results objects API" (which I have currently mostly stolen from ESLint). If we definitely want to support range values and a given rule cannot determine the "real" range then it should just use the full line as the range.

[rwjblue]

Also, I don't see folks having issues with editor integration with ESLint, and they do not provide range information. Am I just not paying attention to the right GitHub repos to see those issues, or is it a non-issue for them?

It sounds like we're in agreement here, any comments @mmun, @MattEddy?

[captain-enjoyable]

Nope. I'm not sure how the atom ESlint package manages to determine ranges, but having them on the result object seems ideal.

I spoke with @mmun about this - he told me about the one true god that is Rust. There are linters that provide ranges which are very useful e.g.

<anon>:6:5: 6:12 error: re-assignment of immutable variable `foo` [E0384]
<anon>:6     foo = 3;
             ^~~~~~~
<anon>:6:5: 6:12 help: see the detailed explanation for E0384
<anon>:2:9: 2:12 note: prior assignment occurs here
<anon>:2     let foo = 1;
                 ^~~
error: aborting due to previous error
playpen: application terminated with error code 101

If I were designing this in a vacuum (e.g. without the precedent of ESLint) I'd have a range in the API.

To summarise from the point of view of the people involved:

• Template authors benefit from having precise instructions over just highlighted lines
• Rule authors suffer from having to write logic to determine ranges
• ember-template-lint maintainers suffer from having to maintain an expanded API
• Integrations (e.g. ember-cli / atom) benefit from having complete metadata available and potentially suffer from writing fallback logic for a single line-column location

I've ordered those groups by how important I think they are. I feel like similar arguments apply for other metadata in the rule API such as source and fix.

After looking out for this more, I saw something that looks like a range in ESLint:

It's straight up inferred from the position of the error and fills to the end of the line...