deps: upgrade npm to 2.9.0 #1573
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
othiym23
added
the
npm
|
Patch works this time (ugh git) Whitespace errors, if you are curious. (doesn't really matter) briefly skimmed code. Tests ok. Note: there are now some new files updated when diff --git a/deps/npm/html/doc/cli/npm-link.html b/deps/npm/html/doc/cli/npm-link.html
index b863110..f3d38db 100644
--- a/deps/npm/html/doc/cli/npm-link.html
+++ b/deps/npm/html/doc/cli/npm-link.html
@@ -36,7 +36,7 @@ cd ~/projects/node-bloggy # go into some other package directory.
npm link redis # link-install the package
</code></pre><p>Now, any changes to ~/projects/node-redis will be reflected in
~/projects/node-bloggy/node_modules/node-redis/. Note that the link should
-be to the package name, not the directory name for that package. </p>
+be to the package name, not the directory name for that package.</p>
<p>You may also shortcut the two steps in one. For example, to do the
above use-case in a shorter way:</p>
<pre><code>cd ~/projects/node-bloggy # go into the dir of your main project
diff --git a/deps/npm/html/partial/doc/cli/npm-link.html b/deps/npm/html/partial/doc/cli/npm-link.html
index d25a640..1965f71 100644
--- a/deps/npm/html/partial/doc/cli/npm-link.html
+++ b/deps/npm/html/partial/doc/cli/npm-link.html
@@ -25,7 +25,7 @@ cd ~/projects/node-bloggy # go into some other package directory.
npm link redis # link-install the package
</code></pre><p>Now, any changes to ~/projects/node-redis will be reflected in
~/projects/node-bloggy/node_modules/node-redis/. Note that the link should
-be to the package name, not the directory name for that package. </p>
+be to the package name, not the directory name for that package.</p>
<p>You may also shortcut the two steps in one. For example, to do the
above use-case in a shorter way:</p>
<pre><code>cd ~/projects/node-bloggy # go into the dir of your main projectLGTM Though, no reason that I can tell this shouldn't make it into 2.0.0 (and maybe backport) |
|
Interesting. Those changes only appear to have happened once, the first time I ran it. Edit: looks like it also can occasionally happen on the version we currently have in... (2.8.3?) |
|
LGTM as well. +1 on backporting it to the v1.x line if @othiym23 thinks that's wise! |
|
I'm always going to be in favor of putting the latest npm in people's hands. I'll land this (after doing a rebase with `--whitespace=fix" and squashing) and then submit a separate PR on v1.x. |
PR-URL: nodejs#1573 Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> Reviewed-By: Chris Dickinson <christopher.s.dickinson@gmail.com>
Every npm version bump requires a few patches to be floated on node-gyp for io.js compatibility. These patches are found in 03d1992, 5de334c, and da730c7. This commit squashes them into a single commit. PR-URL: nodejs#990 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
On Windows, when node or io.js attempts to dynamically load a compiled
addon, the compiled addon tries to load node.exe or iojs.exe again -
depending on which import library the module used when it was linked.
This causes many compiled addons to break when node.exe or iojs.exe are
renamed, because when the binary has been renamed the addon DLL can't
find the (right) .exe file to load its imports from.
This patch gives compiled addon developers an option to overcome this
restriction by compiling a delay-load hook into their binary. The
delay-load hook ensures that whenever a module tries to load imports
from node.exe/iojs.exe, it'll just look at the process image, thereby
making the addon work regardless of what name the node/iojs binary has.
To enable this feature, the addon developer must set the
'win_delay_load_hook' option to 'true' in their binding.gyp file, like
this:
```
{
'targets': [
{
'target_name': 'ernie',
'win_delay_load_hook': 'true',
...
```
Bug: nodejs#751
Bug: nodejs#965
Upstream PR: nodejs/node-gyp#599
PR-URL: nodejs#1251
Reviewed-By: Rod Vagg <rod@vagg.org>
PR-URL: nodejs#1266
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
|
Yeah, we should backport until npm is upgradeable while running on io.js, after that, i'd say only merge the latest in before a maintenance / lts release. |
|
Annoyingly pedantic point: it's not really "backporting", it's still upgrading a dependency. npm is more or less agnostic to which version of Node it's run with, and depends on no features specific to the runtime version. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a replacement for #1515, and upgrades the npm in io.js to the new
latest. To work around the problems withgit applyand case-insensitive filesystems that make usinggit amwith the patch generated by GitHub for #1515 difficult, I've broken the PR into two commits. This is cheesy, and should be squashed before commit, but will does the job for review purposes.Here are the relevant changes:
npm@2.8.4npm@2.9.0I leave to the release manager and evangelism team to decide which bits are relevant for their respective publications, but will say that these releases are significantly smaller and simpler than the last few.
r: @Fishrock123
r: @chrisdickinson