InvalidPathException when loaders used before closure plugin?

[acbart]

I've been building a project that uses the closure-webpack-plugin, although I am somewhat new to WebPack. I think there may be an issue on Windows when you use a loader (at least, eslint-loader) with this plugin for the 'java' platform. In particular, it seems like the path that gets passed into the Closure Library has exclamation marks concatenating the loaders, instead of just the desired code.

Here's a minimal version of the relevant setup, I believe:

module.exports = (env, argv) => {
    return {
        entry: './src/main.js',
        output: {
            path: 'dist',
            filename: 'skulpt.min.js'
        },
        devtool: 'source-map',
        optimization: {
            noEmitOnErrors: true,
            minimizer: [
                new ClosureWebpackPlugin({mode: 'STANDARD', platform: 'java'}, {
                    jscomp_error: ['accessControls', 'checkRegExp', 'checkTypes', 'checkVars',
                                   'invalidCasts', 'missingProperties',
                                   'nonStandardJsDocs', 'strictModuleDepCheck', 'undefinedVars',
                                   'unknownDefines', 'visibility'],
                    jscomp_off: ['fileoverviewTags', 'deprecated'],
                    languageOut: (env && env.languageOut) ? env.languageOut : 'ECMASCRIPT_2015',
                    externs: 'support/externs/sk.js'
                })
            ]
        },
        module: {
            rules: [
                {
                     test: /\.js$/,
                     enforce: 'pre',
                     loader: 'eslint-loader'
                }
            ]
        }
  }
}

This triggers the following error:

ERROR in closure-compiler: java.nio.file.InvalidPathException: Illegal char <:> at index 81: C:\Users\acbart\Projects\bl
ockpy-edu\skulpt\node_modules\eslint-loader\index.js!C:\Users\acbart\Projects\blockpy-edu\skulpt\src\main.js
        at sun.nio.fs.WindowsPathParser.normalize(Unknown Source)
        at sun.nio.fs.WindowsPathParser.parse(Unknown Source)
        at sun.nio.fs.WindowsPathParser.parse(Unknown Source)
        at sun.nio.fs.WindowsPath.parse(Unknown Source)
        at sun.nio.fs.WindowsFileSystem.getPath(Unknown Source)
        at sun.nio.fs.AbstractPath.resolveSibling(Unknown Source)
        at com.google.javascript.jscomp.SourceMapResolver.getRelativePath(SourceMapResolver.java:102)
        at com.google.javascript.jscomp.Compiler.addSourceMapSourceFiles(Compiler.java:2805)
        at com.google.javascript.jscomp.Compiler.initBasedOnOptions(Compiler.java:541)
        at com.google.javascript.jscomp.Compiler.initModules(Compiler.java:511)
        at com.google.javascript.jscomp.AbstractCommandLineRunner.doRun(AbstractCommandLineRunner.java:1207)
        at com.google.javascript.jscomp.AbstractCommandLineRunner.run(AbstractCommandLineRunner.java:518)
        at com.google.javascript.jscomp.CommandLineRunner.main(CommandLineRunner.java:2168)

I can avoid the error simply by removing the rule for Eslint, but that's not really ideal. Is there some configuration option that should be passed to the closure compiler plugin to tell it to read the name differently, or is this some kind of bug? I can't tell if it's Eslint's fault for changing the URL, Webpack's fault for changing the URL, or this plugin's fault for not knowing how to read the URL.

[TorRanfelt]

I'm experiencing the same problem with a different set of loaders.
However by using platform: "javascript" I was able to move forward.

[acbart]

Yeah, but then it's super slow. I would prefer to use the Java compiler.

[TorRanfelt]

I completely agree.
I had to give up on closure entirely though because I got an error about multiple classes having the same name (after 3,5 hours).
I'm coding in Kotlin so this must be due to something the Kotlin compiler is doing so I have to go another route.

[ChadKillingsworth]

Some loaders and transformations make this extremely difficult. The plugin attempts to unwind and get the original filesystem path - but that's not always possible.

[ChadKillingsworth]

Actually - this should be fixed in the compiler proper.