feat: add rename-after-install-and-build input to publish-preview.yml workflow

[mikesposito]

The reusable publish-preview workflow renames each workspace's package.json#name from @metamask/... to @metamask-previews/... before running the build. This works for typical libraries but breaks for Snap packages, because:

• The Snap build (mm-snap build) embeds the package name into dist/bundle.js.
• snap.manifest.json contains a source.shasum computed over the bundle, the manifest itself (minus the shasum), the icon, and locales.
• source.location.npm.packageName in the manifest must match package.json#name at publish time.
  When the rename happens before the build, the bundle and manifest are produced against the preview scope, the shasum is computed over the contaminated bundle, and downstream clients that verify against the published @metamask/... shasum reject the snap.
  The workaround used by snap repos today (e.g. snap-tron-wallet) is to build first, then rename — but the reusable workflow had no way to express that ordering.

To fix this issue and make this workflow usable for Snaps, this PR adds a new boolean input is-snap (default false) to .github/workflows/publish-preview.yml.

Existing consumers don't need to change anything. Snap consumers add a single input:

jobs:
  publish-preview:
    uses: MetaMask/github-tools/.github/workflows/publish-preview.yml
    with:
      is-snap: true
    secrets:
      PUBLISH_PREVIEW_NPM_TOKEN: ${{ secrets.PUBLISH_PREVIEW_NPM_TOKEN }}

---

Note

Medium Risk
Changes CI ordering for preview builds and introduces secret env injection into build steps; default path is unchanged but misconfigured BUILD_ENV or rename ordering could break consumer preview builds.

Overview
Extends the reusable publish-preview workflow so consumers can control when package names are rewritten to the preview NPM scope, and can inject build-time environment from secrets.

Adds rename-after-install-and-build (default false). When true, the job runs install → build → manifest rename → install so artifacts like Snap bundles and snap.manifest.json are built under the original @metamask/... name before preview renaming. When false, behavior stays rename → install → build.

Adds optional secret BUILD_ENV (JSON key/value map) applied to the build step via fromJSON, with a step that masks those values in logs. The prepare step is renamed to Prepare preview manifests; install/build are split into conditional pre-rename and post-rename steps.

^{Reviewed by Cursor Bugbot for commit 9994d8b. Bugbot is set up for automated code reviews on this repo. Configure here.}

[gabrieledm]

LGTM

[mikesposito]

This workflow variation has been tested on this repository:

• https://github.com/MetaMask/snap-stellar-wallet/blob/main/.github/workflows/publish-preview.yml
• test: preview builds snap-stellar-wallet#38

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit b97ae02. Configure here.}

[Mrtenz]

We need to rethink this, as this conflicts with NPM trusted publishing. 😞 We can't configure multiple sources for a single package, so if the preview packages use the same NPM package name, we'd need to allow npm publish (in addition to npm stage publish) for the production workflow as well.

Is there really no way to publish these Snaps with a different package name?

I misunderstood what this change does.