[TheGeekyM]

Summary

This PR adds a new docs page, docusaurus/docs/migrating-from-create-react-app.md. It links to the official migration guides listed in the React team's Sunsetting Create React App post and has a short table of the Create React App conventions that people usually need to replace when they switch tools. The page is in the "Getting Started" sidebar, and the Getting Started page now links to it. This is a docs-only change.

Motivation

Create React App is now officially deprecated (#17003, #17008). The site tells people to move off it, but it doesn't help them do that. Someone with an existing app who opens the docs today finds no list of migration guides, and nothing tells them which parts of their app depend on behavior that react-scripts provides without any config file.

That second gap is where migrations tend to break. Several features only work because of conventions handled in packages/react-scripts:

• config/env.js (lines 67–87) only puts variables that match /^REACT_APP_/i into the bundle, plus NODE_ENV and PUBLIC_URL.
• config/paths.js (lines 20–29) works out the public path from process.env.PUBLIC_URL or the homepage field in package.json. It also resolves src/setupProxy.js (line 75), which config/webpackDevServer.config.js (lines 118–120) loads automatically.
• config/webpack.config.js replaces %PUBLIC_URL% in public/index.html using InterpolateHtmlPlugin (lines 640–644). It also sets up @svgr/webpack (line 392), which is what makes import { ReactComponent } from './logo.svg' work. Its build target comes from browserslist (line 200).
• scripts/start.js (line 111) reads the proxy field from package.json.
• config/modules.js turns baseUrl in jsconfig.json / tsconfig.json into module paths and aliases so absolute imports from src work.

If an app uses any of these, it can build without errors on a new tool and still behave differently at runtime. Examples: env variables come through as undefined, asset URLs break, the dev proxy is missing, or SVG imports fail. Listing these conventions in one place gives people a checklist before they start.

What changed

• docusaurus/docs/migrating-from-create-react-app.md (new)
  • Opens with a short deprecation note that links to the react.dev announcement.
  • Lists migration guides, grouped the same way as the announcement:
    • Frameworks: Next.js, React Router, Expo (webpack)
    • Build tools: Vite, Parcel, Rsbuild
  • Has a table of CRA conventions: REACT_APP_*, PUBLIC_URL / homepage, %PUBLIC_URL%, the proxy field, src/setupProxy.js, baseUrl, SVG ReactComponent imports and browserslist. Each row says briefly what CRA does, names the config/*.js file responsible where that helps, and links to the existing CRA docs page for that feature.
• docusaurus/website/sidebars.json: adds migrating-from-create-react-app as the last item under "Getting Started", after "Updating to New Releases", so it sits next to the other upgrade-related page.
• docusaurus/docs/getting-started.md: adds a one-line deprecation note above "Quick Start" that links to the new page. That's the first page most visitors see.

How it works

The page sends readers to the guides maintained by each target tool rather than writing new migration steps. Those projects know their own tooling best and will keep their guides up to date. This repo is deprecated and unlikely to keep step-by-step instructions for six different tools current. I used the same set of guides as the react.dev announcement so the two sources agree.

The conventions table is the only original content. It describes what CRA does, not how to do it in each tool. I wrote it that way on purpose: every row is something this repo can state with authority, and readers look up the equivalent in their target tool's docs. Each row links to the existing CRA docs page (with anchors, e.g. deployment.md#building-for-relative-paths, importing-a-component.md#absolute-imports, adding-images-fonts-and-files.md#adding-svgs, proxying-api-requests-in-development.md#configuring-the-proxy-manually), so readers can see exactly what behavior they need to reproduce. All the anchors exist in the current docs.

Alternatives I considered:

• A react-scripts migrate command that rewrites a CRA app for Vite or Rsbuild. This was the original, larger idea. It would mean shipping and maintaining a codemod in a deprecated package, tracking changes in other tools' config formats, and handling many edge cases (ejected apps, custom webpack overrides, CRACO/rewired setups). It might be worth doing later, but it isn't needed to close the docs gap, so it's out of scope here.
• Writing a full per-tool translation table (e.g. "REACT_APP_FOO → import.meta.env.VITE_FOO"). That would duplicate the target tools' docs, go stale quickly and add a lot of review work. Linking to their guides avoids all of that.
• Putting the content in the README or only in getting-started.md. A separate page keeps Getting Started focused on what it already covers. It also gives the migration content a stable URL that can be linked from elsewhere, such as the deprecation message added on init.

Tests

No test files were added. This change is docs only and doesn't touch any code under packages/.

To check it locally:

cd docusaurus/website
npm install
npm start

Then check that:

• "Migrating from Create React App" is the last item under "Getting Started" in the sidebar.
• The new note on the Getting Started page links to the new page.
• Every internal link and anchor in the conventions table goes to the right section.
• The external migration guide links open the expected pages.

Running npm run build in the same directory will also report broken internal doc links.

Compatibility & risk

• No code, config or published package changes, so nothing changes at runtime and there's no performance impact for users of react-scripts.
• The only structural change is the new sidebar entry. It uses an existing category and doesn't reorder or rename any existing pages, so existing URLs stay the same.
• The main risk is link rot in the external guide URLs, since other projects maintain them. They match the react.dev announcement as of this PR. Please check that they still resolve.
• One wording point to check: the proxy row doesn't name a file because the field is read in scripts/start.js, not in config/. I left the file out to keep the table focused on the user-facing setting.

Checklist

• I have verified the docs site builds locally and all links resolve
• I have attached screenshots of the new page and sidebar entry