Css-loader version 4.2.2 offers subtle but impactful improvements over its predecessor, version 4.2.1. While the core functionality of enabling CSS files to be used as modules within webpack remains the same, several dependency updates and internal refinements contribute to a better developer experience.
A key difference lies in the updated dependencies. Version 4.2.2 upgrades @commitlint/cli and @commitlint/config-conventional to version 10.0.0 (from 9.1.2 and 9.1.1 respectively), mini-css-extract-plugin to version 0.10.0 (from 0.9.0), and standard-version to version 9.0.0 (from 8.0.2). Some dev dependencies like @babel/core and webpack also contain minor version upgrades. These updates likely incorporate bug fixes, performance enhancements, and compatibility adjustments within those specific tools. While normalize-path was removed as a dependency, this change implies a refactoring to handle path normalization internally or through another existing dependency. This could potentially improve the loader's efficiency.
The slight increase in "unpackedSize" from 109756 to 114550, along with the minor difference in fileCount, also suggests adjustments in the codebase or included assets. Developers upgrading should test their configurations with the new version to ensure compatibility with existing webpack setups and CSS processing pipelines. The update aims to provide smoother integration with the latest tooling and potentially improves upon stability and future compatibility.
The package release date increased from August 6th to August 24th, and developers are encouraged to review the changelog for a complete list of changes.
All the vulnerabilities related to the version 4.2.2 of the package
PostCSS line return parsing error
An issue was discovered in PostCSS before 8.4.31. It affects linters using PostCSS to parse external Cascading Style Sheets (CSS). There may be \r discrepancies, as demonstrated by @font-face{ font:(\r/*);} in a rule.
This vulnerability affects linters using PostCSS to parse external untrusted CSS. An attacker can prepare CSS in such a way that it will contains parts parsed by PostCSS as a CSS comment. After processing by PostCSS, it will be included in the PostCSS output in CSS nodes (rules, properties) despite being originally included in a comment.
