Fetch wasm plugin compat ranges from swc

[kdy1]

Summary

• Fetch Wasm plugin compatibility ranges from swc/main instead of committing a local copy in the plugins app.
• Add a shared importer used by the existing development import page and a new Vercel Cron route.
• Configure a daily Vercel Cron job for /api/cron/import-ranges.

Dependency

Requires the source data file from swc-project/swc#11903 to be merged first.

Validation

• pnpm --filter swc-plugins db:build
• pnpm --filter swc-plugins build:next
• pnpm exec prettier --check apps/plugins/app/import/ranges/page.tsx apps/plugins/app/api/cron/import-ranges/route.ts apps/plugins/lib/import-compat-ranges.ts apps/plugins/vercel.json

Notes

• pnpm --filter swc-plugins exec tsc --noEmit --pretty false still fails on the existing components/logo/index.tsx ./swc.svg module declaration issue.
• pnpm --filter swc-plugins lint still fails on the existing Next lint rule loading issue for @next/next/no-html-link-for-pages.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
plugins	Ready	Preview, Comment	May 28, 2026 4:19am
website	Ready	Preview, Comment	May 28, 2026 4:19am

[claude]

Code Review: Fetch wasm plugin compat ranges from swc

Overview: This PR replaces a static committed data/ranges.json with a live fetch from the upstream swc repo, extracts the import logic into a shared lib, and wires up a daily Vercel Cron job to keep the DB in sync. The approach is sound and the refactor is clean.

---

Bugs / Correctness

Missing error handling in the cron route — if importWasmPluginCompatRanges() throws (upstream fetch failure, schema validation error, DB error), the route returns an unhandled 500 with an HTML error page instead of a structured JSON response. Vercel cron treats any non-2xx as a failure, so it will retry, but observability is poor. Consider wrapping:

export async function GET(req: NextRequest) {
  if (!isAuthorized(req)) { ... }

  try {
    const { ranges } = await importWasmPluginCompatRanges();
    return NextResponse.json({ ok: true, ranges });
  } catch (err) {
    console.error("Failed to import compat ranges:", err);
    return NextResponse.json({ ok: false, error: String(err) }, { status: 500 });
  }
}

No stale-range pruning — importWasmPluginCompatRanges only upserts; it never deletes ranges removed from the upstream source. Over time, obsolete CompatRange rows will accumulate and could affect queries. If upstream ranges can be removed or consolidated, a delete-then-insert (or a deleteMany + createMany inside the transaction) would keep the DB clean.

Import sort order in route.ts — the internal @/lib import appears before the external next/server import, which is reversed from the convention used in app/api/update/runtimes/route.ts. Minor, but inconsistent.

---

Security

isAuthorized non-production bypass is broad — returning true for any non-production environment means staging/preview environments (if they share the same deployment pipeline but have NODE_ENV !== "production") can have their DB mutated by unauthenticated requests. Vercel preview deployments typically have NODE_ENV=production, so this may be a non-issue in practice, but it's worth confirming. Alternatively, consider also checking a CRON_SECRET in preview if that env var is set:

const secret = process.env.CRON_SECRET;
if (!secret) return process.env.NODE_ENV !== "production"; // dev shortcut
return req.headers.get("authorization") === `Bearer ${secret}`;

CRON_SECRET env var is undocumented — no README update or env var table mentions this new required secret for production. This will cause silent authorization failures if deployed without it (!!secret with an undefined value returns false).

---

Reliability / Performance

External dependency with no fallback or timeout — the fetch to raw.githubusercontent.com has no explicit timeout. A hung request will block the route indefinitely (until Node's default socket timeout). Adding a timeout via AbortController or signal: AbortSignal.timeout(10_000) would prevent the cron job from stalling Vercel's function execution budget.

Dependency on upstream PR merging — the PR description notes this depends on swc-project/swc#11903. If deployed before that PR merges, the cron will fail daily until it does. Consider adding a note in vercel.json or the route to handle a 404 gracefully (treat it as "no update available" rather than an error).

Prisma batch transaction with sequential upserts — the db.$transaction([...ranges.map(...), ...RuntimeNames.map(...)]) spreads up to ~30 sequential upsert operations. Prisma's array-form $transaction runs these as individual queries wrapped in a single transaction, not as a single bulk statement. For the runtime upserts (which never change), this runs 4 no-op queries on every import. The runtimes seeding could be separated into a one-time migration or at least skipped if no changes are expected.

---

Code Quality

RuntimeNames is still hard-coded — adding a new supported runtime still requires a code change here. This is a pre-existing design decision, but worth flagging now that this file is the canonical home for it.

No tests — the new shared lib (import-compat-ranges.ts) has no unit or integration tests. At minimum, a test for the Zod schema validation and the isAuthorized logic would prevent regressions.

---

Summary

Issue	Severity
No error handling in cron route	Medium
No stale-range pruning	Medium
CRON_SECRET undocumented	Medium
No fetch timeout	Low
Non-production bypass scope	Low
Import order inconsistency	Nit
No tests	Low

The core refactor is well-structured — extracting to a shared lib and using Zod validation for the external data are both good calls. Addressing the error handling and the missing env var documentation would make this production-ready.