You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's probably not a huge issue (integration or end-to-end tests should determine if it is) as we're not publishing a library (whose code could be further used/bundled downstream). I heard that it might cause an issue on Nodejs on Linux however.
Ideas For Fix
Either don't bundle (which is what creates the mixed line-endings), or use a tool post-bundle to convert all line-endings to LF. One idea is to use Terser, which will also potentially minify, as well and provide a final source map (useful for coverage reports). Terser will parse into AST and then emit all LF line-endings. Parsing into AST instead of blindly replacing all CRLF with LF is better as it is possible (I think) for there to be CRLF in positions other than source code line endings (e.g. maybe a string literal could contain one).
The text was updated successfully, but these errors were encountered:
It's probably not a huge issue (integration or end-to-end tests should determine if it is) as we're not publishing a library (whose code could be further used/bundled downstream). I heard that it might cause an issue on Nodejs on Linux however.
Ideas For Fix
Either don't bundle (which is what creates the mixed line-endings), or use a tool post-bundle to convert all line-endings to LF. One idea is to use Terser, which will also potentially minify, as well and provide a final source map (useful for coverage reports). Terser will parse into AST and then emit all LF line-endings. Parsing into AST instead of blindly replacing all CRLF with LF is better as it is possible (I think) for there to be CRLF in positions other than source code line endings (e.g. maybe a string literal could contain one).
The text was updated successfully, but these errors were encountered: