Migration
Moving between majors. The page was created ahead of its content on purpose: the 0.x line has had no majors yet.
Machine-translated, not yet reviewed. Read the original
There is nothing to migrate from yet. The core lives in the 0.x line, there
have been no major transitions, and this page exists ahead of its content on
purpose: a plan of sections written in advance costs an evening, one written on
release day costs a week and the nerves of everyone who is moving.
What to do today if a version was updated and something came off: look at the changelog — before 1.0 the breaking changes live there, with a description and a date.
What will appear here by 1.0
- A map of API changes — what was renamed, what was removed, what changed its default. As a table rather than as prose: prose cannot be searched by a prop name.
- A codemod. Renames are performed by a script rather than by hand: it lives in the repository next to the migration and runs with one command.
- What breaks silently. A separate section for changes that give neither a build error nor a warning — a shifted default, a different resolution order, another ARIA contract. This is the most expensive part of a move and the shortest one in other people’s guides.
- The order of operations for an application that does not upgrade all at once: what can stand side by side, what conflicts, where the compatibility line runs.
- An effort estimate by application size — so that “move now or next quarter” is decided by a number rather than by mood.
How versioning will work
While there is one major, there is one set of documentation and it lives at
addresses without a prefix. When 1.0 ships, the current tree is copied into the
/v0/ archive, gets a banner and canonical links to the current equivalents, and
a version switcher appears in the documentation header next to the package
version.
The version in the header is read from the core’s manifest at build time — it is never typed by hand, and therefore never disagrees with what is on npm.
The details of the version support policy are on the versioning page.
Moving from another library is not migration in this sense and lives separately: Migrating from….