" > ts-node@10.0.0" has unmet peer dependency "@types/node@*".

[altro3]

Tried to change ts-node to latest version and now I have warning when run yarn upgrade:

[4/5] Linking dependencies...
warning " > ts-node@10.0.0" has unmet peer dependency "@types/node@*".

When using the previous version of ts-node, there was no such warning

Specifications

• ts-node version: 10.0.0
• node version: 16.2.0
• yarn version: 1.22.5
• npm version: 7.15.0
• TypeScript version: 4.3.2
• Operating system and version: Win10
• If Windows, are you using WSL or WSL2?: WSL

[cspotcode]

Yeah, we added that peer dependency so that we can automatically have node typings in certain situations. The release notes link to the relevant tickets. Is this causing problems?

…

On Sat, May 29, 2021, 7:14 AM altro3 ***@***.***> wrote: Tried to change ts-node to latest version and now I have warning when run yarn upgrade: [4/5] Linking dependencies... warning " > ***@***.***" has unmet peer dependency ***@***.***/node@*". When using the previous version of ts-node, there was no such warning Specifications - ts-node version: 10.0.0 - node version: 16.2.0 - yarn version: 1.22.5 - npm version: 7.15.0 - TypeScript version: 4.3.2 - Operating system and version: Win10 - If Windows, are you using WSL or WSL2?: WSL — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1354>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC35OFFVFUL7FVYMQJ7UTDTQDEAHANCNFSM45YGG44Q> .

[altro3]

No, I haven't noticed any problems. It's just that before this, such warnings have never occurred and I wanted to draw your attention to the fact that it might be worth changing something in the package.json settings, because now this warning arises constantly. I'm not an expert in nodejs, so I don't know how critical this warning is.

[cspotcode]

This is normal and not a problem. The warning goes away when you add @types/node as a dependency. And with the newest npm, it automatically installs peer dependencies so the warning doesn't happen at all.

…

On Sat, May 29, 2021, 9:10 AM altro3 ***@***.***> wrote: No, I haven't noticed any problems. It's just that before this, such warnings have never occurred and I wanted to draw your attention to the fact that it might be worth changing something in the package.json settings, because now this warning arises constantly. I'm not an expert in nodejs, so I don't know how critical this warning is. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1354 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC35OBIYA3H3VH5MWL6I4TTQDRTLANCNFSM45YGG44Q> .

[altro3]

@cspotcode Oh, really. It is enough to add the dependency on "@types/node" and the warning disappears. Thanks for clarifying! I think the ticket can be closed :-)

[MauriceArikoglu]

@cspotcode should it be in dependencies or devDependencies? I guess it should be devDependencies, no?

[cspotcode]

You can choose to declare it as a normal dependency or a devDependency, whichever makes the most sense for your project.

[MauriceArikoglu]

@cspotcode when would it make sense to have types in production?

[cspotcode]

dependencies vs devDependencies isn't really about production vs development, it's about if the dependency is necessary for your dependents to function correctly. Sometimes emitted .d.ts includes references to types, so consumers of your package will fail unless those types are installed. In these cases it is appropriate to declare as dependency even if it is only used in development.

[MauriceArikoglu]

@cspotcode I might be totally wrong here and I also deem the documentation about the different dependency fields unclear, but from my understanding, what you describe would be the peerDependencies of a package.
If I am not mistaken, the .d.ts is only used if I consume the package within a strongly typed project, say a typescript app.

"Just" the package is compiled into plain javascript. From my understanding of the documentation dependencies should only be the actual dependencies required to run / provide the functionality of my package. I would consider types to not be crucial for providing any logic / functionality required to run the software. So if my consuming application would be plain javascript, a type dependency that's also installed doesn't make much sense.

Putting additional type dependencies (if they, as you say, are included as require/reference in the package-umbrella-d.ts) in the peer dependencies will result in an install, without them actually becoming a dependency installed by default:

In some cases, you want to express the compatibility of your package with a host tool or library, while not necessarily doing a require of this host. This is usually referred to as a plugin. Notably, your module may be exposing a specific interface, expected and specified by the host documentation. (https://docs.npmjs.com/cli/v8/configuring-npm/package-json#peerdependencies)

I understand it so, that for the case with types the "compatibility of your package with a library" would be the compatibility with additional types if used in a typed environment.

---

edit:
by the way, thanks for taking the time & discussing this with me :)

[cspotcode]

No, what I described could be a dependency or a peerDependency. It could be either depending on the situation.

[MauriceArikoglu]

@cspotcode could you give examples for both situations please?

[cspotcode]

No, but you should be able to find resources online. The TypeScript Community Discord is a good place to ask.