As per #88 you overdid it a little by hard-replacing the resolver path return value with .replace(/\\/g, '/'); in function resolve(request) { ... }

path.normalize does already return the correct normalized path for the specific target environment

When multiple, sequential path segment separation characters are found (e.g. / on POSIX and either \ or / on Windows), they are replaced by a single instance of the platform-specific path segment separator (/ on POSIX and \ on Windows). Trailing separators are preserved.

The only reason a path like C:/browser/test.txt works with many modern browsers is because they actually parse it with the Posix syntax (and their file:// protocol implementation). Technically those paths are incorrect everywhere else - like in NPM and will return a file not found error (like it currently does e.g. when used in conjunction with Gulp on Windows, where all @import rules fail).

Most if not all browser correctly unwrap paths like C:\test\file.txt to their correct syntax the browser expects, in this case "file://C:/test/file.txt".

So the correct solution should be to simply return the value that path.normalize returns without any hard replace applied.

Sorry for the long text, I hope it makes sense.