Most of the tests are failing on Window because of its "inconsistencies to unix":
Paths use the backslash, e.g. "\asset-blsavdw4g453gf-style.css" while the tests except the frontslash.
I wouldn't recommend fixing those but there should be a note somewhere in the README.
I don't have a windows machine to test with, but I can whip up a patch tomorrow that uses stuff from path (sep, etc). That should adress the issue?
edit: the problem is actually that we use path in places we shouldn't.
Another problem, as far as I know, is that you use fs.Stats.mtime when creating the hash. And because the last modified date differs on my computer and this repo, the tests fails since the hashes are hard coded into the tests.
This issue should be cross-os I believe.
@jbergstroem path is the correct cross-platform way of working with paths. The library is failing on windows because the URL paths don't have their separators translated before being looked up in the asset index. When you define an asset, e.g. js/jquery.js the identifier is the path, relative to the static directory that you specify. On windows this would be js\jquery.js. When a request comes through for http://yourhost.com/js/jquery.js we get the request.path of js/jquery.js and find nothing in the index on windows machines. There needs to be a translation step after obtaining request.path where slashes are converted to path.sep. There's also a few other cases where we trim trailing slashes and use '/' rather than path.sep.
@Acconut the hash is based on file contents only; the mtime and filename aren't part of it. Again, the tests are probably failing because the assets aren't being resolved properly and so the file contents (and therefore hash) isn't as expected.
Going to close this based on inactivity. Since neither of us "devs" have access to a windows machine, we can't do much. Feel free to reopen or create a new PR if there's code to be contributed.