Fix Windows Paths (#276)

* fixes #270: bad filename generation

Uses an existing dependency in the module to test if the generated
filename is absolute before adding the leading slash. This is the most
minimal fix for the Windows incompatibility that doesn't break a
bunch of test cases that currently pass on Windows, and which won't
run afoul of the filesystem abstraction layer used by Webpack.

* Tests for #270

* Code style adherence

* Attempt to appease the Linux spirits

The pathabs call wasn't treating c:\ as absolute on Linux, so it was
still prepending the /, and hence failing out the test. Now instead
we call both the posix and win32 versions of the function explicitly,
same as is done in the setFs call. That feels dirty to me, but this is
already fairly dirty, and I don't think this opens any kind of path
attack vector that wasn't already present.

Author: Sean Middleditch

lib/util.js

@@ -93,7 +93,7 @@ module.exports = {
     if (filename) {
       uri = urlJoin((outputPath || ''), filename);
 
-      if (!uri.startsWith('/')) {
+      if (!pathabs.posix(uri) && !pathabs.win32(uri)) {
         uri = `/${uri}`;
       }
     }

test/tests/util.js

@@ -121,6 +121,13 @@ describe('GetFilenameFromUrl', () => {
       publicPath: '/',
       expected: '/pathname with spaces.js'
     },
+    {
+      url: '/test/windows.txt',
+      outputPath: 'c:\\foo',
+      publicPath: '/test',
+      // this is weird, but it's legal-ish, and what URI parsing produces
+      expected: 'c://\\foo/windows.txt'
+    },
     {
       url: '/js/sample.js',
       compilers: [