feature req: installing peer deps of current project about install-peerdeps HOT 17 CLOSED

Thanks for this feature request! Haven't had much time to work on this project recently but will work on it when I get the chance. If you would like to submit a pull, that would be much appreciated!

from install-peerdeps.

Since this package seemed to do a lot more than what I needed, I just implemented an extremely light-weight library to install the peer deps of your current directory: npx i-peers

from install-peerdeps.

thanks you so much @privatenumber your package has helped me with what I needed by installing the current project peer dependencies within itself.

from install-peerdeps.

I’m kind of confused by this use case; all peer deps should be also deps, or also dev deps, and as such should always be available when developing the project.

from install-peerdeps.

Can't tell if you're confused by this use-case or with the npm peerDependencies feature.

Are you arguing that people should be using dependencies/devDependencies over peerDependencies?

from install-peerdeps.

No, i’m saying that when a project has “x” in peer deps, it should also have “x” in either deps or in dev deps. Nothing should ever just be in peer deps.

from install-peerdeps.

Here's a simplified version of my use-case:

Context

Let's say I'm developing a Vue plugin and I bundle it using Webpack. The plugin imports vue and adds features to it.

Since it's a plugin, I don't want vue to be bundled-in so I externalize it from my distribution file.

Since it's a Vue plugin, it would be installed by a project that already has Vue installed, and probably has a Webpack build.

Problem

If vue was declared as a dependency/dev-dependency, installing the plugin will potentially install a different version of vue if there is a version discrepancy between the plugin's dependency and the application's dependency on vue.

That means Webpack will resolve and bundle-in different versions of vue depending on which package is requesting it. Obviously this can be mitigated with further Webpack configuration but that's not a complexity I want to introduce to my users.

Some might suggest setting the vue dev-dependency to * (or ^2.0.0) on the plugin-end to make it compatible with a large range. But in order to make sure I'm developing with the right version of vue (the version I want to offer support for), the vue installed in my dev-env should be the version you're declaring in peerDependencies, so that defeats the point of declaring it in devDependencies.

If I just use peer-dependencies, vue will be a requirement to installing my plugin, and will always use the provided instance of vue.

With i-peers, I can install the expected peer-dependencies for development without adding it to dependencies/devDependencies.

from install-peerdeps.

I don't think it does defeat the point - whatever range is in peers would also be duplicated in dev, eg if "vue": "^1 || ^2" is in peerDeps, you'd put the identical thing in devDeps too.

from install-peerdeps.

The situation is typically more nuanced and you wouldn't want such a large semver range. Especially with something like a plugin that might be tapping into internal API.

For example, there were internal changes introduced in Vue 2.6.0 that made me want to limit the support to Vue v2.6.0 and above, and with peerDependencies, I can strongly suggest that our users provide Vue ^v2.6.0.

Because peer dependencies aren't strictly enforced, users can use the plugin with Vue v2.5.0 if they want. I might not have tested the plugin to work with that version of Vue, but if they test it and it works well enough for them, then that's fine by me.

However, if I also include Vue ^v2.6.0 in my dependencies/devDependencies, it will install a separate version of vue.

i-peers is a very simple solution to a minor developer inconvenience that doesn't compromise or impose the peer-dep semver range.

I feel bad for having this convo in a repo about a completely different project. Let's take the issue to i-peers if you have anything more to add.

from install-peerdeps.

Note that npm 7 will strictly enforce peer deps - it will fail the install if peer deps aren't satisfied, as npm ls has failed for a decade already :-)

from install-peerdeps.

That's great. In most cases, I wouldn't want my users to use a version of vue I'm not supporting as it's typically inadvertent.

The teams and envs I work with are still on npm v6 (and plenty of people still use v6), but once v7 is prevalent, I might be able to put it in devDependencies as well.

If I still want to offer the flexibility of using any version, I can mark peer dependencies as optional via peerDependenciesMeta as of npm v6.11.0.

To give another example where it made sense to not include a peer dependency in the dependency hash, I was working on a library where which had docs with live demo code-snippets in them that used modules like axios. They were marked as peer-dependencies because they weren't required for the actual library to run, but only for the docs to be rendered by the documentation-site repo. They were truly optional peer dependencies, specifically required for docs. For development, instead of resolving them via npm, I ended up resolving via UNPKG for the local dev-env.

from install-peerdeps.

Peer deps have always been required, prior to peerDependenciesMeta, so in that case they should have been dev deps, not peer deps.

from install-peerdeps.

If you're talking about the one-line warning you get on unsatisfied peer-dependencies, I'm not sure if I'd call that "required".

Declaring it in dev-deps would install packages I don't actually need in dev, as they're resolved by UNPKG. And would also pollute the node_modules of projects that install my package in dev-mode.

Anyway, to go back to your main point:

No, i’m saying that when a project has “x” in peer deps, it should also have “x” in either deps or in dev deps. Nothing should ever just be in peer deps.

There's plenty of nuanced cases where a package can just be in peer deps.

from install-peerdeps.

hi there, I'll expose my situation about this issue, explaining about my use case below:

I'm developing ui component library based on react, so I have an isolated project that is built, and in the same way I'm having a stage which makes this project get up to preview its behavior, thus i need install its peerDependencies within itself. I tried run install-peerdeps --only-peers -S or install-peerdeps ./ only-peers -S but it did not work for me, then I choose the other way to do it.

from install-peerdeps.

@krobing what i'm saying is, you should duplicate all your peers in devDeps, and then they're already installed for local development.

@privatenumber nobody installs your package "in dev mode", dev deps are only for local development of your package; i'm saying use the local peer deps instead of unpkg.

from install-peerdeps.

Yeah @ljharb that is a way to do it, I just want to keep the devDeps section clean to solve a trouble when I use npm link to symlinks from main project to ui lib project which cause an error when finding duplicate modules, specifically with styled-components and react hooks.

from install-peerdeps.

When linking, all peer deps must also be linked, regardless of the approach you take.

from install-peerdeps.