Hi @jakwinkler. Thank you for your contribution!
Here are some useful tips on how you can test your changes using Magento test environment.
❗ Automated tests can be triggered manually with an appropriate comment:

• @magento run all tests - run or re-run all required tests against the PR changes
• @magento run <test-build(s)> - run or re-run specific test build(s)
  For example: @magento run Unit Tests

<test-build(s)> is a comma-separated list of build names.

You can find more information about the builds here
ℹ️ Run only required test builds during development. Run all test builds before sending your pull request for review.

For more details, review the Code Contributions documentation.
Join Magento Community Engineering Slack and ask your questions in #github channel.

@magento run all tests

@magento run all tests

@jakwinkler, please review the comments from Copilot and let us know if you would like anything to be fixed based on them. If no, I'll review the pull request

@magento run all tests

@magento run all tests

@engcom-Hotel, this is more about platform health - replacing old not supported tools that currently Magento using with the ones that supported. I do agree that the selected tool has to be reviewed, but I don't think it can be treated as a feature request.

@engcom-Hotel I agree with @ihor-sviziev, this is not a feature but a require step in maintaining platform health. Tests fail on none-related part of the code to that PR...
Messages and comments like this are very discouraging...

I've updated lib/internal/Magento/Framework/composer.json file, hoping all tests will pass

@magento run all tests

Thank you @ihor-sviziev and @jakwinkler for your valuable feedback on this PR. I completely agree with your assessment that this is a platform health improvement rather than a feature request.

Replacing outdated and unsupported minification libraries with maintained alternatives like matthiasmullie/minify is indeed a necessary maintenance step to ensure the platform's stability, security, and performance.

I've already sent an email to the PO explaining the importance of this change for platform health and requesting approval. I've emphasized that:

1. This addresses technical debt by replacing unmaintained dependencies
2. Improves security posture through actively maintained code
3. Provides better minification for modern JS/CSS

I appreciate your patience and contributions to maintaining Magento's platform health. I'll update this thread once I receive feedback from the PO.

Thank you for your continued support.

@engcom-Hotel,
I fully agree with the points raised by @ihor-sviziev and @jakwinkler.
Unfortunately, in recent years, Magento has become increasingly slow and conservative when it comes to adopting new libraries or updating deprecated ones — even when those changes are critical for platform health and long-term sustainability.
Efforts like this PR are essential to keep the ecosystem viable and reduce the burden on both maintainers and merchants. I hope we can prioritize such improvements accordingly.

@magento run all tests

Hi @jakwinkler,

Thank you for your contribution! The Magento core engineering team is working on the issue which you have addressed in this PR. Team will cherry pick the commits from your PR and may do further implementation to cover few more scenarios as needed. We will reach out to you if we need more information. For now, you can pause work on this PR. Thank you once again!

@magento create issue

Hi Everyone,

As part of our investigation, we compared JShrink and MatthiasMullie Minify libraries to evaluate frontend performance and build output differences.

🔍 Summary of Findings:

• Frontend Performance:
  Based on Lighthouse analysis, the overall performance metrics are nearly identical between JShrink and MatthiasMullie Minify.

• File Size Comparison:
  Using the command below, we measured the total size of all generated JavaScript and CSS files:

  find pub/static/frontend -name "*.js" -type f -exec ls -l {} \; | awk '{total += $5} END {print total/1024/1024 " MB"}'
  

  

  The results show only a marginal reduction in file size with MatthiasMullie Minify, which does not offer a substantial performance benefit.

⚙️ Additional Performance Validation:
We also configured and executed Lighthouse and JMeter tests to analyze overall frontend performance.
Please find the comparison screenshots below, and download the attached .zip files for detailed, library-wise performance reports.

jshrink_jmeter_report_20251013_161328.zip
matthiasmullie_jmeter_report_20251014_151151.zip

✅ Conclusion:
While MatthiasMullie Minify generates slightly smaller minified files, the overall performance improvement is negligible.
Based on these results, we currently do not recommend replacing JShrink.

However, we welcome any additional opinions or insights from the team before closing this evaluation.

Hey ChatGPT @glo71317 , but performance wasn't mentioned as the benefit that we suppose to get. Instead - its replacing old and not well maintained library to the one which is supported and has test coverage

Hey ChatGPT @glo71317 , but performance wasn't mentioned as the benefit that we suppose to get. Instead - its replacing old and not well maintained library to the one which is supported and has test coverage

@ihor-sviziev I agree with your statement — we have already evaluated this from all possible aspects and shared the details.

Regarding your point about choosing a well-maintained library with better code coverage, based on my analysis, I didn’t find any evidence indicating that the current package is poorly maintained or lacks sufficient test coverage.

Please refer to the following details I reviewed — both packages are being released frequently, and the code coverage appears to be good in both cases.
https://packagist.org/packages/tedivm/jshrink
https://packagist.org/packages/matthiasmullie/minify

Kindly let me know if there’s anything I might have missed or if you have any additional insights to share.

@jakwinkler, can you please clarify?

Please let us know if anyone has a different opinion. Otherwise, we are planning to close this PR and the respective GitHub issue, as we’ve agreed that no action is required at this time.