CLI tests are tricky on Windows because of CRLF in base64 encoded inline sourcemaps

[romainmenke]

CLI tests are tricky on Windows.

Inline base64 encoded sourcemaps contain CRLF instead of LF.
Using git diff as a test fails because of this.

My intention behind a "simple" bash script was that we wouldn't have to write code.
Any code can be broken and broken test runners are the trickiest :)

If anyone has a good idea for this?

---

see : #17

[Antonio-Laguna]

Should we normalise as part of the test process?

[romainmenke]

Should we normalise as part of the test process?

Unsure, this CRLF is just OS behaviour and the current outputs are straight from PostCSS.

Maybe we can add .expect.css files created on and for Windows?
We would only need these for the CLI and changes here would be rare, so maybe not that big a hurdle?

[Antonio-Laguna]

It's not too big a hurdle but IMHO given that's the only thing changing we could maybe try and test in a way in which that wasn't important at all

[romainmenke]

Added a test PR were source CSS files no longer have new lines.
This seems to work.

Personally not a fan of files without trailing new lines.
But this does have the benefit of not needing to tamper with anything.
I am hesitant to add any normalisation too inputs or outputs as this code could have bugs.

Maybe this is the simplest way to have good tests for the CLI cross platform?

[jonathantneal]

Would it help to add a .gitattributes file like this?

* text=auto eol=lf

This is done in many projects to normalize line ending behavior.

[Antonio-Laguna]

I agree with not being a fan of those types of files. I think though that it's a "sane" tradeoff for CLI given we only use on those occasions.

[romainmenke]

@jonathantneal Thank you!

I did not think that would work as my assumption was that this config only converted CRLF to LF when committing.

Tests pass now without requiring any hacks : #30