Which stats preset balances CI/CD log verbosity with error trace completeness for deployment failure diagnosis?

Recommended preset

Use the minimal stats preset with errorDetails: true as the baseline for CI/CD deployment-failure logs. This keeps routine module listings out of the pipeline while retaining error context, changed assets, and stack/module or chunk traces.

Confirmed facts vs. likely explanation

Confirmed behavior

• Webpack stats presets differ in verbosity: errors-only is the quietest, minimal adds changed-asset context, and detailed or verbose produce substantially more output.
• errorDetails: true adds stack frames, module references, and chunk information to reported errors.
• Webpack CLI and programmatic API defaults can differ, so set the preset explicitly in CI configuration.

Likely explanation

minimal is the practical middle ground because deployment diagnosis usually needs the failing module or chunk and the assets that changed, not a full module inventory. errors-only may omit the asset context that helps correlate a failure with a recent deploy. detailed and verbose flood logs with information that incident reviewers rarely use.

Configuration steps

1. In the webpack config used by the pipeline, set:

module.exports = {
  stats: {
    preset: 'minimal',
    errorDetails: true,
  },
};

1. Run the pipeline build once with this config and inspect a representative failure log.
2. Confirm the log contains the error stack, failing module or chunk reference, and changed assets without routine module listings.
3. If warnings are also required for diagnosis, enable them deliberately rather than switching to detailed.

Sensitive-path exposure

Enabling errorDetails can reveal absolute filesystem paths, usernames, module identifiers, chunk names, and stack frames. These are not automatically secrets, but CI logs are often broadly accessible. Treat CI logs as potentially sensitive: restrict access, set retention, and redact paths or identifiers if your threat model requires it.

JSON stats stability

Do not treat the JSON stats schema as a stable contract across webpack 5.x patches. Pin the exact webpack version in the pipeline, parse only named fields, and tolerate missing or added fields. Re-run validation after any webpack upgrade.

Cache and stale artifacts

Excluding the filesystem-cache directory from deployment artifacts prevents shipping cache contents, but it does not by itself prevent stale compilation. Cache invalidation must track source files, webpack configuration, and dependency-lock changes.

Missing diagnostic detail

Are deployment-failure logs consumed only by human reviewers, or also by automated tooling? If automated parsing is required, JSON stats become necessary and the schema-pinning step above changes from optional to mandatory.

Verification

• Compare minimal against errors-only and detailed on one representative failure; retain the least verbose setting that still provides the stack, module or chunk context, and changed assets your incident process uses.
• Inspect a sanitized CI log sample for absolute paths, usernames, internal hostnames, and chunk identifiers, then verify log access and retention controls.
• Generate JSON stats with the pinned webpack version, parse the named fields required by the analyzer, and test graceful handling when an expected field is absent.

This is a conservative draft pending verification against the exact webpack version pinned by your pipeline.