Any advice on getting production builds to complet...

# compose-web

[Mike Digman]

Any advice on getting production builds to complete? Running any form of ./gradlew jsBrowserProductionWebpack or jsBrowserProductionRun spins infinitely on the webpack step. Works with no issue with the Development variants. With Compose MPP 1.4.0 and Kotlin 1.8.20.

[Mike Digman]

The task just spins at:

<============-> 96% EXECUTING [8m 6s]
> :js:jsBrowserProductionWebpack > 92% sealing asset processing TerserPlugin

[Oleksandr Karpovich [JB]]

No luck reproducing it. Would it stuck in every project for you?
I tried a simple hello world and this one - https://github.com/JetBrains/compose-multiplatform/tree/master/examples/html/landing
both work fine
Could you please try it too? Maybe we can find a root cause

__
Also I tried a canvas based app - https://github.com/JetBrains/compose-multiplatform/tree/master/examples/falling-balls - works too

[Mike Digman]

Thanks Oleksandr! Yeah, can confirm that running jsBrowserProductionWebpack on the falling-balls example works without an issue. I've tried my best to duplicate the patterns used for all the build.gradle and gradle.properties files - still no luck.

[Mike Digman]

Curiously, jsBrowserProductionWebpack sometimes (rarely) completes and nearly instantly. My suspicion is that a prior run completed the minification but progress wasn’t updated properly. I haven’t found a consistent way to repro. Time doesn’t seem to be the magic, tried waiting 4 hours (which failed) and immediately reran (which also failed):

<============-> 96% EXECUTING [3h 50m 14s]
> :js:jsBrowserProductionWebpack > 92% sealing asset processing TerserPlugin
> IDLE

[Mike Digman]

The main reason why I care is that I'm using a web provider to host that has a maximum file size of 32mb and jsBrowserDevelopmentExecutableDistribution is now generated a .js file over that threshold.

[Mike Digman]

Is there a way to disable TerserPlugin minification? Alternatively, is there a way to request the development executable be chunked into smaller .js files? Webpack supports it but I can’t find a way to configure the build to do so: https://webpack.js.org/guides/code-splitting/

[Oleksandr Karpovich [JB]]

Could you please run with --debug or --info?
Maybe we can see where it gets stuck.
__

It seems to be possible to disable the minimization in webpack config:

module.exports = {
  //...
  optimization: {
    minimize: false
  },
};

But it can probably produce a big js.

[Mike Digman]

Thanks again Oleksandr! Thanks to your help I managed to get a small enough js file size by turning off minification. My dev builds (jsBrowserDevelopmentExecutableDistribution) were coming out around 33mb and my jsBrowserProductionWebpack without minification ended up being about 12mb.

In case folks run into this in the future, I did this with the following configuration:

[Mike Digman]

In both build.gradle in js module and common module:

browser() {
    commonWebpackConfig {
        configDirectory = file(".")
    }
}

In file webpack.config.js in main directory:

config.optimization = { minimize: false }

[Mike Digman]

For what it’s worth, I did run ./gradlew jsBrowserProductionWebpack --info and ./gradlew jsBrowserProductionWebpack --debug. The output of the --info command wasn’t useful. Debug however, did show an endless file cycle of file locks and releases which might somehow be related to the underlying problem?

....
2023-06-05T09:48:30.952-0700 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
2023-06-05T09:48:30.952-0700 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
2023-06-05T09:48:30.952-0700 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on
...

[Mike Digman]

Some background research did turn up others having issues with minification being run by Webpack (ex https://github.com/webpack-contrib/terser-webpack-plugin/issues/21). The two primary solutions seemed to be 1) increase memory or 2) disable parallel running.

I tried both with no success - infinite run time. Increasing memory didn’t work:

export NODE_OPTIONS=--max_old_space_size=8192
./gradlew jsBrowserProductionWebpack

Changing webpack.config.js from above still caused the build to hang:

const TerserPlugin = require("terser-webpack-plugin");

config.optimization = {
    minimize: true,
    minimizer: [new TerserPlugin({
        parallel: false,
    })],
}

The only functional solution so far seems to be turning off minimization entirely.

[Oleksandr Karpovich [JB]]

Thanks a lot for extra details!

[Flo]

having the same problem, turning off minimization helps for the time being, thanks

[Chris Sinco [G]]

In file webpack.config.js in main directory

@Mike Digman which main directory exactly? Do you have a sample project? Running into this issue now as well

[Mike Digman]

Hey @Chris Sinco [G], that’d be wherever “.” is relative to the build file you put this in. See

browser() {
    commonWebpackConfig {
        configDirectory = file(".")
    }
}

For me that’s projectRoot / jsApp / webpack.config.js

[Mike Digman]

Because the hosting build file is in projectRoot / jsApp / build.gradle.kts

[Chris Sinco [G]]

Thanks! This worked!

[Chris Sinco [G]]

Though are we out of luck for getting any kind of minification for Compose JS/WAMS projects via Gradle tasks + webpack? Do we have to do it manually, e.g. with Uglify

[Greg Steckman]

I'm seeing the same issue. @Chris Sinco [G] I would think this isn't an issue with WASM because there is no need to minify JavaScript, since there is none (or very little needed only for a "bootstrap" loader?).

[Chris Sinco [G]]

So it turns out that at least for me the minification task spins forever because of the Material Icons extended library: https://kotlinlang.slack.com/archives/C01F2HV7868/p1694152150719539?thread_ts=1691256231.390929&channel=C01F2HV7868&message_ts=1694152150.719539

[Chris Sinco [G]]

Once I removed it, things were much better. Which is annoying since you have to manually add icons from that set individually, but it does do the minifying in reasonable time, and removing that library itself does reduce the size of the JavaScript files significantly

[Greg Steckman]

Great thanks for the tip. I did recently add the extended icons dependency.

[Oleksandr Karpovich [JB]]

I know it's an old thread 🙂 But anyway wanted to share the terser plugin cofnig which works quite well. For the original file 8MB with minimize: false , the new config makes it 2.7MB:

const TerserPlugin = require("terser-webpack-plugin");

config.optimization = config.optimization || {};
config.optimization.minimize = true;
config.optimization.minimizer = [
    new TerserPlugin({
        terserOptions: {
            mangle: true,    // Note: By default, mangle is set to true.
            compress: false, // Disable the transformations that reduce the code size.
            output: {
                beautify: false,
            },
        },
    }),
];

I also tried to use uglifyjs. With --compress option it failed to complete the task too. But with --mangle option only it produced a js file of 2.7MB too

[Greg Steckman]

It's an old thread, but the problem still persists for me with Compose 1.5.10 and Kotlin 1.9.20. Thanks for TerserPlugin config!

[Luca]

Beyond this terser plugin, is there any other tools/configs people are using to shrink the production bundle size?