elm-pages build crashes on Windows due to invalid path

[j-maas]

Unfortunately the fun from #81 continues. However, let's first deal with merging #82 and then come back to this.

When I run the patched version (i.e. the one from #82) with elm-pages build, it first builds everything correctly but then crashes:

$ elm-pages build
Running elm-pages...
Dependencies ready!
Success! Compiled 9 modules.

    Main ---> C:\Users\y0hy0h\AppData\Local\Temp\2020215-10588-1imhixo.aik1.js

10% buildingelm-pages DONE
100%
ERROR in closure-compiler: java.nio.file.InvalidPathException: Illegal char <:> at index 78: C:\Users\y0hy0h\Code\elm-pages-fix\node_modules\style-loader\dist\index.js!C:\Users\y0hy0h\Code\elm-pages-fix\node_modules\css-loader\dist\cjs.js!C:\Users\y0hy0h\Code\test-elm-pages\node_modules\highlight.js\styles\github.css
        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:94)
        at sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:255)
        at sun.nio.fs.AbstractPath.resolveSibling(AbstractPath.java:66)
        at com.google.javascript.jscomp.SourceMapResolver.getRelativePath(SourceMapResolver.java:102)
        at com.google.javascript.jscomp.Compiler.addSourceMapSourceFiles(Compiler.java:2824)
        at com.google.javascript.jscomp.Compiler.initBasedOnOptions(Compiler.java:537)
        at com.google.javascript.jscomp.Compiler.initModules(Compiler.java:517)
        at com.google.javascript.jscomp.AbstractCommandLineRunner.doRun(AbstractCommandLineRunner.java:1248)
        at com.google.javascript.jscomp.AbstractCommandLineRunner.run(AbstractCommandLineRunner.java:554)
        at com.google.javascript.jscomp.CommandLineRunner.main(CommandLineRunner.java:2158)
Duration: 2.4s

(Note that this is a subsequent run. In the first run, I saw all the images being generated. In this run, I guess they were already cached. In every run I encountered the error.)

[vViktorPL]

I think it has something to do with webpack, google closure compiler or closure-webpack-plugin. Perhaps this bug is related to this: webpack-contrib/closure-webpack-plugin#100 .

@y0hy0h: BTW, do you use Windows for production builds? Personally I use Windows only for development server which should work fine after #82 fix, and I leave production building process to the CI which runs on Linux. Perhaps, WSL (Windows Subsystem for Linux) or Docker is the only option to develop on Windows with this toolset without a pain...

[j-maas]

I'm currently trying it out, and for that I'm mostly on Windows (though I also have a Linux laptop on which I could work).

[dillonkearns]

Very interesting. Thanks for investigating @vViktorPL and @y0hy0h. This is very helpful, I appreciate it!

I've been really unhappy with Google Closure Compiler overall.

I used to use this package: https://www.npmjs.com/package/elm-minify

But based on this thread, that package was deprecated: https://discourse.elm-lang.org/t/comparing-uglifyjs-and-google-closure-compiler/2883/4

But given that the Google Closure Compiler is causing so many issues, it seems like the minor performance gain (in some cases) is not worth it at all.

Is anybody up for doing a custom elm-pages build with the Google Closure Compiler step turned off, and letting me know if that fixes the issues on Windows? If so, then maybe we can replace it with UglifyJS using these flags: https://guide.elm-lang.org/optimization/asset_size.html.

[j-maas]

Ok, it seems that disabling the minimizer (Google Closure Compiler) makes it build on Windows. I simply made the minizimer array empty.

In the starter repo, after this change, webpack warns me that the main.js asset is big at 663 KiB (as well as images/author/dillon.jpg). It has thus completed the build successfully.

Unfortunately, I have trouble testing the minifiers. I'm a bit overwhelmed by how to install Google Closure Compiler and unfortunately, the online app at https://closure-compiler.appspot.com/home just crashes with an unhelpful error code. Uglifyjs (installed via npm install uglify-js, note the dash) seems to have trouble with the generated JS's syntax:

Parse error at dist/main.js:1754,0
const {
^
ERROR: Unexpected token: keyword «const»

I'm gonna stop tinkering with this for the day, but feel free to leave me suggestions on what to try. :)

[dillonkearns]

Thanks so much for testing that out @y0hy0h and confirming that the issue is with Google Closure Compiler 👍

So I did some research, and I think I've got a promising approach.

Context

As I mentioned earlier, this nice package, elm-minify, was deprecated because it performed 3-4 times slower than Google Closure Compiler.

However, I've done some research, and I believe that using the latest uglifyjs-webpack-plugin (not the older version that's built into Webpack) will speed things up.

In particular, setting the parallel flag is highly recommended in the docs:

And this blog post touches on the speed improvements that this change contributed (among other unrelated topics): https://medium.com/box-tech-blog/how-we-improved-webpack-build-performance-by-95-864a3a919d69

For reference, here's the original code for the elm-minify webpack plugin. You can see that it doesn't set the parallel flag. I think that this should give us solid performance, allowing us to get rid of the Google Closure Compiler which has caused several problems 👍

[j-maas]

Just a quick note on the proposal: Setting parallel: true instead of a fixed number appears to adapt to the CPU cores.

[dillonkearns]

Yeah, thanks for confirming that, I saw that too and was wondering why all the examples didn't just set it to true 🤔 Kind of odd, seems a lot simpler.

Digging into this a little more, it looks like the elm-minify plugin did some clever stuff to make sure it doesn't use the Elm terser minify options for other JS code. I think we'll have to do something similar.

https://github.com/opvasger/elm-minify/blob/master/src/api.js#L59-L61

[j-maas]

Could all files that are generated from Elm be marked? Something like main.elm.js to make it simple to detect which files to apply the options to?

[dillonkearns]

It looks like using webpack-sources you can already get that metadata, which is nice.

I'll need to do some research and experimentation to try to get that working, though.

[j-maas]

So I had another look at this issue.

First of all, uglifyjs is abandoned. Luckily, there is a replacement, terser, which works like a charm!

I tried it out online using the following config (which are the same arguments as with uglifyjs, just in JSON format) and it reduced main.js from 755.421 bytes to 172.738 bytes.

// edit terser options
{
  "compress": {
    "pure_funcs": "F2,F3,F4,F5,F6,F7,F8,F9,A2,A3,A4,A5,A6,A7,A8,A9",
    "pure_getters": true,
    "keep_fargs": false,
    "unsafe_comps": true,
    "unsafe": true
  },
  "mangle": {},
  "output": {},
  "parse": {},
  "rename": {},
}

I even replaced the previous Google Closure Compiler webpack plugin with the terser plugin and it simply works. main.js is only 174.259 bytes big.

I have opened PR #90 where you can see and try out these changes.