Enable minification in production builds

[HarkiratS1511]

Fixes #7736

Description

Enables minification in production webpack builds by changing minimize: false to minimize: true in app/webpack.prod.config.js.

Problem

The published frontend assets were ~63MB compared to JupyterLab's ~17MB, despite using the same underlying technology. Investigation revealed that the production webpack configuration explicitly disabled minification.

Changes

• Changed minimize: false to minimize: true in app/webpack.prod.config.js (line 18)

Expected Impact

• Reduces asset size from ~63MB to ~17MB (approximately 73% reduction)
• Improves page load times
• Reduces bandwidth usage
• Faster pip/conda installations

Testing

Unable to test locally due to development environment constraints. The change is straightforward (single boolean flag), and CI will validate the build. Ready for maintainer review.

[github-actions]

👈 Launch a Binder on branch HarkiratS1511/notebook/fix-minification-7736

[krassowski]

• Reduces asset size from ~63MB to ~17MB (approximately 73% reduction)
• Improves page load times
• Reduces bandwidth usage

🎉

Faster pip/conda installations

Does it? It looks like the release artifacts actually ended up being larger than on main:

This is because the map files take up more space now, for example:

I wonder if there are some options for the minimizer/terser we should copy from JupyterLab (although I also think we should update those in JupyterLab as well): https://github.com/jupyterlab/jupyterlab/blob/21f9c73298d7a450dba9927d404c87aae3011f7a/jupyterlab/staging/webpack.prod.minimize.config.js#L21-L35

[HarkiratS1511]

Ah, I see what happened - the minification worked on the JS files themselves, but the source maps ended up bigger which defeated the whole purpose. Makes sense that the total package size increased instead of decreased.
Should I update the PR to use the TerserPlugin configuration you linked from JupyterLab?
Let me know if that's the right approach or if you'd prefer to handle this differently!

[krassowski]

I don't know which one would be optimal approach, this requires experimenting a bit and documenting the results. It feels like turning the comments off could help reduce the size further (if it is not a default already).

I don't mind the release tarball increasing slightly if it means faster load time, but we need to have data to support it.

[jtpio]

Reduces asset size from ~63MB to ~17MB (approximately 73% reduction)
Unable to test locally due to development environment constraints.

Curious how you were able to get these numbers without testing?

[jtpio]

Also the latest commit on main shows the following numbers:

https://github.com/jupyter/notebook/actions/runs/18644190793

While with this PR the numbers are slightly bigger?

https://github.com/jupyter/notebook/actions/runs/18612834945?pr=7748

[krassowski]

@jtpio yes this is due to map files increasing in size, see the collapsed details in my comment.

[HarkiratS1511]

@jtpio You're right to call that out - those numbers were an estimate based on comparing to JupyterLab's asset sizes, not actual testing. I should have been clearer that it was a projection, not a measured result.
Looking at the actual CI results you and @krassowski shared, I can see the minification worked on the JS files themselves, but the source maps grew enough to offset the savings.
I'm going to try to get my local environment set up properly so I can experiment with the TerserPlugin configurations @krassowski i mentioned. If I can get it working, I'll test different options and document the results. If I'm still having issues, I'll update here.
Thanks for the patience - still learning the ropes of webpack build tools!

[HarkiratS1511]

Hi so I've updated the PR with the TerserPlugin configuration from JupyterLab as you suggested.
I spent the last two days trying to get my local build environment working but kept hitting walls. Started with npm install errors (ERESOLVE conflicts), fixed those with --legacy-peer-deps. Then when I tried building, I got TypeScript compilation errors with the lib0 package - Type 'Uint8Array' is not generic.
Thought it might be a Node version issue since I was on v22, so I installed nvm and switched to Node v20. Did a fresh reinstall of all dependencies. Same errors. Tried adding skipLibCheck to the tsconfig files in individual packages - got 3 packages to build but 7 others still failing with the same lib0 issue.
At this point I'm just going in circles with environment setup, so I've pushed the TerserPlugin config from JupyterLab (same settings for compression, mangling, comments, etc.) and I'm hoping you can check if this actually improves the artifact sizes compared to my first attempt.
Could you let me know what the build results look like? Hopefully the source maps are more reasonable this time. If not, happy to try tweaking the settings based on what you see!

[krassowski]

@HarkiratS1511 if you face build issues feel free to ask on jupyter zulip chat or discourse maybe we could help out. What you describe could have happened if using say npm over yarn (or an older version of yarn) and thus ignoring the lockfile which resolves to versions that are known to work.

As for testing you can download the built artifact from CI it's the result of Check Release workflow on the summary apge e.g. for latest commit here https://github.com/jupyter/notebook/actions/runs/18709256519?pr=7748

[HarkiratS1511]

I see the artifact size went up to 30.6 MB instead of down.
I'm using the same TerserPlugin settings as JupyterLab, but the results are different. I'm wondering if the issue might be with how source maps are being generated - the config has devtool: 'source-map' which generates full source maps.
Do you think it's worth trying to either remove source maps entirely (devtool: false) or use a different source map strategy? Or is there something else in the build configuration I should be looking at?