The latest updates on your projects. Learn more about Vercel for Git ↗︎

@MidnightLightning is attempting to deploy a commit to the Superfluid Finance Team on Vercel.

A member of the Team first needs to authorize it.

Hey @MidnightLightning

I appreciate the effort.

The intent of a "peer dependency" is to indicate to the package manager that the other library is "good to have", but not essential for the running of the component.

Sorry but this is not correct. A peer dependency not marked as optional is as much of an essential dependency as a regular dependency. Because the types of wagmi/viem are exposed in the widget's API then it's correct to make them peer dependencies.

So I don't think this is the correct solution... but I see what you're going for though... and understand the frustration. I can do a special release for this.

It's also probably possible to fix it with NPM overrides, NPM aliases or monkeypatching somehow, but it's a pain...

Did you try automatic installation of peer dependencies?

A peer dependency not marked as optional is as much of an essential dependency as a regular dependency.

Ah, you're right; I believe my statement would be more accurate as "indicate to the package manager that THIS SPECIFIC VERSION OF the other library is good to have", as it seems if another version of a peer dependency is installed, it generates a warning rather than a failure. Past v7 of npm if no version of a peer dependency is part of the project it gets installed, though (https://github.blog/2020-10-13-presenting-v7-0-0-of-the-npm-cli/). Does that sound more correct?

Aside from the nuances of whether something should be a peer dependency or standard dependency, for the Superfluid widget, I don't think "automatic installation of (missing) peer dependencies" would help in its current form, because the peer dependency is defined as "wagmi": ">=1", and if the project has v2 as a dependency, that fulfils that logic (it doesn't count as "missing"). It allows building in that situation but fails at runtime as the Superfluid widget includes wagmi v2 files and assumes they're a different shape. Possibly if that peer dependency were updated to exclude wagmi v2 (e.g. "wagmi": "^1", so it doesn't cross the major-version boundary), then NPM's "install missing peer dependencies" might solve it?

Because the types of wagmi/viem are exposed in the widget's API then it's correct to make them peer dependencies.

Can you explain further how the types are "exposed"? If wagmi v1-shaped objects are returned as results, if Superfluid specified wagmi v1 as a normal dependency, a project that doesn't have wagmi as a project dependency but includes the Superfluid widget can import the type directly from the Superfluid widget (e.g. ReturnType<typeof superfluidWidgetThing>) without needing to know it's specifically "a wagmi v1 thing", I believe? Or said differently, what's the "bad thing" that would happen if wagmi were a dependency instead of a peer dependency?

It's also probably possible to fix it with NPM overrides, NPM aliases or monkeypatching somehow, but it's a pain...

I did attempt to use npm aliases to get two different versions of wagmi, but because the Superfluid widget code refers to it as "wagmi", it seems the project-installed ("peer" dependency) needs to have "wagmi" be v1, forcing everything else in the project to be using some other term (e.g. "wagmi-latest"). I couldn't get that working completely, as it does get tangled with aliases pretty easily, so a solution that way I agree would be a pain to maintain and pretty fragile.

Oh, I forgot about the wagmi context that needs to be set; that would be a limiting factor for having wagmi be a dependency 🙈 If the project configured a "wagmi v2" provider, and put a Superfluid widget within that context, the widget would expect the provided context to be a different style, so likely wouldn't work even if it had a copy of the wagmi v1 code bundled with it.

So, the basic change here I think is the peer dependency needs to note that wagmi v2 is not supported, which will at least allow NPM to properly warn project developers when there's likely to be runtime incompatibilities with the Superfluid widget.

Oh indeed, this is wrong in the widget package.json:

"viem": ">=1",
"wagmi": ">=1"

Thanks for updating the v0 version of the Superfluid widget to properly self-identify as needing a wagmi v1 environment. I'll close this request and attempt to get my own development environment working to be able to contribute the code changes needed to run within a wagmi v2 environment, as a potential new major version for the Superfluid widget.