terserplugin parallel = 1

[samuelwshen]

Overview

Followup to flare-1195, let's set this limiter as the default for frontend repos.

[samuelwshen]

I'm testing whether we can actually allocate n cores, so far seems ok but leaving this here for now.

[dxu429]

You may want to add this package as a dev dependency to package.json

[samuelwshen]

can I just add it manually or do I have to go through the npm install... process?

[taylor-sutton]

You can figure out the changes needed by doing an ark init --local-only --template-ref <this branch> and the other flags ark init needs, then doing an npm install, then porting the diffs over here.

[johnhuangclever]

Sorry, just wanted to understand:
What is this trying to achieve and how is it related to the flare? Minifying code seems adjacent to any build problems unless I have misunderstood

[samuelwshen]

Sorry, just wanted to understand: What is this trying to achieve and how is it related to the flare? Minifying code seems adjacent to any build problems unless I have misunderstood

@johnhuangclever the root cause of the failed builds seems like it was terser asking for too many resources from Circle CI. Circle CI doesn't proactively communicate its available resources and apparently this can cause the webpack plugin to fail. so this template change should prevent the failures we saw from the flare.

[johnhuangclever]

So a few questions:

• Is our intention to enable the terser plugin for minification for all new frontend repos?
• Have we verified that the build for a new frontend template will run out of resources or is it just sd2 since sd2 has a huge code surface area? Technically if we can make the terser plugin run faster by using parallelization that's a good thing as long as it doesn't run out of resources
• Is using resource_class: large a no-go for us?

[samuelwshen]

@johnhuangclever

1. terser is the default packer (?) that webpack uses so I think it's already enables with new frontend repos (at least it seems to have come with SD2 out of the box)
2. it's SD2 having a huge code surface area. You're right we might be able to also up parallelization, but I haven't done enough testing with upped parallelization to be confident that build process is stable. The default resource class allocates 2vCPUs, so I'm not 100% confident yet that allocating 2/2 vCPUs to the webpacker is safe
3. We can do that, though it doesn't theoretically solve the problem of the webpack plugin being able to ask for more resources than it can access (it just raises the failure point).

I think the 2 paths forward are

1. keep this as a safe default option, if not quite as fast as it could be
2. up parallelization to 2 and size to large (or even just medium+) for performance buff and confidence in stability

[johnhuangclever]

Based on my googling, https://webpack.js.org/plugins/terser-webpack-plugin/ seems like it should not be enabled by default? Unless I have misunderstood the docs

And I think any solution we have has the limitation of a theoretical failure point on our CI. Even with the parallelization at 1 there is still a failure point at some point and if we had the choice between slowing down our builds vs speeding them up, I'd rather speed them up provided we have enough headroom if that makes sense.

e.g. If the failure point for a new repo is to get to the size of sd2 I think that would be plenty headroom for us imo

[samuelwshen]

My understanding of the docs is that it runs by default and has some default options baked in, but to configure the options you need to pull in the dependency manually. It seems like in SD2 at least, terser-webpack-plugin existed in package-lock prior to us mucking with it so it was pulled in transitively.

Let's just bump it to medium+ and parallelization: 2

[johnhuangclever]

okay, this is an interesting read:
https://v4.webpack.js.org/plugins/terser-webpack-plugin/#parallel

Looks like it links to webpack-contrib/terser-webpack-plugin#143 which potentially talks about the issue we're running into in circleCI (although they mention running into the problem on terser v2 not v2). If what I'm reading is correct, if we use 2 vCPUs in circle by default, then setting the parallel to 2 should be good enough to get things to run properly without running into errors

If this is the proper underlying cause of the issues we're seeing it's probably worth to put these links into the webpack config comments