Skip to content

fix(pre-commit): enforce BunnyCDN registry URLs in yarn.lock#34818

Draft
hmoreras wants to merge 1 commit intomainfrom
issue-34619-enforce-yarn-lock-registry-precommit-check
Draft

fix(pre-commit): enforce BunnyCDN registry URLs in yarn.lock#34818
hmoreras wants to merge 1 commit intomainfrom
issue-34619-enforce-yarn-lock-registry-precommit-check

Conversation

@hmoreras
Copy link
Contributor

@hmoreras hmoreras commented Mar 2, 2026

Summary

Adds a check_yarn_lock_registry() function to the pre-commit hook (core-web/.husky/pre-commit) that blocks commits where yarn.lock contains wrong registry URLs (registry.yarnpkg.com or registry.npmjs.org) instead of the project's BunnyCDN cache (dotcms-npm.b-cdn.net).

Background

This is a recurrence of the issue fixed in #34676. When the Lara Theme / Angular 21 upgrade (#34531) was merged, the developer who regenerated yarn.lock had a global registry override set locally. Yarn 1.x does not reliably honour the project-level .yarnrc when a global config is present — npm config set registry silently takes higher priority, causing the lockfile to be regenerated with the wrong registry URLs and breaking CI/CD reliability.

Root cause

  • core-web/.yarnrc correctly points to https://dotcms-npm.b-cdn.net
  • A developer's local yarn config set registry or npm config set registry silently overrides this
  • yarn install regenerates yarn.lock with upstream registry URLs (3,455+ affected entries)
  • CI/CD follows the lockfile exactly, bypassing the BunnyCDN cache and hitting the upstream registry, which is prone to rate limiting and availability issues

What this PR does

  • Adds check_yarn_lock_registry() to .husky/pre-commit
  • Called immediately after yarn install stages yarn.lock
  • Scans the lockfile for registry.yarnpkg.com or registry.npmjs.org entries
  • Blocks the commit if wrong URLs are found, with clear instructions to fix:
    yarn config delete registry
    npm config delete registry
    cd core-web && yarn install
    
  • Zero cost on normal commits — only activates when yarn.lock is actually staged

What this PR does NOT do

  • This does not fix the currently broken yarn.lock on main — that requires a separate PR where someone with no global registry override regenerates it correctly
  • This does not replace the CI-level check Steve mentioned — that should be added as a second line of defence

Test plan

  • Temporarily set a wrong registry: yarn config set registry https://registry.npmjs.org
  • Modify a package and run yarn install in core-web/
  • Stage core-web/yarn.lock and attempt to commit — hook should block with a clear error message
  • Remove the override: yarn config delete registry
  • Re-run yarn install, re-stage, re-commit — hook should pass

Related

🤖 Generated with Claude Code

Adds a check_yarn_lock_registry() function to the pre-commit hook that
blocks commits where yarn.lock contains entries pointing to
registry.yarnpkg.com or registry.npmjs.org instead of the project's
BunnyCDN cache (dotcms-npm.b-cdn.net).

This prevents developers with a global registry override (set via
`yarn config set registry` or `npm config set registry`) from silently
poisoning the lockfile. Yarn 1.x does not reliably honour the
project-level .yarnrc when a global config is present, so the hook
acts as the enforcement layer.

The check fires only when yarn.lock is staged, keeping it a zero-cost
no-op for every other commit. On failure, it prints the exact commands
the developer needs to diagnose and fix the issue.

Closes #34619

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Area : Frontend PR changes Angular/TypeScript frontend code

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

Registry configuration mismatch: yarn.lock uses public registry despite CDN config

1 participant