Disable server bundle minification

[oscar-escire]

References

• Fixes Production server clogs the logs on breaking exceptions #4124
• Malware-Free PR of fix: disable server bundle minification for readable error stack traces #5162

Description

Disable minification for the server-side webpack bundle to produce readable error stack traces in production.

Instructions for Reviewers

1. Add throw new Error('hello world') anywhere in the body of server.ts to simulate an uncaught error
2. Rebuild with yarn build:prod
3. Start with yarn serve:ssr
4. Before this fix: The entire minified file gets printed to the log, making it impossible to determine what went wrong
5. After this fix: The stack trace shows the specific line where the error occurred, with readable code

List of changes in this PR:

• Added optimization: { minimize: false } to webpack/webpack.prod.ts to disable minification of dist/server/main.js

Notes:

• The server bundle only runs on the server and is never sent to browsers, so minification provides no benefit
• mode: 'production' is preserved, so tree-shaking and other production optimizations remain active
• The browser bundle (webpack.browser.ts) is unaffected and remains minified

Checklist

• My PR is created against the main branch of code (unless it is a backport or is fixing an issue specific to an older branch).
• My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
• My PR passes ESLint validation using npm run lint
• My PR doesn't introduce circular dependencies (verified via npm run check-circ-deps)
• My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
• My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
• My PR aligns with Accessibility guidelines if it makes changes to the user interface.
• My PR uses i18n (internationalization) keys instead of hardcoded English text, to allow for translations.
• My PR includes details on how to test it. I've provided clear instructions to reviewers on how to successfully test this fix or feature.
• If my PR includes new libraries/dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
• If my PR includes new features or configurations, I've provided basic technical documentation in the PR itself.
• If my PR fixes an issue ticket, I've linked them together.

[lgeggleston]

Marking as Reviewer approved due to the testing done by @alegontarz.

[ybnd]

I can confirm that this solves the original issue.

[tdonohue]

@oscar-escire and @ybnd : While I can understand the reason behind this PR, I'm a little concerned that this change in minification drastically increases the size of main.js from about 8MB to over 15MB.

While I understand it's very useful for debugging, I'm a little worried this will have performance impacts because of the size increase (even though I realize this main.js on the server side is not downloaded to a user's browser). Are we certain that this won't impact SSR or initial load time in production scenarios? I'm hesitant to merge this without more analysis regarding performance.

The alternative would be to find a way to make this more configurable. Sites could then choose to enable it or enable temporarily when they are debugging a specific issue.

[oscar-escire]

@tdonohue and @ybnd: I'm looking into whether it's possible to make this configurable. As soon as I have an update, I'll let you know.

[oscar-escire]

@tdonohue and @ybnd: I've tested a few alternatives for this PR, but in the end, the best option is still to use minimize: false for debugging. To avoid the issue with the size of main.js, I've made it work as a parameter and added a command called serve:ssr:debug that lets you choose whether to use minimize or not.

[ybnd]

The environment variable is a good idea, only some small notes on the Node scripts

[ybnd]

Could you "align" the name of this script with the others?

• serve:* → only starts the server
• build:* → only builds
• start:* → builds and starts immediately after

Maybe we could use two scripts for this:

• build:prod:debug
• start:prod:debug

We may also need the cross-env NODE_ENV=production part for other parts of the code to properly recognize that it is running in production mode?