search

HenrikJoreteg / moonboots

A set of conventions and tools for bundle and serving clientside apps with node.js
159 stars 20 forks source link

tests dont pass on windows #50

Closed lukekarrys closed 6 years ago

lukekarrys commented 9 years ago

It seems to be just that the expected hashes (for css and js) are different.

It seems to be consistent each time on Windows, thought, but if you load balanced across many servers and there was a mix of linux/windows, this could cause an issue.

screen shot 2014-09-17 at 12 59 21 pm

wraithgar commented 9 years ago

that last test can be fixed by filtering out \r and \n

As far as the other tests, I'll admit they were pretty half-assed to begin with. I simply ran them, saw the hash being generated, and then put those values into the test. They're more regression tests than anything else. If they're blocking windows testing I think we would be ok loosening the tests up to simply make sure the filenames adhere to app.hash.extension(s) and that the hash is not undefined.

Maybe a better approach would be a way to ask moonboots for the hashes, then test that they're not undefined, and build the test filenames from those values in these failing tests.

ETA: we could also just check require('os').EOL which I'm pretty sure is causing the differences and just test one hash or the other based on what that is.

wraithgar commented 9 years ago

As far as the load balancing thing, I'm not sure we really want to worry about that right now. It feels like a bit of an edge case on that one, and the worst case seems to be they'll have two filenames the clients could possibly see/cache?

lukekarrys commented 9 years ago

After chatting with @wraithgar I'm gonna see if I can use require('os').EOL to see if there can be consistent hash across operating systems.

Unfortunately the worst case scenario for that load balancing bug has bit me before and it causes many clients to 404 on their JS/CSS requests if the hashes aren't consistent.