The baseline-branch detection step only special-cased
@bigcommerce/catalyst-makeswift; every other package name, including
@bigcommerce/catalyst-b2b-makeswift, fell through to canary. Since
integrations/b2b-makeswift carries substantial B2B-only code on top
of makeswift, comparing its bundle against canary produced a
misleading diff on every b2b-makeswift PR.
Add an elif branch mapping @bigcommerce/catalyst-b2b-makeswift to
integrations/b2b-makeswift, mirroring the existing pattern in
changesets-release.yml's package-resolution step.
Refs LTRAC-1406
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Jira: TRAC-1350
What/Why?
.github/workflows/bundle-size.yml's baseline-branch detection only special-cased@bigcommerce/catalyst-makeswift(→integrations/makeswift); every other package name, including@bigcommerce/catalyst-b2b-makeswift, fell through tocanary. Sinceintegrations/b2b-makeswiftcarries substantial B2B-only code on top of makeswift, comparing its bundle againstcanaryproduced a misleading diff on every b2b-makeswift PR.Adds an
elifbranch mapping@bigcommerce/catalyst-b2b-makeswift→integrations/b2b-makeswift, mirroring the existing pattern already used inchangesets-release.yml's package-resolution step.Discovered during the LTRAC-1297 makeswift-upgrade climb; per team policy, landing this fix on
canaryfirst, then propagating down throughintegrations/makeswift→integrations/b2b-makeswiftvia the normal sync chain rather than patching it directly on the downstream branch.Rollout/Rollback
CI-only change, no runtime impact. Revert is a one-line diff if needed.
Testing
Verified the exact bug by re-reading the workflow logic:
@bigcommerce/catalyst-b2b-makeswiftdoesn't match thecatalyst-makeswiftstring check, so it always fell to theelse(canary) branch. Confirmed the fix's package name againstcore/package.jsononintegrations/b2b-makeswiftand confirmed the matching pattern againstchangesets-release.yml's existing b2belif.