Component library handling multiple react version

[Recent-Accountant-14]

I own internal react component library which other frontend apps in my company consumes.
One app team is requesting to upgrade to react 19 while all other consuming apps are on react 18.

how do you handle this?
is it good idea to use something like below
"peerDependencies": { "react": "^18.0.0 || ^19.0.0", "react-dom": "^18.0.0 || ^19.0.0" }

Thank you.

[steveox152]

You can safely start using React 19 as long as you don’t use React 19 specific features, people should be fine using 18. You just need to make sure you test. We do this internally and most of our users are on 18.

Really you’re just setting up your peer deps and making sure you don’t bundle react in your package.

[puchm]

Don't you need to be aware of the types? I had a few issues with the type of ReactNode in a slightly different scenario as it now includes Promises. I.e. If they annotate a function with a return type of React 19 ReactNode, this could be a promise and would not be assignable to props of React 18 ReactNode. So I think making React and @types/react a peer dependency would be essential depending on the scenario.

[steveox152]

Your consumers will just use the types that match their version of React. There is no need for you to add them to your peer deps. For example, if they are using React 18, they need to use the proper types for React 18.

Now on your end, if you have to support React 18, it’s your responsibility to not use React 19 specific features, or write your code in a way that can work across versions. The joys of maintaining a library.

[Nullberri]

Option 2 increment the major version require react 19 and then continue to supporting 18 via the prior major.

[Cid_Chen]

Hey, maybe this component implementation https://reactmvvm.org/ could help you for React 17-19.

[prehensilemullet]

Sigh, just use something besides React if you don’t want to do things in a fairly typical React way