cc8376ae67
PR-URL: https://github.com/iojs/io.js/pull/1390 Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
136 KiB
v2.7.6 (2015-04-02):
GIT MEAN, GIT TUFF, GIT ALL THE WAY AWAY FROM MY STUFF
Part of the reason that we're reluctant to take patches to how npm deals with
git dependencies is that every time we touch the git support, something breaks.
The last few releases are a case in point. npm@2.7.4 completely broke
installing private modules from GitHub, and npm@2.7.5 fixed them at the cost
of logging a misleading error message that caused many people to believe that
their dependencies hadn't been successfully installed when they actually had
been.
This all started from a desire to ensure that GitHub shortcut syntax is being
handled correctly. The correct behavior is for npm to try to clone all
dependencies on GitHub (whether they're specified with the GitHub
organization/repository shortcut syntax or not) via the plain git: protocol
first, and to fall back to using git+ssh: if git: doesn't work. Previously,
sometimes npm would use git: and git+ssh: in some cases (most notably when
using GitHub shortcut syntax on the command line), and use git+https: in
others (when the GitHub shortcut syntax was present in package.json). This
led to subtle and hard-to-understand inconsistencies, and we're glad that as of
npm@2.7.6, we've finally gotten things to where they were before we started,
only slightly more consistent overall.
We are now going to go back to our policy of being extremely reluctant to touch the code that handles Git dependencies.
b747593#7630 Don't automatically log all git failures as errors.maybeGithubneeds to be able to fail without logging to support its fallback logic. (@othiym23)cd67a0d#7829 When fetching a git remote URL, handle failures gracefully (without assuming standard output exists). (@othiym23)637c7d1#7829 When fetching a git remote URL, handle failures gracefully (without assuming standard error exists). (@othiym23)