Package install filter can silently drop lines from failing build scripts #12

compress_pkg_log filters line by line, and every drop rule is an unanchored, case-insensitive substring match. From src/pkg_cmd.rs:

static ref DEPRECATED_RE: Regex = Regex::new(r"(?i)(npm warn deprecated|WARN deprecated|deprecat)")
static ref ALREADY_SATISFIED_RE: Regex = Regex::new(r"(?i)already satisfied")
static ref USING_CACHED_RE: Regex = Regex::new(r"(?i)using cached")
static ref FUNDING_RE: Regex = Regex::new(r"(?i)(packages? (are|is) looking for funding|run .+fund)")

There is also no rule anywhere in the chain that keeps error output unconditionally. Errors survive today only because nothing happens to match them.

Why that combination is a problem

When a lifecycle script fails, package managers dump multi-line, mostly unprefixed stderr. Here is real yarn v1 output from a Heroku build:

error /tmp/build_8fb6.../node_modules/node-base64: Command failed.
Exit code: 127
Command: ./install.sh
Arguments:
Directory: /tmp/build_8fb6.../node_modules/node-base64
Output:
./install.sh: 3: ./install.sh: node-waf: not found

Those continuation lines carry no prefix at all. Any one of them that happens to contain "cached", "deprecated" or "fund" is dropped, and the model receives a truncated stack trace underneath a ✓ N packages summary line. It then has to guess at the cause, and it will guess confidently.

The risk is not theoretical for node-gyp failures in particular, which are verbose, free-form, and frequently mention caching.

Suggested fix

A keep-unconditionally rule evaluated before the drop chain, matching anchored error prefixes (error, ERR!, npm error, Error:, bun's error:, berry's YN0001/YN0009), plus their indented continuation lines.

Anchoring the four regexes above would help independently, though it changes existing behaviour and wants its own tests.

Context

Found while adding yarn and bun support in #11. Every rule added there is anchored, so that PR does not add to this, but it does not fix it either.