Handle source map referencing EOL character

[nikolay-borzov]

• Detect EOL character for the file. It fixes wrong splitting for source maps generated on Windows environments.
• When checking column boundary verify that the last referenced column is not EOL.
• Generate source map referencing EOL characters (typescript.ts)
• Fix 'InvalidMappingLine' check. Getting not existing value from array returns undefined, not null.
• Add test for 'InvalidMappingColumn' error. Generate invalid-map-column.js and invalid-map-line.js.

Fixes #136

[coveralls]

Coverage increased (+1.1%) to 96.949% when pulling e37fe62 on handle-source-map-referencing-eol into 2f8535b on master.

[danvk]

Thanks for the fix @nikolay-borzov. I reproduced the original issue on my machine and confirmed that this PR fixes it.

[danvk]

Could you replace this with a shell script that generates the data?

[nikolay-borzov]

I can't, I don't know how to write it in a shell script.

[ashi009]

Is the EOL here meant to be \n\r? If so, git has eaten them.

$ curl https://raw.githubusercontent.com/danvk/source-map-explorer/254a5d997eafb0234385ab52c7ff60714d167a52/tests/generate-data/src/typescript.ts | hexdump -C
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   134  100   134    0     0    206      0 --:--:-- --:--:-- --:--:--   206
00000000  2f 2f 20 54 79 70 65 53  63 72 69 70 74 20 67 65  |// TypeScript ge|
00000010  6e 65 72 61 74 65 73 20  73 6f 75 72 63 65 20 6d  |nerates source m|
00000020  61 70 20 74 68 61 74 20  69 6e 63 6c 75 64 65 73  |ap that includes|
00000030  20 6d 61 70 70 69 6e 67  20 66 6f 72 20 6c 69 6e  | mapping for lin|
00000040  65 20 65 6e 64 69 6e 67  20 63 68 61 72 61 63 74  |e ending charact|
00000050  65 72 73 0a 63 6f 6e 73  6f 6c 65 2e 6c 6f 67 28  |ers.console.log(|
00000060  27 68 65 6c 6c 6f 5c 6e  5c 72 27 29 3b 0a 63 6f  |'hello\n\r');.co|
00000070  6e 73 6f 6c 65 2e 6c 6f  67 28 27 77 6f 72 6c 64  |nsole.log('world|
00000080  5c 6e 27 29 3b 0a                                 |\n');.|
00000086

[nikolay-borzov]

Strange. I though git is only supposed to replace all EOL to be \r. But how does https://github.com/danvk/source-map-explorer/blob/8df374d8c35311f9ea4bde0a7c58cc689307c861/tests/generate-data/src/typescript.ts display multiple lines then?

What does . represent in curl output?

[ashi009]

I piped curl to hexdump, and . is 0x0a (\n). GitHub renders those files line by line, so it will always look fine in browser.

My point is, if this is the input file for testing the implementation in the future, it doesn’t really cover the windows EOL case.

[nikolay-borzov]

My point is, if this is the input file for testing the implementation in the future, it doesn’t really cover the windows EOL case.

We don't need exactly windows EOL to reproduce the issue. EOL type doesn't really matter, does it?

Check out master branch, comment && ${line}${eol}.lastIndexOf(eol) !== generatedColumn and run node dist/cli.js tests\data\map-reference-eol.js. It will still fail because of reference to \n inside source map.