-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
use package manager to get info #85
use package manager to get info #85
Conversation
Renames onlyPeers parameter to noRegistry which better reflects what this function is doing. This function doesn't care about peers vs. main, that's in a different scope.
… lists `--only-peers` was doing two different things which complicated the need for proxy settings. Not only was it flagging whether to install the main package with the peers, it was also toggling whether the peerDeps list was being generated from a local node_modules vs a remote registry. By splitting this into two distinct feature flags, we make behavior clearer, and future case of delegating proxy settings to NPM or Yarn instead of handling those in the utility. BREAKING_CHANGE: `--only-peers` now searches for peerDeps via the registry unless `--no-registry` is also specified * was: `install-peerdeps <package> --only-peers` * now: `install-peerdeps <package> --only-peers --no-registry`
Errors are often on stderr and that's important for debugging
Fixes #73 Removes a bunch of custom logic and leverages the "info" command that all package managers provide for getting package details from a remote registry. By using the package tool, we can delegate proxy configs, private registry paths, and auth tokens to the package manager. This is especially valuable in networks that require complex proxy configurations, or when packages have peerDependencies that may be in multiple other private than the singular one that was specified BREAKING_CHANGE: removes `--registry` `--auth` and `--proxy` options Use `.npmrc` or `.yarnrc` to mange private registry paths, auth tokens, and proxy configs
This is done and ready for review. This includes the work from #84 The failing build looks like it's something weird with the Node 8 agent, possibly because it doesn't have Considering this is a major version bump, it would be an appropriate time to take advantage of the breaking change to drop Node 8. |
Co-authored-by: Jordan Harband <ljharb@gmail.com>
.travis.yml
Outdated
@@ -2,7 +2,6 @@ language: node_js | |||
node_js: | |||
- "12" | |||
- "10" | |||
- "8" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be very explicit: no PR with this change can land, as long as I have a say.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then it's nothing is going to merge. Because without it is failing and master is failing.
Take it or leave it, your attitude is not one that inspires me to contribute further.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since node v8 is end of life now, can we merge this? This would be a great improvement for this tool IMO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A node version being EOL is irrelevant; package authors can and should support engine versions long after their vendors have stopped doing so.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
package authors can and should support engine versions long after their vendors have stopped doing so
Ok, I guess. This seems like a very strange hill to die on to me, though. I think not alienating contributors and enabling a whole world of new use cases beats sacrificing your software on the altar of backwards compatibility. 🤷♂️
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For our team, this contribution would have made install-peerdeps
go from an unusable tool to something really useful!
Thanks for the contribution @amclin! We're looking forward to the day this can be released 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ljharb since you refuse to accept a backwards-breaking change, the responsibility is on you to fix master, so that contributions can be made.
Right now, no-one can contribute to this project because master is failing.
This PR is now 9 months old, because master is failing.
Even your automated security patches from Dependabot are not merging, because master is failing.
Fix master, and I'm happy to update this PR to reflect whatever changes you make to master. But no-one else is going to fix master for you, especially since you've made it clear you won't accept others' logical approaches to doing so.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's totally fair to hold off updating this PR until master is fixed, but if you had restored node 8 to the testing matrix, and the only failures on this PR were the same ones that were already in master, then I'd consider your PR ready to merge. This is a useful change, and I'd prefer to see it go in without disrupting existing users, and without needing to debate support philosophies.
0831778 should have fixed master, so I've rebased this PR (and restored node 8).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, but as-is, it's still a breaking change.
If we can preserve the -r
/-a
/-p
commands, and just render them unnecessary with the default behavior, then this is semver-minor.
-r, --registry <uri> Install from custom registry (defaults to NPM registry) | ||
-n, --no-registry Do not use a remote registry to find dependencies list | ||
--dry-run Do not install packages, but show the install command that will be run | ||
-a, --auth <token> Provide an NPM authToken for private packages. | ||
-p, --proxy <http_proxy> Enable http proxy to connect to the registry |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there a way we can keep this functionality? the default can (should) still be the behavior in this PR, and -n
is a good addition regardless.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not following, that's the point of this PR - remove the custom proxy logic that is unnecessary and doesn't work with many proxy configurations, offloading it to the package manager instead (see my comment on #72). If you have to deal with proxies, you are already having to deal with them in the package manager. Making users deal with them twice is unnecessary pain. I can't have the new behavior as default, while preserve the old behavior in a non-breaking way, because the old behavior was inconsistent with multiple behaviors hidden behind a single flag, (see #84).
Agreed that it's a breaking change and that's why it is flagged as such. Semantic-release should appropriately bump a major version number by design. For more explanation on the breaking change specifically, see #84, which is why I opened this as 2 PRs as this one depends on that one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gotcha, that makes sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, but should be coordinated with #84 as well.
Thank you, this is great! Will release this in v3. |
Just released v3.0.0! Available on NPM now too. |
feat: use package manager to find peerDependencies
Removes a bunch of custom logic and leverages the "info"
command that all package managers provide for getting package
details from a remote registry. By using the package tool, we can
delegate proxy configs, private registry paths, and auth tokens
to the package manager. This is especially valuable in networks
that require complex proxy configurations, or when packages
have peerDependencies that may be in multiple other private
than the singular one that was specified
BREAKING_CHANGE: removes
--registry
--auth
and--proxy
optionsUse
.npmrc
or.yarnrc
to mange private registry paths, auth tokens, and proxy configsThis also fixes the failing pnpm build matrix, allowing the dependabot setup to resume normal operations