Guard against browser-API regressions and slow fix propagation

[djscruggs]

Summary

Following #51 / #52 (navigator.credentials is non-configurable on WebKit, so the Object.defineProperty() call added in 3.2.1 threw and loadOnce() rejected on all iOS browsers and desktop Safari), two gaps remain that let the regression both ship and linger in dependents:

1. No browser test exercised load(). CI runs lint only — there was no automated assertion that load() succeeds in any browser, so the WebKit breakage shipped undetected from 3.2.1 onward.

2. No signal pushed the fix downstream. Consumers pin ^4.0.x and would resolve the patched version on a fresh install, but lockfiles stayed pinned to the broken version and nothing prompted a bump + redeploy.

This issue proposes monitoring/guardrails across three layers. It is a proposal for discussion — the open questions at the bottom should be resolved before implementation.

Layer 1 — Browser-API regression detection

1a. Cross-browser smoke test in CI (highest leverage).

• Add Playwright with chromium, firefox, and webkit projects.

• A test page loads the built bundle, calls loadOnce(), and asserts: it resolves without throwing; window.WebCredential is defined; and navigator.credentials.get / .store are functions (patched).

• The webkit project reproduces loadOnce() throws on iOS (WebKit) since 3.2.1: cannot redefine navigator.credentials #51 directly (red before Do not throw when navigator.credentials cannot be redefined #52, green after).

• Add a test script and a test CI job as a sibling of lint (no needs:, runs in parallel). This makes the regression class fail pre-publish.

1b. External browser-release feed (optional second layer).

• Watch WebKit/Chromium release notes and web-platform-tests deltas for Credential Management API / navigator.credentials changes, to flag upcoming behavior changes before they reach stable. Noisier; does not prove our code breaks (1a does).

Layer 2 — Downstream propagation

2a. Dependabot.

• Add .github/dependabot.yml (npm) so a new release auto-opens a lockfile-bump PR in this repo and in dependents.

2b. Staleness check.

• A small script reporting, per consumer: pinned range, resolved (lockfile) version, and latest published — flagging anyone behind. Runnable on demand or on a schedule.

Layer 3 — External consumers

• Publish release notes / advisory for the fix.

• Consider npm deprecate on the affected version range with a message pointing at the WebKit breakage, so installers see a warning.

Open questions

1. WebKit in CI: Playwright's bundled WebKit (Linux, fast) vs. real Safari on a macOS runner (accurate, costlier)? Bundled WebKit already exhibits the non-configurable navigator.credentials behavior.

2. Layer 1b: build now, or defer until 1a is proven?

3. Dependabot rollout: this repo only, or this repo plus direct consumers?

4. Ownership of any scheduled check (1b / 2b): scheduled GitHub Action vs. run-on-demand?

5. npm deprecate: acceptable to deprecate the affected range, given some pinned consumers would then warn on install?

[davidlehn]

Beyond testing browsers, there are extensions (dashlane, 1password, etc) that have previously been manipulating navigator.credentials and causing issues. Might want to track ones with such issues, and add them into the test browsers too.

[dlongley]

+1 to this plan, answers to questions:

1. We can start with bundled webkit on linux and do more if necessary later.
2. Prove 1a first.
3. Any dependabot stuff should be just this repo for now.
4. Deferred because of other answers (IIUC).
5. IMO, yes, we should do npm deprecate.

Happy to hear other opinions.