Incorrect column for invalid JS file

[Arcanemagus]

As reported over here https://github.com/AtomLinter/linter-jscs/issues/163 by @ricardograca jscs is giving an in correct column number for an invalid JavaScript file.

When run on the following content, jscs reports a column that is past the end of the file:

var testError = image/png'

Here is what I see on the command line:

And when using the API we are getting this:

Tested with jscs v2.8.0. The line ending of the file only changes the numbers by one, it is incorrect with both LF and CRLF. If you need any information please let me know.

[markelog]

Hm, weird, it gives me the correct position, what would happen if you execute this line with node?

[Arcanemagus]

Well this is interesting, my home computer shows a different error, but the right position. The work computer still shows the same as above on the exact same file though so something is up. Both are supposedly running jscs v2.8.0.

I'm not sure exactly what you mean by "execute this line with node", but I would love to figure out how both systems are giving different results if you can think of any steps to debug this.

This is what my home computer is showing:

[sholladay]

I am pretty sure @markelog is asking what Node.js reports for the position if it encounters the example code and crashes from a SyntaxError.

As in, run the example independent of JSCS and check the stack trace. Presumably he is asking that to rule out the possibility that the problem is simply coming from a bug within the version of Node you have installed.

[Arcanemagus]

No difference in the node output between the two, and it seems to be pointing to the correct location.

Work:

Home:

[Arcanemagus]

So I stepped through everything function call by function call and have determined this is a bug within esprima. When it sees the ' at the end it starts scanning for the string contents of the string that was just "began", unfortunately when it sees the EOL character it doesn't advance the tracking of the current line, but it does keep advancing the column position thus leading to the position marker past the end of the line.

Now for the weird part: The esprima loaded within Atom is v2.7.1, the same version that is loaded by the CLI version, as well as both instances on my home computer so I can't explain why it's working here. Going to try stepping through it here next to see why it doesn't fail (and gives a different message).

[Arcanemagus]

Okay, learn to use a clean environment while testing apparently :stuck_out_tongue:

I had the test file inside a project that had a .jscsrc file specifying the airbnb preset, which forces ESNext enabled, and thus uses the babel-jscs parser. Moving it to a similar folder to the work machine causes it to use regular esprima and hit this bug.

[markelog]

I would ask you to change parsers right after verifying we see the same thing, okay, so it seems it is a esprima bug - since it is pretty much nothing we can do on our side, i can just only recommend to use babylon i.e.babel-jscs for now and /cc @ariya