build: Update swc_core to v67.0.1

[kdy1]

No description provided.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 153bbcc

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]

Review — swc_core v66 → v67 bump

Thanks for keeping the plugins in sync with swc_core. The version bumps look consistent across all 82 files (npm packages get a minor, Rust crates get a major), and the changeset-driven CHANGELOG.md / version updates all line up.

🔴 Blocking — compile failures in swc_ast_unknown check

The Check (swc_ast_unknown) job is failing because swc_common v22 turned SourceFile::src_hash from a public field into a method (job log). The same call pattern is used in several places that weren't updated:

• packages/emotion/src/lib.rs:74 — pos.file.src_hash as u32
• packages/emotion/transform/tests/fixture.rs:58, 136, 205 — fm.src_hash as u32
• packages/styled-components/src/lib.rs:26 — pos.file.src_hash
• packages/styled-components/transform/tests/fixture.rs:31 — fm.src_hash
• packages/prefresh/src/lib.rs:20 — pos.file.src_hash (not reported by the failing job — likely a different feature gate — but will fail with the same error once it compiles)

Fix is mechanical: add () to make it a method call (pos.file.src_hash() / fm.src_hash()). The compiler suggestion in the log is correct.

Nits

• Empty PR description. A swc_core major bump is something downstream consumers need to react to (plugin .wasm ABI from v66 hosts won't load on v67 hosts). A one-line link to the swc_core v67 release notes — especially the SourceFile::src_hash change that bit this PR — would make it easier for plugin authors who track this repo.
• react-remove-properties Cargo crate version is 0.19.4 while the package gets 7.0.0 — preexisting mismatch, not introduced here, but worth a sanity check the next time this package is touched.

What looks good

• The minor-bump-for-npm / major-bump-for-Rust pattern is applied uniformly.
• All workspace-pinned swc_* versions in Cargo.toml were bumped together — no stragglers.
• Cargo.lock matches the manifest changes (no orphaned or accidentally-pinned versions).
• No behavioral code changes — the diff is purely the version bump and generated changelog/README updates.

Once src_hash is converted to a method call across the six sites above, this should be ready to land pending the remaining CI runs.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 0d361fe252

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

[chatgpt-codex-connector]

Regenerate the lockfile for this version bump

This manifest now declares modularize_imports as 7.0.0, but the committed lockfile still records the local package as 6.0.0 at Cargo.lock:1637 (the same one-version lag appears for the other local transform crates bumped in this patch). In any CI or release job that builds with a locked/frozen lockfile, Cargo will stop because Cargo.lock needs to be updated before it can resolve the new path-dependency versions.

Useful? React with 👍 / 👎.

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	npm/​@​swc/​core@​1.15.40
	cargo/​testing@​22.0.0 ⏵ 23.0.0

View full report

[claude]

Review of #620 — build: Update swc_core to v67.0.1

Thanks for the upgrade. Most of this PR is mechanical version bumps; below are the observations after looking at the substantive changes.

Summary of actual code-level changes

Beyond the Cargo/package version bumps and CHANGELOG entries, only two functional things change:

1. SourceFile::src_hash field → src_hash() method. Adapted in 5 places:

   • packages/emotion/src/lib.rs:74
   • packages/emotion/transform/tests/fixture.rs (×3)
   • packages/prefresh/src/lib.rs:1112
   • packages/styled-components/src/lib.rs:26
   • packages/styled-components/transform/tests/fixture.rs:31

   The translation is direct and correct.

2. packages/styled-components/__tests__/__snapshots__/wasm.test.ts.snap — output ordering changed: the injected import _styled from \"styled-components\" now appears before the file's leading comment/pragma block instead of after.

Worth flagging: // @flow pragma placement

In the updated snapshot for transpile-css-prop-add-import and transpile-css-prop-add-require:

-"// @flow
-import _styled from \"styled-components\";
+"import _styled from \"styled-components\";
+// @flow

Flow requires // @flow to be at the top of the file (typically the first non-comment line) for it to take effect. Pushing it below an injected import effectively disables Flow type-checking for that file. The Rust unit-test fixture (packages/styled-components/transform/tests/fixture.rs against …/fixtures/transpile-css-prop-add-import/output.js) already had this ordering, so the wasm snapshot is converging to existing behavior — it's not a new regression introduced by this PR, just newly visible here. Still, it would be worth a follow-up to confirm with upstream styled_components whether the pragma-preservation behavior is intentional.

The other snapshot change (the /* Basic fixtures */ block moving below the inserted import in the transpile-css-prop case) has the same root cause but lower semantic impact since it's a non-pragma comment.

Other observations

• @swc/core dev-dep bump (^1.15.0 → ^1.15.40). Minor floor bump, same caret range; fine. The pnpm-lock churn is the platform-specific artifact set for the new patch.
• Major version bumps across all plugin crates (6.0.0 → 7.0.0) and Node packages (e.g. 12.10.0 → 12.11.0) are consistent with the project's release process and the upstream major version of swc_core. No semver issues spotted.
• No new tests. Appropriate for a pure dependency bump — the existing wasm/fixture suite exercises the swapped API surface.
• Cargo.toml / pnpm-lock / Cargo.lock churn is internally consistent: all swc_* workspace deps moved forward by one major and the lockfile checksums line up.

Suggestions

• Consider opening a tracking issue (or adding a note) about the // @flow pragma ordering so future readers know the current behavior is by design, not by accident.
• The PR body is empty — even one-line context ("matches changes in swc_core v67 release notes: SourceFile::src_hash is now accessor-gated") would help future bisects.

Verdict

LGTM as a mechanical upgrade. The src_hash change is correctly propagated, version bumps are consistent across crates and packages, and CI on ubuntu-latest already passes. The Flow-pragma snapshot drift is the only thing I'd want a second look on — but it appears to be a pre-existing behavior of upstream styled_components rather than something introduced here.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 153bbcc844

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

[chatgpt-codex-connector]

Preserve the Flow pragma before injected imports

For inputs that start with // @flow, accepting this output puts the newly injected _styled import before the pragma, so Flow no longer sees the file as Flow-typed because the pragma must appear before executable code. The fixture immediately below is the transpile-css-prop-add-import case whose source starts with // @flow, so users of the wasm plugin on Flow files with css props will silently lose Flow checking after this transform; the injected import should be placed after leading pragmas/comments as the previous snapshot did.

Useful? React with 👍 / 👎.