Peer dependencies

[steida]

There are a few old closed issues I read and to be honest, I still do not understand what is Deno official opinion on peer dependencies. While I understand it's not a problem on the server to bundle several different versions on the same dependency, for client-side development, it's a severe issue. Peer dependencies are not even mentioned in the documentation. What does it mean? Thank you.

[steida]

OK, so the question was moved to discussions 12 hours ago without an official response. Message received.

[KnorpelSenf]

That sounds great in theory and I actually believed the same thing in the beginning. In practice, we have some non-trivial type errors that result from users composing various elements from the plugins and the core library. They're incompatible (on the type level) if they stem from different minor versions

I really don't understand what you mean by this. Typechecking will not be affected by importing different versions of the same library

Why not? In our case, users import a value (some deeply nested object which allows users to perform API calls) from one version, and a function consuming that object from another version, but if the API gets extended, a version mismatch will lead to compilation errors, even though no runtime code will fail.

People will have to --reload to do the manual deduping you're talking about

--reload will do nothing for a pinned version

As mentioned before, we use lib.deno.dev in order to update versions automatically through redirects, rather than pinning versions.

An alternative to our solution would be up ship dozens of patch updates for every release. Every plugin would have to be updated and the only change would be an updated dependency on the core lib.

[KnorpelSenf]

In a way, peer deps could be seen as DI on the module level. I think it could be possible to move this to the code level via dynamic imports. I'm honestly not sure if that's any better due to the drawbacks of dynamic imports, what do you think?

By the way, this will not work well because Deno Deploy does not support dynamic imports—but we obviously want to be able to use the library there. So this is not a solution, either.

[steida]

Note to self: aggressiveness always ensures a quick response, 10/10

Congrats https://deno.com/blog/package-json-support?utm_source=denonews&utm_medium=email#lingering-issues

[steida]

I moved it because it was not a directly actionable issue, and more a discussion but at @littledivy I gave an official response a while back:

The Deno CLI does not care what semantics a placed on the import specifier. That is up to the registry. There are several registries that already provide packages that way, like unpkg, snowpack, esm.sh, etc.

What you are suggesting is that you might want deno.land/x/ to support semver. That isn't an issue for the Deno CLI.

All that being said, this topic has been exhaustively been discussed before, so closing as duplicate of #47, #195, #288, #4574, #6030 and others.

I'm sorry that you are finding this confusing.

Congrats to release package.json

[KnorpelSenf]

Supporting package.json makes a lot of sense if the goal is to support Node projects out of the box. In contrast, supporting bare specifiers and ambiguous imports and inventing new protocols such as deno: and github: is ridiculous. See #17495 (comment), I don't want to repeat all the arguments here.