Closed ayuhito closed 4 months ago
hmm 🤔 I think this is a "known" issue. Not sure if there is a way in order to handle this. Do you happen to know how jest behaves in the above scenarios?
Not particularly, but to be fair this issue is pretty dependent on the machine you are using or Git config you have set. e.g. git config --global core.eol lf
will also automatically convert your checked in content as LF.
I'm not really sure either how to approach this. One solution could be to strip CRLF on incoming data since it will never match snaps anyways, but that sort of invisible behaviour is pretty bad when you have bugs that might depend on line ending behaviour. Perhaps just clearer documentation so developers know about the limitation is the best approach.
That makes sense, will update the documentation for this case.
Took me sometime 😅 Sorry and thank you for opening this issue.
Description
I'm writing a formatter and a testing suite of files alongside it that also needs to validate line endings (LF, CRLF) of string outputs or file reads. From my understanding, I think the snaps are only written in LF which leads to my snaps not matching my bytes output as they sometimes use CRLF.
I understand this is a bit of a complicated messy edge case, so I'm fine with no solution. Just wanted to let you know that line endings are inconsistently handled which does break tests. My only workaround is to disable CRLF testing in the meantime.
Steps to Reproduce
Read any CRLF file into a snap and it will replace all line endings into LF. Read the CRLF file again to match with the snap and it will fail. Note my snaps actually mix both LF and CRLF in the same file so that might be another complicated factor to handle.
Expected Behavior
No response