
Migrate React Spectrum V3 To S2
Guide an agent through Adobe’s ordered React Spectrum v3 (S1) to S2 codemod and provider migration without scope-creeping React major bumps.
Overview
migrate-react-spectrum-v3-to-s2 is an agent skill for the Build phase that upgrades React Spectrum v3 (Spectrum 1) projects to React Spectrum S2 in eight ordered steps.
Install
npx skills add https://github.com/react-spectrum.adobe.com --skill migrate-react-spectrum-v3-to-s2What is this skill?
- Eight ordered migration steps from inspect codebase through final report
- Explicit scope guard: no React major version bumps during migration—note as follow-up only
- Covers @adobe/react-spectrum, @react-spectrum/*, @spectrum-icons/* detection
- Bundler-aware guidance for Parcel, Vite, webpack, Next.js, Rollup, and ESBuild
- Monorepo guidance to migrate the target package/app, not only workspace root
- 8-step ordered migration workflow
- Explicit out-of-scope: React major dependency upgrades during migration
Adoption & trust: 1 installs on skills.sh; trending (+100% hot-view momentum).
What problem does it solve?
Your app still imports @adobe/react-spectrum and @react-spectrum/* packages and you need S2 without agents randomly bumping React or missing bundler-specific fixes.
Who is it for?
Frontend-heavy SaaS or internal tools on React Spectrum v3 preparing for S2 with agent-assisted codemods.
Skip if: Greenfield apps already on S2, or migrations where the primary goal is React 18→19 rather than Spectrum package moves.
When should I use this skill?
Developers mention migrating or upgrading from React Spectrum v3, Spectrum 1, S1, @adobe/react-spectrum, @react-spectrum/*, or codemod-assisted upgrades to @react-spectrum/s2.
What do I get? / Deliverables
You complete inspect-through-report migration with codemod-oriented changes and a final report that flags follow-ups like React major upgrades separately.
- Step-by-step migration changes across manifests and source
- Final migration report with recommended follow-ups (e.g., React major upgrades)
Recommended Skills
Journey fit
Build frontend is the sole phase where package rewrites, providers, and Spectrum design-system imports actually land in code. Frontend subphase matches component library migration work on app entrypoints, bundlers, and @react-spectrum/* usage.
How it compares
Opinionated Adobe migration playbook—not a generic “upgrade all npm deps” skill.
Common Questions / FAQ
Who is migrate-react-spectrum-v3-to-s2 for?
Developers and solo builders maintaining React Spectrum v3 codebases who want step-governed S2 migration assistance in the agent.
When should I use migrate-react-spectrum-v3-to-s2?
During Build frontend work when you mention migrating from React Spectrum v3, Spectrum 1, @adobe/react-spectrum, or codemods to @react-spectrum/s2.
Is migrate-react-spectrum-v3-to-s2 safe to install?
Use the Security Audits panel on this Prism page; migration skills drive broad repo edits—run on a branch with tests and review codemod diffs.
SKILL.md
READMESKILL.md - Migrate React Spectrum V3 To S2
# React Spectrum v3 to S2 migration Upgrade React Spectrum v3 codebases to S2 by following these eight steps in order. ## Scope This skill covers only the React Spectrum v3 (S1) to S2 migration. Do **not** perform major dependency upgrades such as React version bumps (e.g. React 16→17, 17→18, 18→19) as part of this migration. If the project needs a major dependency upgrade, note it as a recommended follow-up in the final report (Step 8) rather than attempting it during migration. ## Step 1: Inspect the codebase - Search package manifests for `@adobe/react-spectrum`, `@react-spectrum/*`, and `@spectrum-icons/*`. - Note the package manager (npm, yarn, pnpm) from the lockfile. - Identify the bundler used by the migration target (Parcel, Vite, webpack, Next.js, Rollup, ESBuild). - In monorepos, inspect the specific package or app being migrated rather than the workspace root. - Find app entrypoints, root providers, shared test wrappers, toast setup, and any `defaultTheme` usage. See [Prerequisites](references/focused-prerequisites.md) for the full inspection checklist and minimum tool versions. ## Step 2: Install @react-spectrum/s2 Install the S2 package with the project's package manager: ```bash npm install @react-spectrum/s2 yarn add @react-spectrum/s2 pnpm add @react-spectrum/s2 ``` If the bundler is not Parcel v2.12.0+, also install and configure `unplugin-parcel-macros` as a dev dependency. See [Getting started](references/docs-getting-started.md) for bundler-specific setup instructions. ## Step 3: Dry-run the codemod Preview what the codemod will change before applying: ```bash npx @react-spectrum/codemods s1-to-s2 --agent --dry yarn dlx @react-spectrum/codemods s1-to-s2 --agent --dry pnpm dlx @react-spectrum/codemods s1-to-s2 --agent --dry ``` Use `npx` for npm/Yarn 1, `yarn dlx` for Yarn Berry/PnP, `pnpm dlx` for pnpm. Add `--path <dir>` for monorepos or partial rollouts. Add `--components A,B` only when explicitly requested for incremental migration. Review the dry-run output to understand the scope of changes. ## Step 4: Run the codemod Execute the codemod to transform the source files: ```bash npx @react-spectrum/codemods s1-to-s2 --agent yarn dlx @react-spectrum/codemods s1-to-s2 --agent pnpm dlx @react-spectrum/codemods s1-to-s2 --agent ``` Use the same `--path` and `--components` flags as the dry run if applicable. ## Step 5: Format with the project's formatter If the project has a formatter (Prettier, ESLint, Biome, Oxfmt, etc.), run it on the changed files to remove extraneous formatting changes introduced by the codemod. ## Step 6: Fix remaining TODO(S2-upgrade) comments Search the codebase for `TODO(S2-upgrade)` comments left by the codemod. Each one marks a change that requires manual review. See [Focused manual fixes](references/focused-manual-fixes.md) for information on how to fix these. Also reference the `react-spectrum-s2` skill (if available) for full S2 component documentation when needed. ## Step 7: Validate Run the project's own toolchain to verify the migration is complete: 1. Install dependencies if package manifests changed. 2. Run the typecheck or compile step (e.g. `tsc --noEmit`, `tsc -b`). 3. Run tests covering the migrated code. Prefer the narrowest test scope that covers the changed files. 4. Run the build to confirm the output is intact. In monorepos, validate the affected package first with its own scrip