Allow configuring or suppressing the logger in InlineCriticalCssProcessor (beasties)

[eneajaho]

Command

build

Description

The InlineCriticalCssProcessor (powered by beasties) used during SSR emits b calls for every it cannot resolve from the server manifest. There is currently no way to configure, suppress, or redirect this logger.

In applications that dynamically load stylesheets at runtime (e.g., multi-brand theming systems where CSS bundles are resolved from a backend manifest and injected as tags during SSR rendering), these warnings fire on every SSR request for every dynamically-loaded stylesheet. The warnings are non-fatal — the tags remain in the HTML and the browser loads them normally — but the log volume is enormous.

In our production environment, this single warning pattern generated ~155 million log entries in 4 days, significantly increasing observability/logging costs.

Describe the solution you'd like

In @angular/ssr, the AngularServerApp constructor creates the InlineCriticalCssProcessor with a hardcoded logger:

// node_modules/@angular/ssr (simplified)
new InlineCriticalCssProcessor((path: string) => {
  const fileName = path.split('/').pop() ?? path;
  return this.assets.getServerAsset(fileName).text();
});

The InlineCriticalCssProcessor (which extends beasties) is constructed with:

logger: {
  warn: s => console.warn(s),
  error: s => console.error(s),
  info: () => {}
},
logLevel: 'warn',

When getCssAsset() fails to read a file, beasties calls:

this.logger.warn?.(`Unable to locate stylesheet: ${filename}`);

This goes directly to console.warn with no way to:

• Suppress specific warnings
• Redirect to a structured logger (e.g., Pino/Winston)
• Configure the log level
• Filter by pattern

Describe alternatives you've considered

Option A: Allow passing a custom logger via AngularServerApp options

const engine = new AngularAppEngine({
  inlineCriticalCss: {
    logger: {
      warn: (msg) => { /* custom handling */ },
      error: (msg) => { /* custom handling */ },
    }
  }
});

Option B: Allow configuring the log level for beasties

const engine = new AngularAppEngine({
  inlineCriticalCss: {
    logLevel: 'error' // suppress warn-level messages
  }
});

Option C: Allow disabling the warning for unresolved stylesheets specifically

const engine = new AngularAppEngine({
  inlineCriticalCss: {
    warnOnMissingStylesheet: false
  }
});

Any of these would allow applications to handle this case without monkey-patching console.warn.

Alternatives Considered

• Monkey-patching console.warn to filter messages containing "Unable to locate stylesheet" — this is what we're currently doing as a workaround, but it's fragile and affects all console.warn calls globally.
• Disabling inlineCriticalCss entirely via build config — this sacrifices the optimization for all stylesheets, not just the dynamically-loaded ones.
• Preventing stylesheet injection during SSR — this requires changes to application code and may break other SSR behaviors that depend on stylesheets being present in the rendered HTML.