webpack

This error occurs because older webpack versions use MD4 hashing, which is disabled by OpenSSL 3 in Node.js 17. Upgrade webpack to 5.61.0 or newer: npm install webpack@^5.61.0 --save-dev, then rebuild. As a temporary workaround, use Node.js 16 (nvm use 16) or enable the legacy OpenSSL provider: on Linux/macOS run export NODE_OPTIONS=--openssl-legacy-provider; on Windows CMD run set NODE_OPTIONS=--openssl-legacy-provider; in PowerShell run $env:NODE_OPTIONS="--openssl-legacy-provider". Then run your build again.

Upgrade minimizer-webpack-plugin to version 5.12.0 or newer; the regression was present in 5.8.0. With Yarn, run:

yarn up minimizer-webpack-plugin@^5.12.0

With npm:

npm install minimizer-webpack-plugin@^5.12.0 -D

Then reinstall dependencies and rebuild. Verify the resolved version with yarn why minimizer-webpack-plugin or npm ls minimizer-webpack-plugin. Updating from 5.8.0 to 5.12.0 resolves the invalid as: 'script' option passed to Terser when minifying JavaScript embedded in HTML.

This is a webpack 5 bug, reproduced in webpack 5.111.1. Stats.hasErrors() reads compilation.errors directly, while stats.toJson().errors and getErrors() apply the compilation.hooks.processErrors waterfall hook. Therefore, filtering errors in processErrors removes them from the output but does not change hasErrors().

The fix is to route hasErrors() through getErrors(), matching hasWarnings():

hasErrors() {
  return (
    this.compilation.getErrors().length > 0 ||
    this.compilation.children.some((child) => child.getStats().hasErrors())
  );
}

Upgrade webpack to a release containing the fix for issue #22279. Until then, do not rely on stats.hasErrors() when a plugin filters errors through processErrors. Use the processed error list instead:

function hasProcessedErrors(compilation) {
  return (
    compilation.getErrors().length > 0 ||
    compilation.children.some(hasProcessedErrors)
  );
}

const hasErrors = hasProcessedErrors(stats.compilation);

Alternatively, check the rendered stats output with stats.toJson().errors.length, accounting for child compilations if your build uses them.

This is a bug in webpack's browserslistTargetHandler (confirmed in webpack 5.111.1 and main). When a target has only a major version, such as safari 10, its missing minor version becomes NaN. In the equal-major check, NaN >= 0 is false, so features first supported at [10, 0] are incorrectly considered unsupported.

Fix: treat a missing minor version as 0 before comparing:

const parserMinor = Number(parser.minor ?? 0);

if (
  Number(parserMajor) === requiredVersion[0] &&
  parserMinor >= requiredVersion[1]
) {
  // feature is supported
}

Apply the upstream patch for webpack issue #22278 or use patch-package until a fixed webpack release is available. As a temporary workaround, use an explicit minor version where possible, such as safari 10.0, though some Browserslist queries may normalize it back to a bare major version.

This is a webpack bug in native CSS mode (experiments.css: true). When a CSS rule uses parser: { exportType: "style" } and an @import "./ignored.css" target is ignored (via IgnorePlugin or resolve.alias: { "...": false }), moduleGraph.getModule(dep) returns null and CssGenerator._generateImportExpressions crashes reading depModule.userRequest. Fixes: 1) Upgrade webpack to the release containing this fix (PR for issue #22842 adds a null check). 2) Temporary patch: in node_modules/webpack/lib/css/CssGenerator.js, inside _generateImportExpressions, add if (!depModule) continue; right after const depModule = moduleGraph.getModule(dep); (use patch-package to persist it). 3) Alternative workaround: stop ignoring the CSS file—remove the IgnorePlugin/resolve.alias: false entry for that stylesheet, or switch the rule to exportType: "css-style-sheet" / "link" if feasible, since the crash only occurs with exportType: "style".