closure-compiler
closure-compiler copied to clipboard
Closure compiler does not work on Windows at least if path contains UTF-8 characters
If an input file name contains non-7bit-ASCII characters in it, Closure fails to operate.
STR:
- Install Closure compiler to directory "☃äö Ć € 🦠". (not mandatory, but for good measure to see if any issues arise from that)
- Pass an input file "☃äö Ć € 🦠.js" to Closure compiler as
--externs
or--js
.
Results in
C:\☃em sd äö Ć € 🦠\emsdk\emscripten\main> dir äö.js
Volume in drive C has no label.
Volume Serial Number is 8847-8E7D
Directory of C:\☃em sd äö Ć € 🦠\emsdk\emscripten\main
03/16/2021 06:18 PM 3,472 äö.js
1 File(s) 3,472 bytes
0 Dir(s) 1,757,394,030,592 bytes free
C:\☃em sd äö Ć € 🦠\emsdk\emscripten\main> node_modules\.bin\google-closure-compiler --externs äö.js --js_output_file out.js --js a.js
[ '--externs', 'äö.js', '--js_output_file', 'out.js', '--js', 'a.js' ]
ERROR - [JSC_READ_ERROR] Cannot read file äö.js: äö.js
1 error(s), 0 warning(s)
C:\☃em sd äö Ć € 🦠\emsdk\emscripten\main> node_modules\.bin\google-closure-compiler --externs a.js --js_output_file out.js --js äö.js
[ '--externs', 'a.js', '--js_output_file', 'out.js', '--js', 'äö.js' ]
ERROR - [JSC_READ_ERROR] Cannot read file äö.js: äö.js
1 error(s), 0 warning(s)
- Pass UTF-8 chars as output file :
C:\☃em sd äö Ć € 🦠\emsdk\emscripten\main> node_modules\.bin\google-closure-compiler --js a.js --js_output_file äää.js
[ '--js', 'a.js', '--js_output_file', 'äää.js' ]
C:\☃em sd äö Ć € 🦠\emsdk\emscripten\main> dir *.js
Volume in drive C has no label.
Volume Serial Number is 8847-8E7D
Directory of C:\☃em sd äö Ć € 🦠\emsdk\emscripten\main
03/16/2021 06:18 PM 3,472 a.js
03/16/2021 06:24 PM 5,595 äää.js
2 File(s) 9,067 bytes
0 Dir(s) 1,757,393,338,368 bytes free
(The [ '--externs', 'äö.js', '--js_output_file', 'out.js', '--js', 'a.js' ]
print is one of my own added debug prints, trying to look if the proper path names even reach Closure, which they seem to do. Also did the test prints with simpler äö.js
filename to verify the extent of the failure to do UTF-8 handling)
Any chance we could get a fix for this? The current workaround in emscripten is kind of horrible.
Is this related to this error, that I get for a file with a cyrillic filename?
Filename: наиывпишв.js
And here is my command: "C:\Users\Chris\.netbeans\minifierbeans\custom-packages\google-closure-compiler.cmd" "--compilation_level" "SIMPLE" "--language_in" "STABLE" "--language_out" "ECMASCRIPT_NEXT" "--js" "C:/Users/Chris/Documents/NetBeansProjects/HTML5Application/public_html/наиывпишв.js" "--js_output_file" "C:/Users/Chris/Documents/NetBeansProjects/HTML5Application/public_html/наиывпишв.min.js"
And here is the error:
Exception in thread "main" java.nio.file.InvalidPathException: Illegal char <?> at index 71: C:/Users/Chris/Documents/NetBeansProjects/HTML5Application/public_html/?????????.js
at sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
at sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
at sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:229)
at java.nio.file.Path.of(Path.java:147)
at java.nio.file.Paths.get(Paths.java:69)
at com.google.javascript.jscomp.CommandLineRunner.findJsFiles(CommandLineRunner.java:2130)
at com.google.javascript.jscomp.CommandLineRunner.access$000(CommandLineRunner.java:134)
at com.google.javascript.jscomp.CommandLineRunner$Flags.getMixedJsSources(CommandLineRunner.java:1226)
at com.google.javascript.jscomp.CommandLineRunner.initConfigFromFlags(CommandLineRunner.java:1605)
at com.google.javascript.jscomp.CommandLineRunner.<init>(CommandLineRunner.java:1446)
at com.google.javascript.jscomp.CommandLineRunner.main(CommandLineRunner.java:2214)
Happens in my NetBeans plugin https://github.com/Chris2011/minifierbeans/issues/90
Anything new here? Still a problem in version "20211201.0.0".
I'm afraid we're just really not motivated to spend development effort on making non-ascii JS inputs work.
However, we'll be happy to review and merge a PR if someone in the community would like to create one.