Closure-compiler: Source Maps Resolved relative to SourceFile path (which may not be a valid path).

[jochenberger]

Caused by: java.nio.file.InvalidPathException: Illegal char <:> at index 44: StreamableResource%3Ctext/javascript webjars:META-INF/resources/webjars/eddyson-react-grid/0.8.6/dist/Ardagryd.min.js COMPRESSABLE lastModified: Do Aug 10 09:02:01 MESZ 2017 size: 60696%3E
--
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 com.google.javascript.jscomp.SourceMapResolver.getRelativePath(SourceMapResolver.java:73)
at com.google.javascript.jscomp.SourceMapResolver.extractSourceMap(SourceMapResolver.java:53)
at com.google.javascript.jscomp.JsAst.parse(JsAst.java:163)
at com.google.javascript.jscomp.JsAst.getAstRoot(JsAst.java:54)
at com.google.javascript.jscomp.CompilerInput.getAstRoot(CompilerInput.java:121)
at com.google.javascript.jscomp.Compiler.hoistIfExtern(Compiler.java:1974)
at com.google.javascript.jscomp.Compiler.hoistUnorderedExterns(Compiler.java:1944)
at com.google.javascript.jscomp.Compiler.orderInputs(Compiler.java:1895)
at com.google.javascript.jscomp.Compiler.parseInputs(Compiler.java:1826)
at com.google.javascript.jscomp.Compiler.parseForCompilationInternal(Compiler.java:994)
at com.google.javascript.jscomp.Compiler.access$300(Compiler.java:102)
at com.google.javascript.jscomp.Compiler$6.call(Compiler.java:974)
at com.google.javascript.jscomp.Compiler$6.call(Compiler.java:971)
at com.google.javascript.jscomp.CompilerExecutor.runInCompilerThread(CompilerExecutor.java:118)
at com.google.javascript.jscomp.Compiler.runInCompilerThread(Compiler.java:872)
at com.google.javascript.jscomp.Compiler.parseForCompilation(Compiler.java:970)
at com.google.javascript.jscomp.Compiler.compile(Compiler.java:723)

Maybe the InvalidPathException should be caught.

[jochenberger]

The issue was introduced in https://github.com/google/closure-compiler/commit/fa5af790fc86b8bde261a19152eb222d61458333#diff-153756dc1310b1c74308e9d07c4a93faR73.

[MatrixFrog]

So, WindowsPathParser thinks it's an invalid path character, but Windows itself treats it as valid?

[jochenberger]

No, it isn't valid, but is is not required to be a valid file name according to the SourceFile.name JavaDocs

[tadeegan]

What is the //# sourceMappingURL linked to?

[jochenberger]

It's linked to a valid file name, but that's not really relevant here.
The issue is that SourceMapResolver assumes that the SourceFile's name is a valid file name.
In my case, I'm creating the SourceFile from an InputStream. It contains a generated asset that's a concatenation of multiple individual files, say foo.js and bar.js. I give it a "file name" of bundle: foo.js and bar.js.
Now, foo.js has a sourceMappingURL pointing to foo.js.map. As I'm just concatenating the files, the sourceMappingURL ends up in the bundle. CC finds it and tries to resolve the actual file by calling FileSystems.getDefault().getPath("bundle: foo.js and bar.js").resolveSibling("foo.js.map").normalize(). And that's where things break.

[tadeegan]

Perhaps the compiler should only perform the sourcemap resolution urls for the "OnDisk" variant of SourceFile.

The inputStream api uses the "Preloaded" SourceFile subclass. Feel free to open a pull request with the fix.
https://github.com/google/closure-compiler/blob/master/src/com/google/javascript/jscomp/SourceFile.java#L522

You can flip this boolean in the CompilerOptions to turn this off:
https://github.com/google/closure-compiler/commit/f29d2621084cc3e77adf73da5ac5ac58a3531022
I don't think there is a command line flag for it yet but perhaps it should be added.

[jochenberger]

Thanks for the hint, I looked for a CompilerOptions setting but apparently I overlooked resolveSourceMapAnnotations.
The fix sounds good to me but since I don't want to sign the CLA, my PR wouldn't get accepted.

[ChadKillingsworth]

I don't really think this needs a flag. Most build tooling has a way to handle this already.

[jochenberger]

Maybe, but this issue is not about the flag.

[tadeegan]

This is still a bug. Sources that don't come from a filesystem should not try to find the file from the sourcemap annotation. Or at least there should be a better error here.

[chancyk]

Is this related to the exception below? I'm getting this from the release.clj build script in the ClojureScript quick-start tutorial under the Production Builds section, which reads:

(require 'cljs.build.api)

(cljs.build.api/build "src"
  {:output-to "out/main.js"
   :optimizations :advanced})

(System/exit 0)

Exception in thread "main" java.nio.file.InvalidPathException: Illegal char <:> at index 2: /C:/Projects/cljs/out/cljs/core.js, compiling:(C:\Projects\cljs\release.clj:3:1)
        at clojure.lang.Compiler.load(Compiler.java:7391)
        at clojure.lang.Compiler.loadFile(Compiler.java:7317)
        at clojure.main$load_script.invokeStatic(main.clj:275)
        at clojure.main$script_opt.invokeStatic(main.clj:335)
        at clojure.main$script_opt.invoke(main.clj:330)
        at clojure.main$main.invokeStatic(main.clj:421)
        at clojure.main$main.doInvoke(main.clj:384)
        at clojure.lang.RestFn.invoke(RestFn.java:408)
        at clojure.lang.Var.invoke(Var.java:379)
        at clojure.lang.AFn.applyToHelper(AFn.java:154)
        at clojure.lang.Var.applyTo(Var.java:700)
        at clojure.main.main(main.java:37)
Caused by: java.nio.file.InvalidPathException: Illegal char <:> at index 2: /C:/Projects/cljs/out/cljs/core.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 com.google.javascript.jscomp.SourceMapResolver.getRelativePath(SourceMapResolver.java:73)
        at com.google.javascript.jscomp.SourceMapResolver.extractSourceMap(SourceMapResolver.java:53)
        at com.google.javascript.jscomp.JsAst.parse(JsAst.java:168)
        at com.google.javascript.jscomp.JsAst.getAstRoot(JsAst.java:55)
        at com.google.javascript.jscomp.CompilerInput.getAstRoot(CompilerInput.java:122)
        at com.google.javascript.jscomp.Compiler.hoistNoCompileFiles(Compiler.java:1992)
        at com.google.javascript.jscomp.Compiler.orderInputs(Compiler.java:1890)
        at com.google.javascript.jscomp.Compiler.parseInputs(Compiler.java:1793)
        at com.google.javascript.jscomp.Compiler.parseForCompilationInternal(Compiler.java:982)
        at com.google.javascript.jscomp.Compiler.access$300(Compiler.java:102)
        at com.google.javascript.jscomp.Compiler$6.call(Compiler.java:964)
        at com.google.javascript.jscomp.Compiler$6.call(Compiler.java:961)
        at com.google.javascript.jscomp.CompilerExecutor$2.call(CompilerExecutor.java:101)
        at java.util.concurrent.FutureTask.run(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)

[Lakret]

I'm having the same problem as @chancyk. This issue breaks ClojureScript compilation with enabled optimizations on Windows.

[brad4d]

@blickly
I think you're the most familiar with this part of the code.

[blickly]

Looks like the relevant code here was added in: https://github.com/google/closure-compiler/commit/fa5af790fc86b8bde261a19152eb222d61458333#diff-153756dc1310b1c74308e9d07c4a93fa

It seems like @tadeegan (the author) is suggesting that the entire extractSourceMap step should be skipped if the SourceFile is not of the OnDisk variant.

[thheller]

FWIW in shadow-cljs I'm using a subclassed Compiler to work around this.

It might not be the cleanest approach but it did fix those issues. The case I wanted to fix was that Closure was trying to load source maps for [synthetic:1]. I'm not sure why but on linux this just return null but on Windows it failed with an Exception.

[ChadKillingsworth]

I believe this is fixed by #2921