fix(vite): add missing peer dependency on vue

[clemyan]

vite-plugin-vue-devtools has a dependency on @vue/devtools-core which peer-depends on vue, but vite-plugin-vue-devtools declares neither a dependency nor a peer-dependency on vue

This PR adds vue as a peer-dependency of vite-plugin-vue-devtools

[netlify]

✅ Deploy Preview for vue-devtools-docs canceled.

Name	Link
🔨 Latest commit	9057ca0
🔍 Latest deploy log	https://app.netlify.com/projects/vue-devtools-docs/deploys/6a01f89316b70a0008d74e12

[skirtles-code]

I'm struggling to understand the motivation behind this change.

vite-plugin-vue-devtools doesn't import anything from vue directly, either in the original source or the built files.

Why do we need to list a dependency on vue if it's only used via a transitive dependency that's already listed?

Could you provide some more explanation about what you're hoping to achieve with this change?

Thanks.

[clemyan]

vite-plugin-vue-devtools has a dependency on @vue/devtools-core which peer-depends on vue, but vite-plugin-vue-devtools declares neither a dependency nor a peer-dependency on vue. Sure, whatever app using vite-plugin-vue-devtools as a (possibly transitive) dependency will most likely have vue somewhere in their dependency tree, but the behavior is not consistent across different package managers.

Consider the case where a user is creating an app that depends on vite-plugin-vue-devtools, vite, and vue.

If the app is using npm, then it is not guaranteed that the instance of vue that @vue/devtool-core gets is the same instance of vue that the app uses. Depending on what other dependencies the app has and/or what vite-plugin-vue-devtools adds as dependencies in the future, it is possible that npm hoists package in such a way that the app and @vue/devtools-core uses two different instances of vue

Ensuring that the app and @vue/devtools-core uses the same instance of vue requires an unbroken chain of peer dependencies from @vue/devtool-core to the app. This PR adds the missing link.

If the app is using pnpm, peer dependencies can be satisfied by and only by ancestors. So @vue/devtools-core will get the same instance of vue the app uses. This is more consistent than how npm works but that still means that an ancestor of vite-plugin-vue-devtools must depend on vue. So vite-plugin-vue-devtools has an implicit peer dependency on vue.

Relying on implicit peer dependency isn't ideal. Adding a dependency may inadvertently remove an implicit peer dependency which can lead to breakage. For example, if vite-plugin-vue-devtools somehow needs vue in the future, a contributor may naively add it as a regular dependency, which again may lead to the app and @vue/devtools-core getting different instances of vue. Conversely, removing a (regular) dependency may inadvertently create a new implicit peer dependency and breaking dependents. This PR removes vite-plugin-vue-devtools's implicit peer dependency on vue by making it explicit.

If the app is using Yarn with node-modules, it suffers the same problem as npm. Yarn will warn about this but ultimately relies on hoisting to make vue available to @vue/devtool-core.

If the app is using Yarn with PnP, @vue/devtools-core won't have access to vue at all. Under PnP, if a package requests a peer dependency, the direct parent must satisfy it with a dependency or peer dependency, otherwise resolution will fail.

In other words, for @vue/devtools-core to successfully resolve vue, there must be an unbroken chain of peer dependencies from @vue/devtool-core to the app. Otherwise, yarn run vite build will fail. This PR adds the missing link.

The examples I provided may be far-fetch and may not exactly apply to vite-plugin-vue-devtools, but the general message I want to send is that relying on implicit peer dependencies does not behave consistently across package managers, and can lead to accidental breakage. Creating an unbroken chain of peer dependencies between requester and provider is a much more consistent and predictable way of dealing with peer dependencies.