What this prompt does
This prompt casts the model as a senior frontend build engineer and asks it to produce a concrete, follow-blind migration plan from Create React App or Webpack to Vite. Instead of a vague "switch your bundler" overview, it forces actual file diffs: dependency changes, a vite.config.ts, the index.html move, the entry point rewrite, and env var renames. The framing — "return actual file diffs, not vague steps" — is what keeps the output executable rather than aspirational.
The variables shape how specific the plan gets. [source_setup] tells the model whether you are on CRA 5 or a hand-rolled Webpack config, which changes the exact files it touches. [test_runner] drives section 4 — the Jest-to-Vitest config and mock migration looks very different from a Mocha setup. [ci] tailors the install, build, and cache steps to your pipeline so the CI section is copy-ready rather than generic.
When to use it
- You are moving a CRA or Webpack app to Vite mainly for dev-server speed and HMR
- You want the long-tail gotchas (
process.env,require, dynamic imports) surfaced before they break CI - You need a Jest-to-Vitest test migration mapped out, not just the build swap
- Your CI pipeline needs explicit install/build/cache adjustments for the new toolchain
- You want a rollback path ready before you merge, not improvised after a red build
- You are handing the migration to someone who needs each step as a literal diff
Example output
The model returns an ordered checklist where each step carries the actual file diff to apply — a prerequisites block (Node version, lockfile, CRA/Webpack feature inventory), then dependency and config diffs, an index.html move, entry-point changes, CI edits for your system, a test-runner migration section, a gotchas list, and a final rollback plan. It reads like a PR description you can execute top to bottom.
Pro tips
- Fill
[source_setup]precisely ("Create React App 5 with CRACO overrides") — overrides and ejected configs change which steps apply - If your
[test_runner]is Jest, expect a Vitest config plus mock rewrites; flag any custom transformers so they are not silently dropped - Set
[ci]to your real system so the cache keys and build commands match; a generic answer often caches the wrong directory - Push the model hard on the gotchas section —
process.envaccess, CommonJSrequire, and dynamic imports are where CRA hid complexity that Vite exposes - Keep the rollback branch alive until the new build is green in CI for a full cycle; dynamic imports can resolve differently and only show up under load
- Iterate by pasting back any CI error and asking it to amend the specific diff rather than regenerating the whole plan
