ci: add misc npm publish workflow

[kdy1]

Summary

• Add a new workflow named Publish misc packages.
• Support manual publishing of @swc/types and @swc/helpers via workflow_dispatch.
• Add a branch guard so the workflow only runs from main.

Details

• Add an npmTag input with latest and nightly options.
• Use a matrix strategy to publish both packages in parallel.
• Keep trusted publish settings with id-token: write, environment: publish, and an npm upgrade step.
• Publish with yarn npm publish --access public --tag ... --tolerate-republish.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 177a412

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[socket-security]

No dependency changes detected. Learn more about Socket for GitHub.

👍 No dependency changes detected in pull request

[Copilot]

Pull request overview

Adds a manually-triggered GitHub Actions workflow to publish “misc” npm packages from this repo (currently @swc/types and @swc/helpers) with a selectable dist-tag.

Changes:

• Introduces .github/workflows/publish-misc-packages.yml workflow triggered via workflow_dispatch.
• Publishes @swc/types and @swc/helpers via a matrix job with npmTag input (latest/nightly).
• Uses the existing Node setup composite action and trusted-publish permissions (id-token: write) plus an npm update step.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The main-branch guard is implemented as a runtime step, which still triggers the environment: publish protection flow and starts runners before failing. Other publish workflows in this repo use a job-level branch guard (e.g. .github/workflows/publish-npm-package.yml:55-56 uses if: github.ref == 'refs/heads/main') to prevent the job from starting at all. Consider moving this check to jobs.publish.if: github.ref == 'refs/heads/main' (and removing the step) so non-main dispatches are rejected earlier and don’t require environment approval.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 94c8e84d11

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[codspeed-hq]

Merging this PR will not alter performance

✅ 219 untouched benchmarks

---

_{Comparing kdy1/publish-misc-packages-workflow (177a412) with main (71feafb)¹}

Footnotes

1. No successful run was found on main (169c961) during the generation of this report, so 71feafb was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[claude]

PR Review: ci: add misc npm publish workflow

Overall this is a clean, well-structured workflow. A few observations:

Looks Good

• Branch guard — The explicit check against refs/heads/main is a good safety measure for a workflow_dispatch trigger.
• Trusted publishing — id-token: write + environment: publish is consistent with the existing publish-npm-package.yml workflow. No secrets or tokens are leaked.
• Matrix strategy with fail-fast: false — Good choice, so one package failing doesn't block the other.
• --tolerate-republish — Prevents failures on re-runs for already-published versions.
• SKIP_YARN_COREPACK_CHECK — Matches the pattern used in publish-npm-package.yml.
• Concurrency group — Prevents duplicate runs.

Suggestions / Questions

1. @swc/helpers has a prepack script (zx ./scripts/build.js) — yarn npm publish triggers prepack automatically, so this should work. However, @swc/types uses prepublishOnly which yarn npm publish also triggers. Worth verifying that both build scripts succeed on a bare ubuntu-latest runner with just Node.js (no Rust toolchain, etc.). If @swc/helpers build depends on anything beyond Node.js, the workflow would fail silently on the build step embedded in publish.

2. No version bump step — This workflow publishes whatever version is in package.json on main. This is presumably intentional (versions are bumped in separate commits/PRs), but it means accidentally re-triggering the workflow after a publish will be a no-op only because of --tolerate-republish. Consider adding a check that logs whether the version already exists on npm, to make re-runs more obvious.

3. npm install -g npm@latest — The comment in the existing publish workflow says this is for trusted publish support (npm 11.5.1+). Consider pinning to a minimum version (e.g., npm@11) instead of @latest to avoid surprises from future breaking changes in npm.

4. Permissions are minimal (contents: read) — Good. The existing publish-npm-package.yml uses contents: write because it uploads CLI binaries to GH releases; this workflow correctly only needs read.

5. Minor: GITHUB_TOKEN env on publish step — For OIDC-based trusted publishing, the token used is the OIDC token (via id-token: write), not GITHUB_TOKEN. The GITHUB_TOKEN env var is passed but may not actually be needed for the npm publish step itself. Not harmful, just potentially unnecessary.

Security

• No secrets beyond GITHUB_TOKEN are used. OIDC trusted publishing is the correct modern approach.
• The branch guard prevents publishing from feature branches.
• The environment: publish gate adds an additional layer of protection (environment protection rules).

Test Coverage

• This is a CI-only change with no code changes, so no test coverage is needed. The workflow can be validated by a dry-run dispatch from main.

LGTM — the workflow is simple, follows existing patterns, and has appropriate safeguards. The suggestions above are minor improvements, not blockers.

[github-actions]

Binary Sizes

File	Size
swc.linux-x64-gnu.node	28M (29066056 bytes)

Commit: a428993