react native dependencies broken my dependency tree

[moonrailgun]

I found this commit 8e8a4b6 change all @types/react-native to react-native but some library declare this in dependencies fields

so when i try to install those type library in pnpm, its will broken my dependencies tree and throw those error

I dont know why, but if i change library's dependencies and remove it , every thing is ok.

I thinks its a mistake for those library which make react-native in dependencies field and you know its will be install rather than devDependencies which will be ignore.

[jakebailey]

@lunaleaps

But you should be using discussions for these kinds of questions.

[moonrailgun]

But you should be using discussions for these kinds of questions.

well, but i think its not a question but a issue, common issue.

It's just that in other package management software it will be obscured because they are not so precise

[jakebailey]

well, but i think its not a question but a issue, common issue.

Our discussion boards ping package owners; the issue tracker is supposed to be for infrastructure issues only (hence why the only valid form is for infra issues, which everyone is ignoring).

[lunaleaps]

@moonrailgun I'm not sure I understand how that error is related to the type change. Can you clarify that connection?

Happy to continue discussion in a discussion board or a react-native issue

[moonrailgun]

@moonrailgun I'm not sure I understand how that error is related to the type change. Can you clarify that connection?

Happy to continue discussion in a discussion board or a react-native issue

the major problem is as a type dependency try to install a real dependency, and react native has a lot of implicit dependencies.

I am using pnpm and its will broken topology of react native dependency. i think its not true so i remove it and everything is work.

I don’t know why this problem occurs under the hood. I only know that types should not actually install an library. It should be used as devDependency or peerdependency.

[lunaleaps]

I'm wondering if its also because react-native doesn't support pnpm from my understanding and DefinitelyTyped doesn't support peer dependencies as mentioned here: #67459 (comment)

[jakebailey]

I only know that types should not actually install an library. It should be used as devDependency or peerdependency.

This is generally not true; types dependencies are real dependencies, and are needed if you ever want to use a library that uses another library's types. Peer dependencies are certainly possible and I have half proposed switching DT to them, but not all package managers auto-install peers (notably, no version of yarn does!)

[moonrailgun]

react-native doesn't support pnpm from my understanding

In fact, our team is using pnpm workspace to manage react native projects (excluding expo)

types dependencies are real dependencies, and are needed if you ever want to use a library that uses another library's types

I mean a type library should not help people install other library. because its not real run in runtime.

For example, user install package A@^1.0.0, and create lock file, everything is good.

Then, user install a type library which include A@1.1.0 in dependencies list, and everything maybe broke.

---

After all, i just report a problem as user. although I solved this problem myself, I thought someone might have the same problem as me in the future. so i report it let you know.

Because this is the source of my problem and I think this design is unreasonable. It violates the node package management design philosophy. They should be a peerdependency rather than dependencies.

There is no problem if a type library depends on a type library, but if it is changed to a complete library, we must pay attention to its impact.

If I install a type library that depends on react native, I will definitely not expect this type library to install react native for me.

[jakebailey]

There is no problem if a type library depends on a type library, but if it is changed to a complete library, we must pay attention to its impact.

This is generally inevitable as DT becomes less relevant and more packages include their own types (which has strong benefits).

That being said, for packages where it's clear that you're going to have to install a sibling package (like react, express, etc), I think that it's possible for DT to do peer dependencies safely, even with yarn not behaving like other package managers on that front.

[lunaleaps]

I think at this stage, this is a limitation from DT.

From discussion on the change, we can consider releasing a types-only react-native package if it becomes a larger issue