Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mitigate local dev memory leaks #1155

Merged
merged 1 commit into from
Apr 28, 2023
Merged

Mitigate local dev memory leaks #1155

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 5 additions & 1 deletion packages/pwa-kit-dev/src/configs/webpack/config.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -354,7 +354,11 @@ const renderer =
devtool: mode === development ? 'eval-source-map' : false,
output: {
path: buildDir,
filename: 'server-renderer.js',

// We want to split the build on local development to reduce memory usage.
// It is required to have a single entry point for the remote server.
// See pwa-kit-runtime/ssr/server/build-remote-server.js render method.
filename: mode === development ? '[name].js' : 'server-renderer.js',
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🥳 nice! Wild to think that the magic of [name].js is the fix here. Can you unpack and explain that?

Copy link
Collaborator Author

@kevinxh kevinxh Apr 27, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bfeister previously, our webpack build a single file server-renderer.js for SSR and this file is huge because it includes all dependencies and that file is about 50MB. Each time a change happens, webpack re-build this 50MB file and saves it in memory.

While we can't completely eliminate the memory leaks because it happens in 3rd party modules like global._, global['__core-js-shared__'], and there is also the bug in Node internal that actually holds on to references for dynamic imports. It's nearly impossible to eliminate the issue, but we can mitigate the issue by splitting the build into very small chunks, so each build would be much smaller, thus take less space in memory.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is amazing! I tested this PR on my local, not running into this issue once. Great job on finding the solution

libraryTarget: 'commonjs2'
},
plugins: [
Expand Down