React 19 in Figma Make

Hi, ​@Benjamin - stepping in for ​@Celine_! Thank you for flagging that in our developer documentation - I can see how that would be confusing.

Did you try using React 19 and are still unable to use that as your base, or have you not tried because of what the documentation states? I flagged the article to our team so we can get that updated. Having said that, let us know if you are unable to do this in a new Make file, or if you can but are running into issues. Happy to help.

Reproduced this today (2026-08-27), from a different angle than the original report, and can confirm the underlying issue is still present.

Installing react@19.2.6 as a dependency in a newly-created Make file works fine, and the npm install itself succeeds. But any code that uses a React-19-only feature crashes at runtime. Specifically: React 19 added the ability to render a Context object directly as a provider — <MyContext value={x}> instead of <MyContext.Provider value={x}>. A design-system component using this pattern throws:

Warning: Rendering <Context> directly is not supported and will be removed in a future major release. Did you mean to render <Context.Consumer> instead?
...
TypeError: _ is not a function

That first warning is React ≤18's own message — it doesn't exist anywhere in React 19's source. So I pulled code_components_preview_iframe-*.min.js.br directly and decoded it: it contains the literal string "18.3.1", and the exact legacy context-handling function (_e, matching the crash's stack frame) that emits that warning. There's no trace of React 19's context-as-provider code path anywhere in the bundle.

So it looks like the Aug 12 "React 19 support" only covers what you can declare in the code component's own package.json — the preview iframe that actually owns the render root and reconciles the tree is still React 18.3.1. Any library relying on a React-19-only API (this Context shorthand, but presumably others too) will break, even though npm install succeeds and nothing in the tooling warns you about it until runtime.

Could someone confirm whether the preview iframe's own React version is meant to be part of this rollout, or whether "React 19 support" is intentionally scoped to dependency resolution only? That distinction isn't documented anywhere I could find, and it's easy to hit this silently.

Good catch, ​@Vinayak Patil - thank you for flagging this and for providing an example! I’ve shared this with the team for review - one would definitely expect the preview to use the same version of React. Just to be clear, your published app uses the version of React declared in package.json, right?

Yes, the published app uses React 19 but it fail to render in the figma make preview iframe which is still not compatible with React 19 I believe. 

Can confirm, it’s still not working properly. Oh boy.

Folks, I can’t believe how hard it is for you to update to the latest React version. I deleted and recreated our Make kit now for the 7th time and Claude Opus 4.8 in Make still tells me that the preview harness is on React 18 and that’s why it’s incompatible with our npm package and its scaffolding. I'm losing trust in your AI strategy at Figma here, you promote all the latest AI features but don’t get the basics working. I’m really frustrated by now and don’t know how many more times I need to create a kit from scratch, lose all progress and waste working hours on that.

React 19 in Figma Make — dev perspective: the preview iframe still runs React 18.3.1

Adding a developer-side view to this thread. I maintain a React component library (~100 components) that is consumed by product teams and is also meant to be used by designers in Figma Make. The library targets React 19, and the preview iframe being stuck on 18.3.1 makes it unusable — not partially, but completely.

I verified each point against a real React 18.3.1 runtime, not just from the console output in Make.

1. Context-as-provider → hard crash, blank preview

React 19 lets you render the context object itself (<Ctx value={…}> instead of <Ctx.Provider value={…}>). On 18.3.1 this throws TypeError: … is not a function, with the stack ending inside Figma’s own preview bundle. Our layout primitives (the wrapper/grid components) use this syntax — so literally any prototype that wraps content in a layout container renders nothing. That cascades to roughly 17 higher-level components that compose those primitives internally.

2. ref as a plain prop → silent breakage

React 19 made ref a regular prop on function components; forwardRef is no longer needed. Libraries built for React 19 therefore ship zero forwardRef calls — ours included. Under React 18, any ref passed to such a component is silently dropped: no error, just a dev warning most people never see. In our case 13+ components lose focus management, scroll-to-error and animation triggers. The prototype looks correct and is quietly broken.

3. inert → the preview is measurably less accessible than the real product

This one matters for designers, not just devs. inert is the browser feature that makes a region non-focusable and invisible to screen readers — it’s how a modal stops you from tabbing into the page behind it. React 19 supports inert as a boolean attribute; React 18 does not know it and silently drops it from the DOM. Result in the Make preview:

• Modal / drawer overlays: keyboard focus and screen readers can still reach the page behind the overlay
• Carousels: off-screen slides stay in the tab order and are still announced
• Hidden sticky bars: still focusable

None of this shows up visually. The preview looks pixel-identical to production while behaving differently for keyboard and screen-reader users — so accessibility reviews done in Make would be based on a false signal.

4. Further React 19 features

Additional React 19 capabilities (cleanup functions returned from ref callbacks, the changed useId format, React-19-only @types/react) fail in smaller but equally silent ways. Downgrading our types to @types/react@18 alone produces 26 compile errors in our source.

Beyond the API gap: the age of the pinned version, and the missing update process

Stepping back from the individual APIs, the more fundamental issue is how far behind the pinned runtime is, and that there is no visible process for keeping it current.

react-dom@18.3.1 was published two years ago and is the last release on the 18.x line (npm). React 19 has been stable since December 2024 and has since gone through several minor releases. So the preview iframe is not “one version behind” — it is a full major plus two years of maintenance behind, and it stayed there long enough that the gap has outlived multiple React release cycles.

From a software perspective, adopting Figma Make as a tool means taking on an external runtime dependency that we cannot version, pin, patch or override. We would normally accept that, but only if the vendor can point to an update process. Right now the observable evidence suggests there isn’t one: the bundled React has not moved in two years, and the announcement of “React 19 support” changed the project template without changing the runtime that actually renders — which is exactly the symptom you get when nobody owns the version of the bundled runtime.

So the question I’d like answered isn’t just “please ship React 19”. It’s:

1. Who owns the React version inside the preview iframe, and on what cadence is it updated?
2. What process guarantees we don’t land in exactly this situation again with React 20? If the answer is “it gets updated when someone notices it’s broken”, then every library author has to plan for the preview lagging by years, indefinitely.

A published commitment would settle it — either “the preview tracks the latest stable React within N weeks of release”, or better, “the preview uses the React version installed in your project”, which removes the coupling entirely. For anyone doing a tooling review before rolling Make out across an organisation, that answer matters more than any of the individual API breakages above: those are bugs, this is a maintenance question.

Worth stressing: none of our runtime dependencies block React 18 — the CSS-in-JS layer, the date picker, the HTML parser and the map bindings we use all declare support for React 16.8/18 and 19. React itself is the only blocker.

And these aren’t things a library can shim. <Ctx value> and ref-as-prop are compiler/runtime semantics; inert is a DOM serialization decision inside react-dom. Maintaining a parallel React-18 build of a design system purely for Figma Make would mean re-introducing forwardRef library-wide and diverging from what product teams actually ship.

The current workaround our designers are left with is reimplementing the layout primitives as plain styled components on top of our design tokens — i.e. rebuilding the design system inside Make, which defeats the point of having one.

What we’d need: the preview iframe bundle shipping React 19, or deferring to the version installed in the project. Updating package.json templates is not enough — the render environment has to match. Happy to provide a minimal repro repo.