This document defines the versioning policy for test-renderer (TR) starting with 1.x.
- Avoid leaving users without an installable
test-rendererrelease when React publishes a new 19.x minor before the matching preferred TR line is ready. - Let consumers adopt new React features as soon as their React version supports them.
- Let a consumer package such as a testing library depend on
test-rendererwithout forcing all users onto the newest React 19 minor. - Avoid vendoring
react-reconcilerunless it becomes necessary.
test-renderer depends on a single react-reconciler (RR) version line at a time.
Because react-reconciler is versioned alongside React internals, each test-renderer minor still has a preferred React / RR line even when the package publishes a broad React 19 peer range.
In practice, older test-renderer lines may continue to work on newer React 19 minors for many use cases, but they should not be assumed to support newer-minor-specific features until the matching TR line exists.
For test-renderer 1.x, the version number has two meanings:
majortracks TR API or behavior breaks, or a move to a new React major.minortracks the preferred React 19 compatibility line and bundledreact-reconcilerline.patchtracks fixes and features that stay within the same preferred line.
In practice, each 1.x minor corresponds to a specific React / RR line, while peerDependencies.react stays broad enough to avoid blocking installs across React 19 minors.
Starting with 1.x, test-renderer tracks preferred React 19 compatibility lines while keeping a broad React 19 peer range so installs do not get blocked between React minor releases.
test-renderer version |
react version |
react-reconciler version |
peerDependencies.react |
Notable React features |
|---|---|---|---|---|
1.0.x |
19.0 |
~0.31.0 |
^19.0.0 |
Actions, useActionState, useOptimistic, use |
1.1.x |
19.1 |
~0.32.0 |
^19.0.0 |
Owner Stack support, CSS-selector-safe useId() format |
1.2.x |
19.2 |
~0.33.0 |
^19.0.0 |
<Activity />, useEffectEvent |
These feature examples are illustrative, not exhaustive. The 1.0.x, 1.1.x, and 1.2.x lines are current compatibility lines. New React-minor-specific support lands on the matching preferred React / react-reconciler line for each 1.x release, even though the package publishes a broad React 19 peer range.
Use patch releases for:
- bug fixes within the current preferred React compatibility line
- internal improvements that do not raise the minimum supported React minor
- new TR features that work on the existing RR line
Example:
1.1.2->1.1.3for a bug fix that still supports React19.1.x
Use minor releases for:
- adopting a newer
react-reconcilerline - advancing the preferred React 19 minor line
- introducing features that require the newer React / RR line
Examples:
1.0.x->1.1.xwhen moving from RR0.31to0.321.1.x->1.2.xwhen moving from RR0.32to0.33
Minor releases are where React-minor-specific features become officially supported. Older lines may still install and work on newer React minors, but the newer line is the preferred target once it exists.
Use major releases for:
- TR API or behavior changes that break existing consumers across compatibility lines
- a move from React
19support to React20
If a new TR feature or bug fix does not depend on a newer React / RR line, it should be backported to every maintained compatibility line.
Examples:
- a fix that works everywhere may ship as
1.0.5,1.1.4, and1.2.1 - a feature that requires React
19.2should ship only in1.2.x
This lets users on older preferred lines keep receiving fixes without waiting for newer React-specific work.
test-renderer should use a broad React 19 peer range across active 1.x lines.
Recommended range:
1.x:^19.0.0
This keeps installs working across React 19 minors even when the matching preferred TR line has not shipped yet.
Broad peers are not a promise that every 1.x line fully supports every newer React 19 minor feature. The preferred React / RR line for each minor release remains the authoritative signal for where new React-minor-specific support lands.
A consumer package such as a testing library should depend on test-renderer as a regular dependency, not a peer dependency.
Recommended range:
{
"dependencies": {
"test-renderer": "^1.0.0 || ^1.1.0 || ^1.2.0"
}
}This keeps the consumer package open to newer test-renderer lines without turning test-renderer into another peer dependency.
To make this work well, the consumer package should either:
- rely only on TR APIs available across all supported
1.xpreferred lines, or - use feature detection when integrating with newer TR capabilities
When multiple 1.x compatibility lines are live, direct test-renderer consumers should get line-specific dist tags:
latest-> newest supported line, typically the highest React 19 linereact19.0-> latest1.0.xreact19.1-> latest1.1.xreact19.2-> latest1.2.x
This keeps npm install flows predictable for users who consume test-renderer directly.
During rollouts to later React 19 lines, latest may temporarily lag the highest published compatibility line. Dist tags become more useful once there is more than one active 1.x line.
The recommended test-renderer 1.x scheme is:
1.0.xfor React19.01.1.xfor React19.11.2.xfor React19.2
With this scheme:
- installs remain unblocked across React 19 minors
- a consumer package can stay compatible with multiple React 19 lines
- new React features can be exposed as soon as a new compatibility line is published
- vendoring
react-reconcileris not required