Infer the endLocation of a problem from the reported node

Problem

Currently, the context.report API allows rules to specify a start and end location for problems:

context.report({
  loc: {
    start: {
      line: 1,
      column: 3
    },
    end: {
      line: 1,
      column: 5
    }
  },
  message: 'Detected a problem.'
});

This was added to address https://github.com/eslint/eslint/issues/3307, and it’s very useful because it allows editor integrations to highlight an entire range.

However, as currently implemented this API is tedious to use, because it only works if a report includes aloc key. As a result, most rules don’t use this API, because they report a node instead of an explicit location. (When a node is reported, only the start location of the node appears in the resulting message – the end location does not appear.)

Proposal

When a node is reported without a location, the end location of the node should be used as the end location of the report. (The start location of the node is already used for the start location of the report.)

For example, given the following node:

{
  "type": "Identifier",
  "start": 0,
  "end": 3,
  "name": "foo"
}

Suppose a rule uses

context.report({ node, message: 'report message' });

The resulting problem message currently looks like this:

{
  "ruleId": "some-rule",
  "severity": 2,
  "message": "report message",
  "line": 1,
  "column": 1,
  "nodeType": "Identifier",
  "source": "foo"
}

With this change, the resulting problem message would look like this:

{
  "ruleId": "some-rule",
  "severity": 2,
  "message": "report message",
  "line": 1,
  "column": 1,
+ "endLine": 1,
+ "endColumn": 4,
  "nodeType": "Identifier",
  "source": "foo"
}

[not-an-aardvark]

I’ll add this to the TSC agenda since it’s a change to core that could break things.

TSC Summary: As currently implemented, the endLine and endColumn report API is tedious to use, because it only works if a report includes a loc key. As a result, most rules don’t use this API, because they report a node instead of an explicit location. We could update core to infer the endLine and endColumn of a reported node, but this would be a breaking change because it could cause a poor user experience in some existing editor integrations (e.g. if hundreds of lines are highlighted because a large node is reported).

TSC Question: Should we make this change?

[not-an-aardvark]

In today’s TSC meeting, the TSC accepted this issue.