Maximum call stack size exceeded after fullOptJS

[armanbilge]

Reported by @buntec:

I now run into a “maximum call stack size exceeded” exception in one of the projects at work using ff4s when making a simple GET request using ‘client.expect’. The source map points to line 255 in ‘MediaType.scala’, which looks innocuous to me. According to the call stack this seems to happen during entity decoding. I’m using 0.23.11. Strangely enough, this only occurs in the fully optimized js bundle; not during development when using fastOpt.

This sounds a lot like:

• Site is broken b/c of JS stack overflow #33

If we look at the reported line:

object MediaType extends MimeDB {

https://github.com/http4s/http4s/blob/v0.23.11/core/shared/src/main/scala/org/http4s/MediaType.scala#L255

It leads us to our old friend:

• Reduce the impact of MimeDB on JS size #30

The current workaround is to disable GCC in fullOptJS with:

scalaJSLinkerConfig ~= { _.withClosureCompilerIfAvailable(false) }

I would like to explore alternative minimizers to GCC such as ESBuild:
https://esbuild.github.io/api/#minify

I also have a plan to fix #30 in http4s/http4s#5273. It is quite a bit of work to do binary-compatibly, but feasible I think.

[armanbilge]

I would like to explore alternative minimizers to GCC such as ESBuild

Note: minifiers are not the same as optimizers. The ESBuild minifier reduces the 12 mb (!!) fetch demo to 6 mb. Meanwhile the closure compiler reduces it to 2 mb, albeit introducing the stack overflow problem. So I think the only way forward is to fix this in http4s core.

[armanbilge]

Update: it seems the correct way to disable the closure compiler is like this. H/t Christoph.

scalaJSLinkerConfig ~= { _.withClosureCompiler(false) }

[armanbilge]

I've PRed a fix upstream in http4s/http4s#6211. Please try the snapshot (instructions in PR :)

[armanbilge]

I can confirm the PR snapshot fixes the similar problem I experienced in #33 🎉