Relative path resolution on Windows fails about gulp-sri-hash HOT 5 CLOSED

I tried solving this the other day I was fiddling with the repo to no avail. I might be able to have a look again soon-ish if you don't beat me to it.

from gulp-sri-hash.

Two issues prevented tests to pass on Windows:

• Tests for relative path resolution were not portable and checked path separators by forward-slash (but Windows uses backward slashes). Commit ead6130 fixes this issue.

• Hash checksum calculation yields different results if files in question use CRLF line endings. Therefore checksums didn't match and tests failed. Commit 7ec45d8 forces checking out css- and js-files with LF file endings.

@XhmikosR Can you pull the latest changes from master, and run tests again? You may have to manually convert line-endings (or do a fresh new checkout). This time it should work, though 😄

Also, I updated the README.md with a note about this line-ending issue (6620fa4).

from gulp-sri-hash.

@macedigital: Looks good to me. A couple of thoughts:

• I would remove the init section from AppVeyor; you shouldn't rely on such things
• An alternative approach to .gitattributes would be to make sure you just do foo.replace(/\r\n/g, '\n');

from gulp-sri-hash.

Oh, an irrelevant thing, but I don't want to make a new issue.

Make sure you use the files section in package.json so that you don't include unneeded files when publishing. Like:

  "files": [
    "index.js"
  ]

from gulp-sri-hash.

@XhmikosR Thanks for your help! And don't hesitate to open tickets ;)

Regarding your feedback:
I removed the init section from the appveyor.yml, it's definitively not needed.

Line-ending settings in .gitattributes are local to this module, and in a sense, only affect the test fixtures. In practice, it shouldn't actually matter with which line endings files are saved with, as long they are never converted.

Also, I'll consider limiting the number of files for the next release (e.g. excluding test files).

from gulp-sri-hash.