Vít Šesták

I have not experienced such issue with Duplicity. I have managed to perform incremental backup on roughly 15GiB (after exclusions) of various data (many small files and few large files)...

Aha, good point. So, IIUC, create_config_file generates randomized XML and it is cached in `/var/lib/xen/userdata-d.*` files. So, it can survive some reboots, and thus it is reordered far less often...

The failure on Windows is likely related to argument quoting/escaping. Maybe I should get a Windows VM and debug it there.

@Lukah0173 Thanks for linking the relevant issues. Terser looks cool, I'll probably try it. Does it affect 3rd party JS (non-Scala.js) libraries? I think they deserve a more conservative approach...

I have similar list of JS dependencies (bootstrap, chart.js, moment +tz, chartjs-adapter-moment and comma-separated-values). The resulting size is much better, but still by ~330KiB larger than it is with closure...

I still believe there must be a way to proceed with Google Closure Compiler, even with few hacks. I believe I've almost reached the result, albeit with some hacks: 1....

Makes sense, but I wonder why it works with CommonJS modules. IIUC, there should be the same issue.

In my experiment, I've replaced all external JS imports (i.e., those that don't start with "./"*) by require function call before passing to GoCC, so the reason shouldn't be there....

Aha, I got it. Scala.js [uses withOptimizeBracketSelect(false)](https://github.com/scala-js/scala-js/blob/b8fb2f28aff3dac46e35c101550c732bf0dbe562/linker/jvm/src/main/scala/org/scalajs/linker/backend/closure/ClosureLinkerBackend.scala#L59) when using GoCC, so GoCC doesn't mangle the references. With ES module, there is no way to configure optimizeBracketSelect, so GoCC mangles it....

I hope I can make GoCC reliably working with ES modules. It should work even for multi-module projects (internal modules are inlined). Inlining seems to be a suitable option for...