feat: scaffold parallel SWC v2 npm API#12015
Conversation
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6cc187a009
ℹ️ 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".
| set -euo pipefail | ||
| case "$PACKAGE" in | ||
| core | html | minifier | react-compiler) ;; | ||
| core | core-v2 | html | minifier | react-compiler) ;; |
There was a problem hiding this comment.
Add a root test script for core-v2
When publish-npm-v2-preview.yml invokes this reusable workflow with package: core-v2, the Linux binding test jobs pass this allow-list and later run pnpm "test:${PACKAGE}" from the repository root inside Docker. At this commit the root package.json only defines test:core, not test:core-v2, so both Linux binding test jobs fail with a missing script and publish-core never reaches the publish step. Add a root test:core-v2 script or special-case these jobs to run the package-local test command.
Useful? React with 👍 / 👎.
| #[cfg(all(not(feature = "api_v1"), not(feature = "api_v2")))] | ||
| compile_error!("Please enable api_v1 or api_v2 feature"); |
There was a problem hiding this comment.
Preserve no-default v1 binding builds
This new requirement breaks the existing publish matrix entries in .github/workflows/publish-npm-package.yml that build @swc/core with --no-default-features --features swc_v1 or swc_v1,plugin for several targets; those commands do not enable api_v1, so the build script now emits this compile_error! before any v1 artifact is built. Either make the swc_v1 feature imply api_v1 or update every no-default-features core build to pass api_v1.
Useful? React with 👍 / 👎.
| import type { Options } from "@swc/types"; | ||
|
|
||
| /** Public configuration accepted by the v2 JavaScript API. */ | ||
| export type V2Options = Options; |
There was a problem hiding this comment.
Don't advertise ignored JS plugins
Because v2 options are still exactly @swc/types Options, the published type surface includes plugin?: Plugin, but the v2 transform methods never apply that callback before serializing options to the native binding. For callers using the documented JS plugin form (transformSync(src, { plugin })), JSON serialization drops the function and the transform runs without the plugin or a warning; either keep the v1 plugin handling here or remove it from V2Options.
Useful? React with 👍 / 👎.
| } | ||
|
|
||
| async parse(src: string, options?: ParseOptions): Promise<Program> { | ||
| const normalized = options ?? { syntax: "ecmascript" }; |
There was a problem hiding this comment.
Default syntax when parse options are partial
If a JavaScript caller supplies parse options without a syntax tag, such as { comments: true }, this path forwards that object unchanged to native deserialization. The Rust ParseOptions expects the flattened syntax tag unless the JS facade fills it in; v1 does options.syntax = options.syntax || "ecmascript", so these calls regress from parsing as ECMAScript to throwing. Apply the default whenever an options object is provided, and mirror it in the sync/file parse paths.
Useful? React with 👍 / 👎.
Merging this PR will not alter performance
Comparing Footnotes
|
Description:
Establishes the repository and release structure needed to develop the SWC v1 and v2 npm APIs together on
mainwithout duplicating the Rust engine.swc_api_commoncrate for version-neutral compiler operations and direct version-selected AST wire encoding.core-v2andtypes-v2workspace sources. Removed v2 APIs such asbundle()andprint()are not exported from the v2 facade.@swc/core, platform packages,@swc/types, and@swc/wasmat a synchronized 2.x prerelease version.latestand v2 previews onnext.This PR provides isolated v2 config and AST codec boundaries so milestone-specific API cleanup can be landed incrementally while v1 development continues against the same engine.
Existing v1 npm and Rust public APIs remain unchanged.
Validation:
cargo fmt --allcargo clippy --all --all-targets -- -D warningscargo test -p swc_api_commonpackages/corebuild and test suiteRelated issue (if exists):