Found during the e2e test pass for issue #2 / phase 1 / phase 2.
Symptom
plumb lint <real-url> fails immediately with error: Chromium major version <N> is not supported (Plumb pins to 131) whenever the host's Chromium / Chrome major version is anything other than exactly 131.
PINNED_CHROMIUM_MAJOR is defined as 131 (crates/plumb-cdp/src/lib.rs:57) and the gate is an equality check at crates/plumb-cdp/src/lib.rs:501 (if found == PINNED_CHROMIUM_MAJOR).
Chromium 131 is the November 2024 release. On any reasonably current developer machine, this gate refuses to run.
Reproduction
$ ./target/release/plumb lint https://example.com --format json
error: Chromium major version 139 is not supported (Plumb pins to 131)
$ echo $?
2
System binaries available locally:
Chromium 139.0.7216.0 at /Applications/Chromium.app/Contents/MacOS/Chromium
Google Chrome 147.0.7727.102 at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome
--executable-path points at a different binary but does not bypass the version check. There is no env var, feature flag, or CLI flag that skips it.
Why this matters
Phase 1 acceptance criterion (#10):
`plumb lint https://plumb.aramhammoudeh.com --format json` renders a real page via Chromium and emits ≥1 violation from a real rule.
This criterion cannot be satisfied on any host without a fresh Chromium 131 install — and Chromium 131 is no longer the current download from chromium.org or via Homebrew (brew install --cask chromium ships latest).
Rule-engine / config / format work landed in phases 1+2 (8 rules registered, all integration tests green), but the only path to drive a real page is gated behind a binary that's hard to obtain.
Suggested fix
Pick one (or combine):
- Bump the pin to whichever Chromium major the project actively supports (e.g. 139 or whatever CI uses).
- Switch the gate from
== to >= with a documented "tested up to" upper bound — every CDP feature plumb uses is stable across recent majors.
- Add a
--skip-chromium-version-check flag (or PLUMB_SKIP_CHROMIUM_VERSION_CHECK=1 env) so users on the latest Chrome can opt in without modifying source. Print a warning that emitted output is unsupported.
Whichever path you take, also fix the misleading install hint at crates/plumb-cdp/src/lib.rs:419 which currently tells users --executable-path is the workaround — it is not.
Parent
Refs #2.
Found during the e2e test pass for issue #2 / phase 1 / phase 2.
Symptom
plumb lint <real-url>fails immediately witherror: Chromium major version <N> is not supported (Plumb pins to 131)whenever the host's Chromium / Chrome major version is anything other than exactly131.PINNED_CHROMIUM_MAJORis defined as131(crates/plumb-cdp/src/lib.rs:57) and the gate is an equality check at crates/plumb-cdp/src/lib.rs:501 (if found == PINNED_CHROMIUM_MAJOR).Chromium 131 is the November 2024 release. On any reasonably current developer machine, this gate refuses to run.
Reproduction
System binaries available locally:
Chromium 139.0.7216.0at/Applications/Chromium.app/Contents/MacOS/ChromiumGoogle Chrome 147.0.7727.102at/Applications/Google Chrome.app/Contents/MacOS/Google Chrome--executable-pathpoints at a different binary but does not bypass the version check. There is no env var, feature flag, or CLI flag that skips it.Why this matters
Phase 1 acceptance criterion (#10):
This criterion cannot be satisfied on any host without a fresh Chromium 131 install — and Chromium 131 is no longer the current download from chromium.org or via Homebrew (
brew install --cask chromiumships latest).Rule-engine / config / format work landed in phases 1+2 (8 rules registered, all integration tests green), but the only path to drive a real page is gated behind a binary that's hard to obtain.
Suggested fix
Pick one (or combine):
==to>=with a documented "tested up to" upper bound — every CDP feature plumb uses is stable across recent majors.--skip-chromium-version-checkflag (orPLUMB_SKIP_CHROMIUM_VERSION_CHECK=1env) so users on the latest Chrome can opt in without modifying source. Print a warning that emitted output is unsupported.Whichever path you take, also fix the misleading install hint at crates/plumb-cdp/src/lib.rs:419 which currently tells users
--executable-pathis the workaround — it is not.Parent
Refs #2.