You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After the v0.6 release — the first since we moved to Vue CLI (see #217) — it stopped being possible to build Frontend on a Digital Ocean droplet with 1 GB of memory (forum topic).
it takes webpack ~1065MB of active memory (and something over 3GB of virtual memory) to build the frontend..
so the memory profile is sort of interesting; there's a main process that balloons to ~485MB while it's building the "legacy bundle", and then (without freeing any memory) it spawns a second process that builds the .. whatever the nonlegacy bundle is i can't remember. modern? and that one balloons out the rest of the ~1100MB. then both quit the moment it's done. so if somehow those could be separated that would help but.. it still just seems weirdly excessive.
I don't see any Vue CLI options related to memory/space. However, there are probably changes we could make to the webpack configuration.
Also, currently it does not seem possible to build the modern bundle without also building the legacy bundle, which means that we aren't able to build the legacy bundle, then separately build the modern bundle.
Note that we do want to reduce our bundle size (see #232). However, we think that that is an unrelated issue.
For now, we will build Frontend without using modern mode: we will build only the legacy bundle. From a quick look, our modern bundle seems to be about 9% smaller than our legacy bundle. According to the Vue CLI documentation, the code in the legacy bundle may also run more slowly compared to the modern bundle, though I'm not sure by how much.
The text was updated successfully, but these errors were encountered:
After upgrading to Vue CLI v5 (#669), I see the following message when I run npm run build:
All browser targets in the browserslist configuration have supported ES module.
Therefore we don't build two separate bundles for differential loading.
Starting with v5.0.0-beta.0, running vue-cli-service build will automatically generate different bundles based on your browserslist configurations. The --modern flag is no longer needed because it is turned on by default.
In other words, previously we built just a legacy bundle, and now we're building just a modern bundle. I think that's a sensible change, and we haven't run into any issues during regression testing. Previously, we wanted to build both legacy and modern bundles, but opted just for legacy. Now I think it's safe to be building just a modern bundle.
I'm going to go ahead and close this issue, because we're now building a modern bundle without the memory overhead of a second process. We're also planning to move to Vite (#671), so we probably wouldn't want to invest in changes to our webpack configuration anyway. Also, end users won't be affected by memory usage if we prebuild Frontend, which we're considering as part of getodk/central#347.
After the v0.6 release — the first since we moved to Vue CLI (see #217) — it stopped being possible to build Frontend on a Digital Ocean droplet with 1 GB of memory (forum topic).
@issa-tseng writes on Slack:
I don't see any Vue CLI options related to memory/space. However, there are probably changes we could make to the webpack configuration.
Also, currently it does not seem possible to build the modern bundle without also building the legacy bundle, which means that we aren't able to build the legacy bundle, then separately build the modern bundle.
Note that we do want to reduce our bundle size (see #232). However, we think that that is an unrelated issue.
For now, we will build Frontend without using modern mode: we will build only the legacy bundle. From a quick look, our modern bundle seems to be about 9% smaller than our legacy bundle. According to the Vue CLI documentation, the code in the legacy bundle may also run more slowly compared to the modern bundle, though I'm not sure by how much.
The text was updated successfully, but these errors were encountered: