Update version of css-minimizer-webpack-plugin to 8.0.0

[D3xime]

Hello everyone,

This morning i was doing some applicative maintenance, and discover that last version of Webpack-Encore has a dependency on vulnerable packages css-minimizer-webpack-plugin. I just found the package have patched the problems within the last version of package which have a major update from 7.x.y to 8.0.0. I don't know if you have been informed about that vulnerabilities, it's the main reason for this issue.

I stay in touch if you want to ask me anything.

Have a great day.
Déxime,
French FullStack Developper

[lucasmirloup]

+1

Link to the CVE: GHSA-hxcc-f52p-wc94

EDIT: corrected link : GHSA-5c6j-r48x-rmvq

[Kocal]

Hi, and thanks for the report.

Only version <3.1.0 of serialize-javascript contain this vulnerability, as shown by the link provided. There is no need to upgrade support of css-minimizer-webpack-plugin to 8.0.0 for security issues (which already use serialize-javascript@^6.0.2).

However, it could be interesting to accepts ^7.0.0 || ^8.0.0 as constraint version. Up for a PR? :)

[D3xime]

Hello,

To be more precise the new version patch this advisories.
GHSA-5c6j-r48x-rmvq
The old version didn't correct well the CVE. Upgrading will lead to some Breaking Changes because the packages you are depending onto have changed the minimum version for nodeJs from 18 to 20. I don't know if any other packages need to be upgraded. I will try to do some PR if i got time for it.

[Kocal]

Thanks for the precision!

[stof]

Version 8 requires node 20.9.0+, while webpack-encore currently supports node 18+. So this will need to be part of a new major version of webpack-encore (even a union of 2 major versions is not possible, as the compat with node versions is not taken into account when selecting the version of a dependency).

[Kocal]

It is not necessary if we use ^7.0.0 || ^8.0.0 as constraint version

EDIT: ah, didn't read the last part of your comment 🙈

[stof]

yeah, we are used to the nice behavior of composer where platform compatibility is part of the requirements of a package impacting the solver.

[lucasmirloup]

Oops my bad, wrong link 😁

[Kocal]

Since both Node.js 20 and 22 are in maintenance mode (see https://nodejs.org/en/about/previous-releases), I would rather switch to Node.js 24.

WDYT? Or let's keep things smooth and switch to Node.js 20?

[olivier1980]

Maintenance mode for node 20 ends in like a month, so 22 at the minimum seems a safer choice?

[stof]

I would indeed keep node 22 as it will stay supported for a long time. Keeping support for the maintenance LTS version of node seems to be the common thing in the ecosystem.
I agree about dropping node 20 as it will reach EOL in a month. It would not make sense for us to make 2 major versions in a short sequence just to keep support for node 20 for the last 2 months of its life.

Thus, node 22 has support for require(esm) (technically, node 20.17+ also has it), which would also us to convert the webpack-encore source code to ESM (see #1312). As this feature is available without an experimental flag and warning as of Node 22.13.0, I would use 22.13.0 as min version for the new major version of webpack-encore.

[Kocal]

I also feel like 22.13.0 would be the best choice. Well, let's start working on Webpack Encore 6 🙌🏻

[olivier1980]

Is the conversion to ESM (#1312) required or can it be postponed?

If it's a lot of work (which a quick scan of the issue, already started in 2024, seems to indicate) then to speed up the security patches it might be better to focus on the package upgrades first.