`kotlin-wrappers:kotlin-react-core` is an amazing ...

# react

[andylamax]

kotlin-wrappers:kotlin-react-core is an amazing library filled with very well described externals for react. I like how it is separated from kotlin-react which brings convenience functions to be used from kotlin. However, I have faced some challenges using these wrappers on our own kotlin/react library that has got to be consumed from typescript

When we publish our kotlin/react library, it ends up having a react dependency in it's package.json which forces our consumers to update to the react version from kotlin-wrappers:kotlin-react and kotlin-wrappers:kotlin-react-core as bundled by our kotlin/react library.

This can be challenging and problematic. My request to @turansky is can we add react as an peerDependency to kotlin-wrappers:kotlin-react and kotlin-wrappers:kkotlin-react-core so that our users won't be forced to use react that comes from these amazing library

[turansky]

AFAIK You can control resulted package.json via special Gradle task

[andylamax]

Well, I believe its possible. But I also think that my request is still valid (even though you can achieve that through a custom gradle task to do that).

Won't changing

jsMainApi(npm("react"))

into

jsMainApi(npmPeer("react"))

be the best solution and benefit all consumers???

[turansky]

be the best solution and benefit all consumers???

And as result we will receive random React version in application 😞
It's not what I expect.

jsMainApi(npmPeer("react"))

What if you will declare peer dependency in library?
Will it work?

[andylamax]

And as a result we will receive random react version

this can be mitigated by explicitly adding the react dependency you need to use your final appllication (not library code)

jsMainApi(wrappers.react.core)
jsMainApi(npm("react","x.x.x"))

and library authors can let the consumers pick their own react versions

[andylamax]

what if you will declare peer dependency in library??

I honestly haven't tried that, is this the best long term solution?? shouldn't a library like this (like many react libraries) have react as a peer dependency instead of it being a direct dependency??

[andylamax]

Actuall, adding jsMainApi(peerNpm("react")) does seem to move react from core dependency into peerDependencies. That's a huge plus. this does solve my issue with forcing users onto a specific react depedency

Though my problem has been fully solved, My question still remains though.

is it the best solution to define react as a core dependency in a library??

[andylamax]

• @tanstack/react-table defines react as a peerDependency, kotlin-tanstack-react-table has react as a depedency
• react-router defines react as a peer and dev dependency, kotlin-react-router defines it as a core dependency
• react-select defines react as a peer dependency, kotlin-react-select defines it as a core dependency
I can keep going on this, but the the general takeaway is that, these libraries should really not force the consumer into the version they are developed on.

The libraries themselves can however enforce the version of react they are targeting using devNpm , but allowing users to pick their own react versions.

BTW, This whole logic applies beyond react

[turansky]

@andylamax You have control over package.json and you can describe your library rules and versions.
For application developers we fix versions which we support in wrappers. They receive dependencies by default and it's what we want.

If you wanna have all NPM dependencies as peer dependencies - you have extension point.

[andylamax]

For application developers we fix versions which we support in wrappers

But kotlin-react and kotlin-react-core is not an application but a library, don't you think it'd be wise to follow the guidelines of a library.

This is same as gradle's enforcePlatform . I'll advised for a library, but a good option for an application

[turansky]

If you have good option both for application and library users - please describe it in issue.
For now described solution = dependency problems both for application and library developers + small bonus for library developers

[turansky]

My question still remains though.

is it the best solution to define react as a core dependency in a library??

As you see - you have full control inside your project.
Application developers have synchronized Gradle and NPM dependencies by default.
Library developers can move some dependencies (all or some of them) in "peer" section if they want.