gomawt

Appearance

Publishing ​

Internal-facing guide for cutting a release of @gomagaming/* packages. Releases are cut manually by a maintainer with publish access to the @gomagaming npm scope.

When to add a changeset ​

Every PR that changes anything in packages/<pkg>/src/ (or that adds or modifies a widget's public API) needs a changeset. CI enforces this via pnpm changeset status --since=origin/main — PRs without a changeset fail the check.

To add one:

bash
pnpm changeset

Follow the interactive prompts:

  1. Select which packages this PR affects (space to toggle).
  2. Pick the bump level (major / minor / patch) per package.
  3. Write a short summary that goes into the CHANGELOG.

The wizard creates a .changeset/<random-name>.md file. Commit it in your PR.

Lockstep versioning: all eight publishable packages — @gomagaming/core, @gomagaming/sports-domain, @gomagaming/events-horizontal, @gomagaming/sports-navigation-horizontal, @gomagaming/sports-navigation-dialog, @gomagaming/betslip-floating, @gomagaming/betslip-sidebar, and @gomagaming/game-details — bump together. This is configured via "fixed" in .changeset/config.json. Even if your PR only touches one package, the next release bumps all eight.

Cutting a release ​

Releases run from the maintainer's machine.

Prerequisites ​

  • Maintainer must have publish access to the @gomagaming npm scope.

  • An npm Granular Access Token scoped to @gomagaming (read+write) must be in ~/.npmrc:

    //registry.npmjs.org/:_authToken=<your-token>

    Verify with npm whoami --registry=https://registry.npmjs.org/.

  • Local main is up to date and clean.

2FA gotcha: if the npmjs.com account has two-factor authentication enabled, the token will fail to publish with a 403 (OTP required) unless the token is minted with the "Bypass two-factor authentication (2FA)" checkbox enabled. The error message is unambiguous when this is wrong — re-mint the token if you see it.

Steps ​

bash
git checkout main && git pull
pnpm install
pnpm run version-packages

version-packages consumes pending .changeset/*.md files, bumps each package.json version, and updates each CHANGELOG.md. Inspect the diff:

bash
git diff

Verify versions look right. If anything is off, you can edit package.json and CHANGELOG.md files by hand before committing.

Changesets quirk: demo/package.json reformatting. Even though @gomagaming/demo-app is in the "ignore" list of .changeset/config.json, version-packages cosmetically reformats its package.json (whitespace only, no semantic change). Revert it before committing:

bash
git checkout -- demo/package.json

Changesets quirk: stale cross-dep versions in CHANGELOG bodies. If you manually override the computed version in a package.json (for example, when promoting a 0.1.0-rc.0 to 0.1.0), Changesets-generated CHANGELOG bodies still reference the computed cross-dep version (e.g. "Updated dependencies → @gomagaming/core@0.1.0-rc.1") instead of the override. Fix with a targeted sed over the affected CHANGELOG.md files before committing.

bash
git add packages/*/package.json packages/*/CHANGELOG.md .changeset/
git commit -m "[Web] - GOMAWT - Release: <version>"
git push

Then publish:

bash
pnpm run release

release runs build && test && size:check && changeset publish. On success it tags each released version locally — push the tags:

bash
git push --tags

Verification ​

After publishing, verify on npmjs.com:

bash
for pkg in core sports-domain events-horizontal sports-navigation-horizontal sports-navigation-dialog betslip-floating betslip-sidebar game-details; do
  echo -n "@gomagaming/$pkg latest: "
  npm view @gomagaming/$pkg dist-tags.latest
  echo -n "@gomagaming/$pkg access:  "
  npm access get status @gomagaming/$pkg
done

All eight should show the new version, all restricted. If any shows public, run npm access set status=private @gomagaming/<pkg> immediately — the package is currently world-installable.

Cache gotcha: immediately after a fresh publish, npm view may serve cached 404s (or the previous version) for up to a few minutes. If you see stale data, force a fresh lookup:

bash
npm cache clean --force
npm view @gomagaming/<pkg> --prefer-online

Recovery: botched publish ​

If a published version has a defect:

  • Within 72 hours of publish:

    bash
    npm unpublish @gomagaming/<pkg>@<bad-version>

  • After 72 hours, or if the version has dependents:

    bash
    npm deprecate @gomagaming/<pkg>@<bad-version> "broken — use <good-version>"

    If latest was set to the bad version, also reset:

    bash
    npm dist-tag add @gomagaming/<pkg>@<good-version> latest

Then publish a fixed version. Do not reuse the bad version number — even after unpublish, npm reserves the version slot for 24 hours and caches may have stale copies.

Recovery: leaked npm token ​

If a publish token appears in any commit, immediately:

  1. Revoke the token at npmjs.com → Account → Access Tokens.
  2. Mint a fresh token (same scope: granular, @gomagaming/*, read+write, with 2FA bypass enabled if the account has 2FA).
  3. If the leaked token reached a remote, scrub history with git filter-repo or BFG, then force-push the cleaned branch and notify any collaborators to re-clone.
  4. Audit recent publishes: npm view @gomagaming/<pkg> time shows when each version was published; anything during the leak window warrants investigation. If a malicious version was published, deprecate it (per "Recovery: botched publish" above) and publish a clean replacement.
  5. Update the maintainer-only ~/.npmrc with the new token. Do not re-add the leaked one.

Reference ​

  • Installation guide — for consumers.
  • .changeset/config.json — fixed group + ignored packages.