Closed shark-horse closed 4 years ago
You have right, the current problem that we use the OS EOL and not the document EOL
let arr
try {
arr = (more + 2) + fileContent.split(os.EOL)
} catch (e) {
arr = (more + 2) + fileContent.split('\n')
}
Or :
if (text.match(/\n/g) && !text.match(/\r\n/g))
I would not try / catch for this, especially since an exception is not guaranteed: A file may have a mixture of \n
and \r\n
such that there are enough lines, so no TypeError, but I think the error message would show the wrong code.
Ideally, we would use the same newline characters that terser itself treats as newlines. I found:
var NEWLINE_CHARS = makePredicate(characters("\n\r\u2028\u2029"));
(source). In at least one spot \r\n
is handled specially so that it is treated as just one newline, not two (source).
I'll work on a PR for this today if time allows.
@shark-horse Can you Q/A (try my change) #12 ?
I prefere to change the EOL because my function printError
can be used for other package like gulp-less.
Yes, I will QA.
https://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf section 11.3 lists the same characters in terser's NEWLINE_CHARS
as the line-terminating characters, with of course \r\n
counting as one line terminator.
Please see my comment on the submission.
Encountered this with gulp-terser-js@5.0.0 on Windows, but not Linux:
That LoC is:
Replacing both instances of
os.EOL
innode_modules/gulp-terser-js/bin/index.js
with'\n'
fixes the problem in Windows so we get a nice error report. Replacingos.EOL
with'\r'
in Linux makes the same problem reproducible in Linux.We have a lot of files with
\n
as the line ending. What I suspect is thatterser
is reporting line numbers correctly, butgulp-terser-js
is not correlating that to the file because it is assuming thatos.EOL
is the same line ending that the file is using.Just getting this information out there before I have time to confirm my theory, write a test, or submit an MR.