chore: Mark swc_core@v67 as Wasm-breaking

[kdy1]

No description provided.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 779e232

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.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

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

[claude]

PR Review: Mark swc_core@v67 as Wasm-breaking

Mechanical release-chore PR — bumps dependencies and version numbers across all plugin packages. No functional code changes. Overall this looks correct, but I have a few notes.

What this does

• swc_core 67.0.1 → 67.0.3, swc_atoms 9.0.1 → 9.0.2, swc_ecma_transforms_base 43.0.0 → 43.0.1, hstr 3.0.5 → 3.0.6
• swc_icu_messageformat_parser 26.0.0 → 27.0.0 (workspace + consumer in packages/formatjs/transform/Cargo.toml both updated — good)
• All published plugin packages bumped a major (or minor for 0.x packages, which is correct for changeset-style 0.x semver)
• Transform sub-crates (e.g. swc_emotion, styled_jsx, swc_relay, etc.) all bumped in lockstep — good, keeps the plugin/transform pair aligned

Concerns

1. Missing PR description for a load-bearing claim. The whole point of this PR is asserting that the swc_core 67.0.1 → 67.0.3 jump is Wasm-breaking, but the PR body is empty and the changeset entries just repeat the title. Since swc_core itself stayed on the same major (67.0.x), downstream consumers will reasonably ask: what specifically about 67.0.3 breaks plugin Wasm binaries built against 67.0.1? A one-line link to the upstream swc/swc commit/PR that introduced the ABI/memory-layout change would justify the major bump here and help users understand why they need to rebuild plugins.

2. README.md duplication of CHANGELOG content (pre-existing, but worth flagging). Many README.md files (e.g. packages/emotion/README.md, packages/styled-jsx/README.md, packages/relay/README.md, …) have a # @swc/plugin-… heading followed by changelog-style version entries that changeset version keeps appending to. The READMEs aren't truncated when CHANGELOG.md is, so they accumulate forever and drift from the canonical CHANGELOG. This PR isn't introducing the problem — it just inherits and continues it — but it might be worth a separate cleanup PR to strip the changelog tail from each README and let CHANGELOG.md be the single source of truth. As of this PR they're already showing stale entries (e.g. packages/emotion/README.md shows ## 12.11.0 immediately after the new ## 15.0.0 block — the intermediate 13.x/14.x history exists in CHANGELOG.md but not in the README).

3. Version-bump consistency — looks good, double-check intent on two packages:

• contrib/graphql-codegen-client-preset 0.23.0 → 0.24.0 (Minor)
• packages/feature-flags 0.10.0 → 0.11.0 (Minor)
  These are correct for 0.x packages (Minor = breaking under changesets' 0.x convention), but every other plugin in this PR is being bumped as a Major. Worth confirming this was intentional vs. an artifact of how the changeset was generated.

Quality / risk

• Tests: No test changes, none expected for a version bump. CI is currently running (Integration tests, Test - ubuntu/windows) — review should be gated on those going green, especially the integration tests, since this is where a real Wasm ABI break would surface.
• Security: No surface-area changes. The Socket Security checks have already passed.
• Performance: N/A for a version bump, but if the underlying swc_core patch contains perf-relevant changes, calling those out in the description would help.

Suggestion

Add a short PR description: (1) link/SHA for the upstream change that makes 67.0.3 Wasm-incompatible with 67.0.1, (2) brief note for plugin consumers that they must rebuild against the new version. Then this is ready to ship once CI is green.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: d8232907d8

ℹ️ 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".

[claude]

PR Review — chore: Mark swc_core@v67 as Wasm-breaking

Pure version/metadata change — no source-code modifications. Cargo.lock and version bumps line up cleanly with the workspace dependency edits, and the changeset/CHANGELOG/README updates flow through consistently from a single changeset (809c25d). Nothing alarming from a correctness, performance, or security perspective.

A few small notes:

1. PR body is empty

Even a one-liner would help downstream consumers and future archaeology. Something like:

v67 of swc_core is ABI-breaking for Wasm plugins (despite the patch-level bump in PR #620). Re-publishing all plugin packages as a major release so dependents do not silently inherit an incompatible runtime.

This matters because PR #620 already shipped 67.0.0/67.0.1 with a non-major changeset, and this PR is the retroactive correction. Without context, it looks like a duplicate release.

2. Changeset wording reads ungrammatically

The changeset message is chore: Mark v67 as a Wasm-breaking. The indefinite article without a noun (as a Wasm-breaking) is a bit awkward — this string is now embedded in 18 CHANGELOG.md files and their README mirrors, so it's worth getting right. Suggestions:

• chore: Mark v67 as Wasm-breaking (drop the article), or
• chore: Mark v67 as a Wasm-breaking change (add the noun)

Not blocking, but since the same line is duplicated everywhere it'll be visible.

3. Pre-1.0 packages handled correctly

Spot-checked the two 0.x packages, both of which used Minor bumps rather than Major:

• @swc/plugin-experimental-feature-flags: 0.10.0 → 0.11.0 ✓
• @swc-contrib/plugin-graphql-codegen-client-preset: 0.23.0 → 0.24.0 ✓

This matches the changesets convention for pre-1.0 packages (breaking → minor). Good.

4. Version-train divergences are preserved

mut-cjs-exports continues to track separate version lines for the Rust crate (18 → 19) and the npm package (14.11.0 → 15.0.0). That's the existing convention, so consistent.

5. Cargo.lock transitive bumps look incidental

hstr 3.0.5 → 3.0.6, swc_atoms 9.0.1 → 9.0.2, swc_ecma_transforms_base 43.0.0 → 43.0.1 — all patch bumps pulled in by the swc_core update. No concerns.

Test coverage

N/A — no code paths touched. Existing CI on the release branch is the right gate; nothing to add here.

Summary

LGTM apart from the empty PR description and the slightly awkward changeset wording (which now lives in every CHANGELOG). Both are easy fixes; neither is blocking.