Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Vscode and atom highlight locations are unexpected when end location is not provided

See original GitHub issue

Summary Many rules reports only start location and no end location. For these rules, editors often renders tildes in unexpected places.

Examples In these examples, the rules only reports start location but no end locations. Instead of highlighting tokens like \n, (, or {, the token before the said token is highlighted.

/* eslint semi: [2, 'always'] */
const a = Math.random
//             ~~~~~~    actual highlight in vscode
//                   ~   expected highlight
//                   ^   reported start location


/* eslint object-curly-spacing: [2, 'always'] */
const b = {b: Math.random}
//                 ~~~~~~    actual highlight in vscode
//                       ~   expected highlight
//                       ^   reported start location


/* eslint space-in-parens: [2, 'never']  */
function ffff( a ) {}
//       ~~~~    actual highlight in vscode
//           ~   expected highlight
//           ^   reported start location

There are many other rules suffering from this problem, most of them are named *space* or *spacing*.

How to fix The problem disappear if the both start location and end location are reported and start location is different to end location. That is, the location range is not zero-width-ed.

There are several places this can be done:

Modify each rules to report end location. Pros: explicit. Cons: lots of place needs change.
Modify ESLint core, automatically add end location when end location is missing. Cons: not explicit.
Modify vscode-eslint plugin to automatically add end location when end location is missing.