Why not auto-detect NPM registry from .npmrc? about install-peerdeps HOT 10 CLOSED

I'll take a look at branching this and see what I come up.

from install-peerdeps.

It could certainly shell out to npm config get registry.

from install-peerdeps.

This would be a huge improvement. As far as I can tell, this project right now is unusable because our corporate requirements result in needing to use multiple regestries, which are separated by package namespaces:

Example

• @my-corp/my-package loads from private registry "A"
• @my-other-corp-group/my-package loads from private registry "B"
• eslint loads from a mirror of the public NPMJS.org registry, which is private registry "C"

from install-peerdeps.

Hmm, I'm not sure how that would work with npm config get registry, which pulls a single value; if you're using scoped registries, npm install figures that out by itself.

from install-peerdeps.

The point of this script is to install peer dependencies for a specified package, right? npm isntall doesn't do that. So if a package has namespaced dependencies, it should be able to resolve those.

Seems this package could do that by just passing each found package to node install via child_process.spawn(). That's effectively what I'm having to build as a custom script instead of using this utility.

from install-peerdeps.

That's basically what it's already doing: https://github.com/nathanhleung/install-peerdeps/blob/master/src/install-peerdeps.js#L84-L103

Since it's using npm install by default, in the proper directory, I'm not sure why it's not already working.

I think the issue is that getPackageData is making a direct request to the registry. I think the solution is, to shell out to npm show --json ${packageName}, and use that data - that way the registry for the package will be taken from npmrc normally.

from install-peerdeps.

Yeah, since getPackageJson calls getPackageData, and passes the provided registry from the CLI option, it can only track across one registry. There's nothing in the NPM standard mandating dependencies are available in the same registry as the package referencing them.

from install-peerdeps.

A PR would be appreciated.

from install-peerdeps.

I'm not sure how to address it in this project without significant restructuring of the interfaces being exposed. In the script I've built privately, I've avoided all the registry and proxy passing entirely (that adds a huge amount of complexity with the corporate proxies I have to deal with). Instead of using the remote registry to get package data or npm show, I'm just drilling into node_modules to find a package.json like the peers-only option does here. That's not particularly future-proof though and is a good design question for what this project wants to do.

from install-peerdeps.

It seems like just a refactor in getPackageJson, you can leave getPackageData intact and unused?

from install-peerdeps.