You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Type error: Argument of type 'ComponentType | ReactNode' is not assignable to parameter of type 'ReactNode | ComponentType<{}>'.
Type 'ComponentClass<{}, any>' is not assignable to type 'ReactNode | ComponentType<{}>'.
Type 'import("/vercel/path1/node_modules/@sanity/types/node_modules/@types/react/index").ComponentClass<{}, any>' is not assignable to type 'React.ComponentClass<{}, any>'.
Types of property 'contextType' are incompatible.
Type 'import("/vercel/path1/node_modules/@sanity/types/node_modules/@types/react/index").Context<any> | undefined' is not assignable to type 'React.Context<any> | undefined'.
Property '$$typeof' is missing in type 'import("/vercel/path1/node_modules/@sanity/types/node_modules/@types/react/index").Context<any>' but required in type 'React.Context<any>'.
And since @sanity/types has a direct dependency on @types/react there isn't an easy to solve it, userland has to resort to package manager overrides 😅
It's always been bad to have direct deps on types that can have different majors that are incompatible, so the fix is to move it to a peer dep.
What to review
Makes sense?
Testing
If it builds it works.
Notes for release
Improves React 19 compatibility for TypeScript users, by moving the @types/react direct dependency in @sanity/types, to a peer dependency.
efps — editor "frames per second". The number of updates assumed to be possible within a second.
Derived from input latency. efps = 1000 / input_latency
Detailed information
🏠 Reference result
The performance result of sanity@latest
Benchmark
latency
p75
p90
p99
blocking time
test duration
article (title)
47ms
52ms
92ms
527ms
933ms
11.3s
article (body)
16ms
17ms
29ms
160ms
217ms
5.3s
article (string inside object)
40ms
42ms
49ms
171ms
154ms
7.0s
article (string inside array)
46ms
49ms
53ms
359ms
412ms
7.8s
recipe (name)
19ms
21ms
25ms
42ms
0ms
6.9s
recipe (description)
17ms
19ms
21ms
29ms
0ms
4.4s
recipe (instructions)
5ms
7ms
8ms
9ms
0ms
3.1s
synthetic (title)
52ms
55ms
69ms
315ms
605ms
14.2s
synthetic (string inside object)
53ms
56ms
70ms
365ms
751ms
8.5s
🧪 Experiment result
The performance result of this branch
Benchmark
latency
p75
p90
p99
blocking time
test duration
article (title)
38ms
41ms
51ms
472ms
207ms
11.8s
article (body)
15ms
19ms
33ms
89ms
200ms
5.4s
article (string inside object)
39ms
42ms
47ms
184ms
146ms
6.7s
article (string inside array)
42ms
46ms
55ms
312ms
429ms
7.4s
recipe (name)
17ms
19ms
22ms
34ms
0ms
6.9s
recipe (description)
15ms
17ms
18ms
32ms
0ms
4.3s
recipe (instructions)
6ms
7ms
8ms
25ms
0ms
3.1s
synthetic (title)
52ms
54ms
57ms
286ms
571ms
12.7s
synthetic (string inside object)
48ms
50ms
58ms
436ms
122ms
7.9s
📚 Glossary
column definitions
benchmark — the name of the test, e.g. "article", followed by the label of the field being measured, e.g. "(title)".
latency — the time between when a key was pressed and when it was rendered. derived from a set of samples. the median (p50) is shown to show the most common latency.
p75 — the 75th percentile of the input latency in the test run. 75% of the sampled inputs in this benchmark were processed faster than this value. this provides insight into the upper range of typical performance.
p90 — the 90th percentile of the input latency in the test run. 90% of the sampled inputs were faster than this. this metric helps identify slower interactions that occurred less frequently during the benchmark.
p99 — the 99th percentile of the input latency in the test run. only 1% of sampled inputs were slower than this. this represents the worst-case scenarios encountered during the benchmark, useful for identifying potential performance outliers.
blocking time — the total time during which the main thread was blocked, preventing user input and UI updates. this metric helps identify performance bottlenecks that may cause the interface to feel unresponsive.
test duration — how long the test run took to complete.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
On React 19 I'm seeing build errors like this:
And since
@sanity/types
has a direct dependency on@types/react
there isn't an easy to solve it, userland has to resort to package manager overrides 😅It's always been bad to have direct deps on types that can have different majors that are incompatible, so the fix is to move it to a peer dep.
What to review
Makes sense?
Testing
If it builds it works.
Notes for release
Improves React 19 compatibility for TypeScript users, by moving the
@types/react
direct dependency in@sanity/types
, to a peer dependency.