Remove bundlewatch from /catalog devDeps

[drernie]

Sub-task of #4869.

Why

bundlewatch is the sole reason axios and follow-redirects are in the catalog dep tree — both are chronic Dependabot security-PR sources (~4 PRs in the last 10 months between them). Removing bundlewatch eliminates that transitive chain entirely.

Scope

• Remove bundlewatch from catalog/package.json devDependencies.
• Remove the bundlewatch npm script (line ~19 of catalog/package.json).
• Regenerate catalog/package-lock.json under node@20's npm (per repo memory).
• Remove any CI step that invokes bundlewatch (check .github/workflows/).
• Verify axios and follow-redirects are gone from the lockfile.

Replacement?

Open question — does anyone actually look at bundlewatch output? Options:

1. Drop it outright (simplest; if nobody's monitoring, it's dead weight).
2. Replace with bundlesize-action or similar lighter alternative.

Recommend (1) unless someone speaks up.

Acceptance

• npm ls axios in /catalog returns nothing.
• npm ls follow-redirects in /catalog returns nothing.
• CI passes.

[drernie]

Where bundlewatch output goes

• PR status check — BUNDLEWATCH_GITHUB_TOKEN is set in .github/workflows/js-ci.yml:27-29, so bundlewatch posts a commit status on every PR with bundle-size deltas.
• CI logs — text output from npm run bundlewatch.

Config is a single line (catalog/package.json:19) — no .bundlewatch.config.json, no size thresholds defined. So it's running in pure-informational mode (no hard failures).

Implications

If nobody actually looks at the PR check, just delete it. If size monitoring is wanted, size-limit is a common axios-free replacement.

Suggest asking on the eventual PR whether anyone has acted on a bundlewatch check in the past 12 months — if no, drop outright.

[drernie]

Evidence: bundlewatch is running but unread

Checked recent CI runs and PRs:

• It works: PR build(deps): bump follow-redirects from 1.15.9 to 1.16.0 in /catalog #4828 (webpack vuln bump) CI logs show bundlewatch PASS — Everything is in check (+62.79KB, -5.74KB, +1.0%) with a link to service.bundlewatch.io results.
• GitHub status check not appearing: rolled up checks on recent catalog-touching PRs (Catalog: drop unused linkedData / overviewUrl code paths #4856, Catalog: cascade bucketRemove through cached Policy/Role permissions #4855, Catalog: migrate bucket queries to role-scoped Bucket type #4839, feat(catalog): enable logo file upload in theme editor #4781, Qurator: wire in Platform MCP Server tools #4840, Catalog: clarify revision link tooltip (catalog URL, not canonical URI) #4838) show zero bundlewatch status. Token is set but the PR-status posting is broken or disabled.
• No human discussion: searched the last ~50 PRs — zero comments referencing bundlewatch output. The only matches are dependabot bumping bundlewatch itself (Bump axios and bundlewatch in /catalog #4376, chore(deps): update dependency bundlewatch to ^0.4.1 #4388).
• No thresholds: catalog/package.json:19 runs bundlewatch with --normalize only, no config file. Pure informational.

Conclusion: it's silently producing data nobody reads. Recommend dropping outright; if anyone speaks up, size-limit is a clean axios-free replacement.

[fiskus]

I have an impression, that I already proposed to remove bundlewatch, but Alexei rejected.
But I didn't find the evidence.

[nl0]

i always check the bundle size change for every catalog pr, tho now i can't see it on newer prs. ci shows something about "github access token" not found -- has anyone changed the configuration recently?