1.0.0-rc5 line endings change

[XhmikosR]

Hello!

While trying to update to v1.0.0-rc5 from rc3, I noticed that on Windows the result line endings are CRLF. On rc3 they were LF.

PR with sample code: twbs/icons#575

Not a big deal and I can normalize the line endings, but I thought I'd mention it since it might be something that slipped in. :)

PS. I also had to explicitly set xmlMode: true in order to get the same final SVGs compared to rc3.
PPS. is there any way one can set globals easily? Like set xmlMode: true for all cheerio calls?

[5saviahv]

• I checked your example, but I wasn't able replicate.

Since #1602 you told you use autocrlf can you try moving icons outside of your git folder. Before test check they use LF and do the test with those files. SVG files are text files, I believe git may convert LF to CRLF. Parsers in cheerio simply replicate line endings they see.

• if you specify option with load they will be stored with object

const $ = cheerio.load(result.data, { xmlMode: true });

later when you use $(...) same options apply.

[XhmikosR]

Since #1602 you told you use autocrlf can you try moving icons outside of your git folder. Before test check they use LF and do the test with those files. SVG files are text files, I believe git may convert LF to CRLF. Parsers in cheerio simply replicate line endings they see.

This is unrelated to git; the files have CRLF after running the script thus after using cheerio, not after cloning the repo. Also, the repo I'm having the issue already enforces LF via .gitattributes. So, it doesn't look like an issue with git, rather with the new parser or something since going back to v1.0.0-rc3 works fine and outputs LF.

* if you specify option with load they will be stored with object

const $ = cheerio.load(result.data, { xmlMode: true });

later when you use $(...) same options apply.

Thanks!

[5saviahv]

I tested with windows 10 and with node versions 12 and 14. I tested with cheerio 1.0.0-rc.3 and rc.5, but I was not able generate svg files with LF line endings.

CRLF comes from SVGO package - Serializer uses OS specific EOLs js2svg.js line 3

[XhmikosR]

I don't change anything else in that branch apart from the cheerio version. I don't see how svgo is related since it's used the same way & the same versions. Only the cheerio version changes and I'm hit with the issue. As long as I downgrade the issue goes away.

…

On Sun, Dec 27, 2020, 17:14 5saviahv ***@***.***> wrote: CRLF comes from SVGO package - Serializer uses OS specific EOLs js2svg.js line 3 <https://github.com/svg/svgo/blob/07ca9764f71fb946adc23f4ea9f19070d335305d/lib/svgo/js2svg.js#L3> I tested with windows 10 and with node versions 12 and 14. I tested with cheerio 1.0.0-rc.3 and rc.5, but I was not able generate svg files with LF line endings. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1598 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACVLNJ6FTAIZGXCALOCKBTSW5FNJANCNFSM4VJ34CBA> .

[5saviahv]

I managed replicate the issue.

[fb55]

Cheerio is now using parse5's serializer for HTML. That is the one change that could have resulted in this. Using xml: true will solve this for now.

It would be great to have a minimal example, so we can report this to parse5.

[XhmikosR]

Does that explain the line endings issue too?

The script is linked in the OP and it's a pretty basic one :)

[5saviahv]

parse5 always converts CRLF to LF, but htmlparser2 preserves CRLF as they come in.

With specify xml: true you use htmlparse2

I tried find the way so everything acts as before so I parse using parse5 and later serialize with dom-serializer

    ...
    const $ = cheerio.load(result.data);
    const svg = $('svg');
    svg[0].attribs = { ...svgAttributes, class: `bi bi-${path.basename(file, '.svg')}` };

    fs.writeFile(file, cheerio.html(svg, { xml: true }), 'utf8')
    ...

[fb55]

Ahh, that makes more sense. Thanks for the clarification @5saviahv!

This is unfortunately expected behavior following the HTML spec then, and will not be fixed.