This repository has been archived by the owner. It is now read-only.

Node. [Progress Tracking] #31777

Closed
DomT4 opened this Issue Aug 21, 2014 · 50 comments

Comments

Projects
None yet
@DomT4
Contributor

DomT4 commented Aug 21, 2014

In this issue I will document everything I can think of to fix the recently badly broken Node on OS X inside Homebrew.

Expect debug logs, musings, frustration and hopefully by the end, some kind of solution. Bear with me. Opening this up as an issue so people can kick in with suggestions and ideas, and to hopefully have one place to discuss all the Node issues rather than the multiple active open & closed Node issues.


  • Current Homebrew Node.rb Formula - Clicky.

Other recent Node/npm issues:

Success 1 - Node install after going through & removing all remnants of Node, including now-dead packages symlinked into /usr/local/bin with "find -L /usr/local/bin -type l -exec rm -i {} +".

I also did "rm /usr/local/share/man/man1/node.1" before the install, and "rm -r /usr/local/lib/node_modules" and "rm -r ~/.npm"

After all of this I did "chown -R YOURUSERNAME /usr/local".


Success 2, Over existing directories.

Brew Remove Node, Brew Cleanup, Brew Install Node. Deliberately didn't remove any existing Node directories from the first successful install. This was to see if Node was having permission issues overriding existing directories.


Success 3, Upgrading Versions

Installed Node 0.10.30 from a formula I had lying around, and then asked Brew to upgrade Node. Upgrade from 0.10.30 to 0.10.31 went successfully, without issue. I also installed the grunt package globally as a test. That worked fine too.


Success 4, Latest npm

Node 0.10.31 with a modified Homebrew formula that installed the latest npm that was previously causing issues. Build succeeded. Installed grunt globally as a test, worked fine.

@DomT4

This comment has been minimized.

Show comment Hide comment
@DomT4

DomT4 Aug 22, 2014

Contributor

Hey @jacknagel, @mistydemeo, @MikeMcQuaid, @adamv - I think I may have stumbled on a solution to the problem kicked up recently. I'd like a few others to test the steps written underneath Success 1 but if that works for multiple people I think that's the problem dealt with. Strangely, although I'm hesitant to definitively finger a particular file causing an error here, the man1/node.1 file consistently was the one screwing with the post install stage early on.

I think this problem breaks down into 3 parts:

  1. Npm packages are often symlinked into usr/local but there's no easy mechanism to clean up those symlinks if you remove Node. Even the Homebrew brew remove aspect doesn't seem to successfully yank everything out of /usr/local/bin from Node all of the time.

Homebrew is wildly better at it than if someone had previously installed Node from a .pkg and later removed all of the obvious components of it, but still, there are quite a few things that end up getting left behind. This seems to cause issues when npm looks for packages and finds symlinks to them but the symlinks go nowhere.

  1. Ownership of /usr/local has been well known for a while to cause issues with Node, particularly around requiring the use of sudo to execute installing anything globally. If we explicitly chown the directory to the user, it should and seems to annul the requirement for sudo as npm themselves have suggested.

  2. Brew remove Node doesn't remove the created directory at ~/.npm. That sticks around and can bork up installs.

I've managed a successful install with Node v0.10.29, 0.10.30 & 0.10.31 and the old version of npm we currently have in place, and the newest version of npm that we were having trouble with before. All worked fine, and all installed packages globally without sudo and without issue. I also did a brew upgrade between 0.10.30 to 0.10.31 to check the upgrade process and that succeeded without causing issue.

This fix obviously requires users to destroy their current Node installations, and that's a pain in the neck, but I think, if others can test and confirm, this should solve the Homebrew problem with Node.

Contributor

DomT4 commented Aug 22, 2014

Hey @jacknagel, @mistydemeo, @MikeMcQuaid, @adamv - I think I may have stumbled on a solution to the problem kicked up recently. I'd like a few others to test the steps written underneath Success 1 but if that works for multiple people I think that's the problem dealt with. Strangely, although I'm hesitant to definitively finger a particular file causing an error here, the man1/node.1 file consistently was the one screwing with the post install stage early on.

I think this problem breaks down into 3 parts:

  1. Npm packages are often symlinked into usr/local but there's no easy mechanism to clean up those symlinks if you remove Node. Even the Homebrew brew remove aspect doesn't seem to successfully yank everything out of /usr/local/bin from Node all of the time.

Homebrew is wildly better at it than if someone had previously installed Node from a .pkg and later removed all of the obvious components of it, but still, there are quite a few things that end up getting left behind. This seems to cause issues when npm looks for packages and finds symlinks to them but the symlinks go nowhere.

  1. Ownership of /usr/local has been well known for a while to cause issues with Node, particularly around requiring the use of sudo to execute installing anything globally. If we explicitly chown the directory to the user, it should and seems to annul the requirement for sudo as npm themselves have suggested.

  2. Brew remove Node doesn't remove the created directory at ~/.npm. That sticks around and can bork up installs.

I've managed a successful install with Node v0.10.29, 0.10.30 & 0.10.31 and the old version of npm we currently have in place, and the newest version of npm that we were having trouble with before. All worked fine, and all installed packages globally without sudo and without issue. I also did a brew upgrade between 0.10.30 to 0.10.31 to check the upgrade process and that succeeded without causing issue.

This fix obviously requires users to destroy their current Node installations, and that's a pain in the neck, but I think, if others can test and confirm, this should solve the Homebrew problem with Node.

@DomT4

This comment has been minimized.

Show comment Hide comment
@DomT4

DomT4 Aug 22, 2014

Contributor

If this works for others, I'll push an update for npm later today.

Contributor

DomT4 commented Aug 22, 2014

If this works for others, I'll push an update for npm later today.

@adamv

This comment has been minimized.

Show comment Hide comment
@adamv

adamv Aug 22, 2014

Contributor

Node (or npm?) should fix its sudo issue upstream; users should be able to have /usr/local owned by any user that doesn't otherwise cause problems on the system.

Contributor

adamv commented Aug 22, 2014

Node (or npm?) should fix its sudo issue upstream; users should be able to have /usr/local owned by any user that doesn't otherwise cause problems on the system.

@DomT4

This comment has been minimized.

Show comment Hide comment
@DomT4

DomT4 Aug 22, 2014

Contributor

The issue seems to be with npm. The Node team keep shoving similar issues over to npm. It has been suggested to them several times that this is a major issue, but they regularly instruct users to chown /usr/local which yes, is a pain if you aren't in a position to do that.

Contributor

DomT4 commented Aug 22, 2014

The issue seems to be with npm. The Node team keep shoving similar issues over to npm. It has been suggested to them several times that this is a major issue, but they regularly instruct users to chown /usr/local which yes, is a pain if you aren't in a position to do that.

@jacknagel

This comment has been minimized.

Show comment Hide comment
@jacknagel

jacknagel Aug 22, 2014

Contributor
  1. Npm packages are often symlinked into usr/local but there's no easy mechanism to clean up those symlinks if you remove Node. Even the Homebrew brew remove aspect doesn't seem to successfully yank everything out of /usr/local/bin from Node all of the time.

This is by design, so that one doesn't have to reinstall all of their npm packages each time they upgrade. We set the npm prefix to HOMEBREW_PREFIX here.

Contributor

jacknagel commented Aug 22, 2014

  1. Npm packages are often symlinked into usr/local but there's no easy mechanism to clean up those symlinks if you remove Node. Even the Homebrew brew remove aspect doesn't seem to successfully yank everything out of /usr/local/bin from Node all of the time.

This is by design, so that one doesn't have to reinstall all of their npm packages each time they upgrade. We set the npm prefix to HOMEBREW_PREFIX here.

@DomT4

This comment has been minimized.

Show comment Hide comment
@DomT4

DomT4 Aug 22, 2014

Contributor

Yes, and largely it's a good design, but if you actually want to remove Node for whatever reason it leaves behind these dregs of dead symlinks, which can upset npm if you then reinstall Node.

Contributor

DomT4 commented Aug 22, 2014

Yes, and largely it's a good design, but if you actually want to remove Node for whatever reason it leaves behind these dregs of dead symlinks, which can upset npm if you then reinstall Node.

@DomT4

This comment has been minimized.

Show comment Hide comment
@DomT4

DomT4 Aug 22, 2014

Contributor

Success 1 has one other success thus far, in issue #31774. That's 2/2 people its worked for so far, including me. Might try reaching out to a few of the other folks having Node issues and asking them to check whether this does the job for them. I'd like a relatively wide check ideally.

Contributor

DomT4 commented Aug 22, 2014

Success 1 has one other success thus far, in issue #31774. That's 2/2 people its worked for so far, including me. Might try reaching out to a few of the other folks having Node issues and asking them to check whether this does the job for them. I'd like a relatively wide check ideally.

@nacho-marin

This comment has been minimized.

Show comment Hide comment
@nacho-marin

nacho-marin Aug 22, 2014

I offer myself as a tester. I had NodeJS on OS X 10.9.4, installed after the instructions in nodejs.org (the sudo way, and so I did with npm). One of the programs that I need to use forced me to remove this installation and install using brew. I have tried the steps in Success 1 and Success 2 instructions, and also the indications from one of the npm developers (sudo rm -rf /usr/local/{bin/{node,npm},lib/node_modules/npm,lib/node,share/man//node.}) repeteadly.

Are there any steps that you recommend me to follow?

brew install node keeps failing with this output:

Homebrew 0.9.5
==> make install
rm -rf
.building_ronn
html/doc
html/api
man
scripts/doc-build.sh doc/api/npm-bin.md man/man3/npm-bin.3
node cli.js install ronn --no-global
bash: node: command not found
make[1]: *** [node_modules/.bin/ronn] Error 127
make: *** [man/man3/npm-bin.3] Error 2
==> Configuration
HOMEBREW_VERSION: 0.9.5
HEAD: 55f6060
CPU: quad-core 64-bit ivybridge
OS X: 10.9.4-x86_64
Xcode: 5.1.1
CLT: 5.1.0.0.1.1396320587
X11: 2.7.6 => /opt/X11
==> ENV
PATH: /Users/Nacho/.rvm/gems/ruby-2.1.2/bin:/Users/Nacho/.rvm/gems/ruby-2.1.2@global/bin:/Users/Nacho/.rvm/rubies/ruby-2.1.2/bin:/Users/Nacho/bin/Sencha/Cmd/4.0.4.84:/Users/Nacho/bin/Sencha/Cmd/4.0.3.74:/Users/Nacho/bin/Sencha/Cmd/4.0.2.67:/usr/local/mysql/bin:/Users/Nacho/Dropbox/AWS/API/ec2-api-tools-1.6.7.3/bin:/Users/Nacho/bin:/Users/Nacho/adt-bundle-mac-x86_64/sdk/tools:/Users/Nacho/adt-bundle-mac-x86_64/sdk/platform-tools:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/Applications/Server.app/Contents/ServerRoot/usr/bin:/Applications/Server.app/Contents/ServerRoot/usr/sbin:/Users/Nacho/.rvm/bin:/usr/local/Library/Contributions/cmd

Error: node 0.10.31 did not build
Logs:
/Users/Nacho/Library/Logs/Homebrew/node/01.make

I offer myself as a tester. I had NodeJS on OS X 10.9.4, installed after the instructions in nodejs.org (the sudo way, and so I did with npm). One of the programs that I need to use forced me to remove this installation and install using brew. I have tried the steps in Success 1 and Success 2 instructions, and also the indications from one of the npm developers (sudo rm -rf /usr/local/{bin/{node,npm},lib/node_modules/npm,lib/node,share/man//node.}) repeteadly.

Are there any steps that you recommend me to follow?

brew install node keeps failing with this output:

Homebrew 0.9.5
==> make install
rm -rf
.building_ronn
html/doc
html/api
man
scripts/doc-build.sh doc/api/npm-bin.md man/man3/npm-bin.3
node cli.js install ronn --no-global
bash: node: command not found
make[1]: *** [node_modules/.bin/ronn] Error 127
make: *** [man/man3/npm-bin.3] Error 2
==> Configuration
HOMEBREW_VERSION: 0.9.5
HEAD: 55f6060
CPU: quad-core 64-bit ivybridge
OS X: 10.9.4-x86_64
Xcode: 5.1.1
CLT: 5.1.0.0.1.1396320587
X11: 2.7.6 => /opt/X11
==> ENV
PATH: /Users/Nacho/.rvm/gems/ruby-2.1.2/bin:/Users/Nacho/.rvm/gems/ruby-2.1.2@global/bin:/Users/Nacho/.rvm/rubies/ruby-2.1.2/bin:/Users/Nacho/bin/Sencha/Cmd/4.0.4.84:/Users/Nacho/bin/Sencha/Cmd/4.0.3.74:/Users/Nacho/bin/Sencha/Cmd/4.0.2.67:/usr/local/mysql/bin:/Users/Nacho/Dropbox/AWS/API/ec2-api-tools-1.6.7.3/bin:/Users/Nacho/bin:/Users/Nacho/adt-bundle-mac-x86_64/sdk/tools:/Users/Nacho/adt-bundle-mac-x86_64/sdk/platform-tools:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/Applications/Server.app/Contents/ServerRoot/usr/bin:/Applications/Server.app/Contents/ServerRoot/usr/sbin:/Users/Nacho/.rvm/bin:/usr/local/Library/Contributions/cmd

Error: node 0.10.31 did not build
Logs:
/Users/Nacho/Library/Logs/Homebrew/node/01.make

@DomT4

This comment has been minimized.

Show comment Hide comment
@DomT4

DomT4 Aug 22, 2014

Contributor

Try rm -r /usr/local/lib/node_modules and rm /usr/local/share/man/man3/npm-*, and then do the standard brew remove node, brew install node -v.

Contributor

DomT4 commented Aug 22, 2014

Try rm -r /usr/local/lib/node_modules and rm /usr/local/share/man/man3/npm-*, and then do the standard brew remove node, brew install node -v.

@DomT4 DomT4 referenced this issue Aug 22, 2014

Closed

Node: npm bump #31799

BrewTestBot pushed a commit to BrewTestBot/homebrew that referenced this issue Aug 22, 2014

Dominyk Tiller BrewTestBot
Node: npm bump
Bumps npm back to the latest release. Hopefully [this
issue](Homebrew#31777) will allow
those still with issues to upgrade without issue.
@mattsilv

This comment has been minimized.

Show comment Hide comment
@mattsilv

mattsilv Aug 22, 2014

Success 1 solved the problem for me on OSX 10.9.4. I literally spent an hour try other help docs. After trying success 1, i ran Brew uninstall node --force. When i ran brew install node after that, it worked flawlessly for the first time in a long time :)

Success 1 solved the problem for me on OSX 10.9.4. I literally spent an hour try other help docs. After trying success 1, i ran Brew uninstall node --force. When i ran brew install node after that, it worked flawlessly for the first time in a long time :)

@DomT4

This comment has been minimized.

Show comment Hide comment
@DomT4

DomT4 Aug 22, 2014

Contributor

Awesome! Glad this helped you out as well. I will breathe a deep, deep sigh of relief if this solves the issue for most people. Node has been a complete pain lately.

(I love Node, but still, a complete pain).

Contributor

DomT4 commented Aug 22, 2014

Awesome! Glad this helped you out as well. I will breathe a deep, deep sigh of relief if this solves the issue for most people. Node has been a complete pain lately.

(I love Node, but still, a complete pain).

@nacho-marin

This comment has been minimized.

Show comment Hide comment
@nacho-marin

nacho-marin Aug 22, 2014

Same error for me after following your indications, Dom.The rm -r /usr/local/lib/node_modules and rm /usr/local/share/man/man3/npm-* recommended were already performed in the line suggested by isaacs, one of the npm developers. My log was a partial copy (the final part) of the log generated. I had noticed that there was a previous error:


==> Downloading https://downloads.sf.net/project/machomebrew/Bottles/node-0.10.31.mavericks.bottle.tar.gz
Already downloaded: /Library/Caches/Homebrew/node-0.10.31.mavericks.bottle.tar.gz
==> Verifying node-0.10.31.mavericks.bottle.tar.gz checksum
==> Pouring node-0.10.31.mavericks.bottle.tar.gz
tar xf /Library/Caches/Homebrew/node-0.10.31.mavericks.bottle.tar.gz
==> Caveats
Bash completion has been installed to:
/usr/local/etc/bash_completion.d
==> Finishing up
ln -s ../../Cellar/node/0.10.31/etc/bash_completion.d/npm npm
ln -s ../Cellar/node/0.10.31/bin/node node
rm /usr/local/bin/node
rm /usr/local/etc/bash_completion.d/npm
rmdir /usr/local/etc/bash_completion.d
Error: The brew link step did not complete successfully
The formula built, but is not symlinked into /usr/local
Could not symlink include/node/ares.h
Target /usr/local/include/node/ares.h
already exists. You may want to remove it:
rm /usr/local/include/node/ares.h

To force the link and overwrite all conflicting files:
brew link --overwrite node

To list all files that would be deleted:
brew link --overwrite --dry-run node

Possible conflicting files are:

[list of files in /usr/local/include/node]

So after my broken 'brew install node' I have made these things:

  1. brew remove node // Give brew the chance to do the job, then clean 'forgotten' files
  2. sudo rm -rf /usr/local/{bin/{node,npm},lib/node_modules/npm,lib/node,share/man//node.} // Perform the command recommended by https://github.com/isaacs
  3. find -L /usr/local/bin -type l -exec rm -i {} + ; rm -r /usr/local/lib/node_modules ; rm -r ~/.npm // i.e., follow Success 1
  4. rm -r /usr/local/include/node // to try to avoid the error in the log aforementioned -
  5. brew install node -v

Then same problem with /usr/local/lib/dtrace/node.d, so I repeated the 5 steps with step
4) rm -r /usr/local/include/node; /usr/local/lib/dtrace/node.d
and it worked....

I hope it can be helpful for someone out there ;-)

Same error for me after following your indications, Dom.The rm -r /usr/local/lib/node_modules and rm /usr/local/share/man/man3/npm-* recommended were already performed in the line suggested by isaacs, one of the npm developers. My log was a partial copy (the final part) of the log generated. I had noticed that there was a previous error:


==> Downloading https://downloads.sf.net/project/machomebrew/Bottles/node-0.10.31.mavericks.bottle.tar.gz
Already downloaded: /Library/Caches/Homebrew/node-0.10.31.mavericks.bottle.tar.gz
==> Verifying node-0.10.31.mavericks.bottle.tar.gz checksum
==> Pouring node-0.10.31.mavericks.bottle.tar.gz
tar xf /Library/Caches/Homebrew/node-0.10.31.mavericks.bottle.tar.gz
==> Caveats
Bash completion has been installed to:
/usr/local/etc/bash_completion.d
==> Finishing up
ln -s ../../Cellar/node/0.10.31/etc/bash_completion.d/npm npm
ln -s ../Cellar/node/0.10.31/bin/node node
rm /usr/local/bin/node
rm /usr/local/etc/bash_completion.d/npm
rmdir /usr/local/etc/bash_completion.d
Error: The brew link step did not complete successfully
The formula built, but is not symlinked into /usr/local
Could not symlink include/node/ares.h
Target /usr/local/include/node/ares.h
already exists. You may want to remove it:
rm /usr/local/include/node/ares.h

To force the link and overwrite all conflicting files:
brew link --overwrite node

To list all files that would be deleted:
brew link --overwrite --dry-run node

Possible conflicting files are:

[list of files in /usr/local/include/node]

So after my broken 'brew install node' I have made these things:

  1. brew remove node // Give brew the chance to do the job, then clean 'forgotten' files
  2. sudo rm -rf /usr/local/{bin/{node,npm},lib/node_modules/npm,lib/node,share/man//node.} // Perform the command recommended by https://github.com/isaacs
  3. find -L /usr/local/bin -type l -exec rm -i {} + ; rm -r /usr/local/lib/node_modules ; rm -r ~/.npm // i.e., follow Success 1
  4. rm -r /usr/local/include/node // to try to avoid the error in the log aforementioned -
  5. brew install node -v

Then same problem with /usr/local/lib/dtrace/node.d, so I repeated the 5 steps with step
4) rm -r /usr/local/include/node; /usr/local/lib/dtrace/node.d
and it worked....

I hope it can be helpful for someone out there ;-)

@DomT4

This comment has been minimized.

Show comment Hide comment
@DomT4

DomT4 Aug 23, 2014

Contributor

Seriously considering writing up a quick shell script that removes all remnants of Node & npm. It sinks its teeth into near everywhere and leaves so much clutter around. Success 1 seems to be doing the job for most people, but there are a few cases of people running into yet further Node remnants lying around and obstructing the install process.

Contributor

DomT4 commented Aug 23, 2014

Seriously considering writing up a quick shell script that removes all remnants of Node & npm. It sinks its teeth into near everywhere and leaves so much clutter around. Success 1 seems to be doing the job for most people, but there are a few cases of people running into yet further Node remnants lying around and obstructing the install process.

@DomT4

This comment has been minimized.

Show comment Hide comment
@DomT4

DomT4 Aug 24, 2014

Contributor

Okay. Shell script is done. Instructions are below, source is here if people want to check it out beforehand. The use of sudo is necessary to cover any one who has ever installed Node with the .pkg. It could be fairly easily adjusted for Homebrew if necessary though by removing the sudo. If the maintainers have an interest in that I'll tweak up another version.

It's written in bash and triggers bash automatically, so whatever shell you are using it should work for you. The script is deliberately methodical & will ask for your confirmation before proceeding initially, and then will ask for your confirmation again if it detects any dead symlinks to remove. You don't need to hit enter after answering y or n to the "Proceed?" question, it will automatically recognise that you've answered.

To use the script:

  • curl -O https://raw.githubusercontent.com/DomT4/scripts/master/OSX_Node_Removal/terminatenode.sh

Then:

  • chmod +x /path/to/terminatenode.sh

Then:

  • ./terminatenode.sh.
Contributor

DomT4 commented Aug 24, 2014

Okay. Shell script is done. Instructions are below, source is here if people want to check it out beforehand. The use of sudo is necessary to cover any one who has ever installed Node with the .pkg. It could be fairly easily adjusted for Homebrew if necessary though by removing the sudo. If the maintainers have an interest in that I'll tweak up another version.

It's written in bash and triggers bash automatically, so whatever shell you are using it should work for you. The script is deliberately methodical & will ask for your confirmation before proceeding initially, and then will ask for your confirmation again if it detects any dead symlinks to remove. You don't need to hit enter after answering y or n to the "Proceed?" question, it will automatically recognise that you've answered.

To use the script:

  • curl -O https://raw.githubusercontent.com/DomT4/scripts/master/OSX_Node_Removal/terminatenode.sh

Then:

  • chmod +x /path/to/terminatenode.sh

Then:

  • ./terminatenode.sh.
@DomT4

This comment has been minimized.

Show comment Hide comment
@DomT4

DomT4 Aug 24, 2014

Contributor

I've updated the script to cull another potentially troublesome directory, as reported here.

Contributor

DomT4 commented Aug 24, 2014

I've updated the script to cull another potentially troublesome directory, as reported here.

@ThePhen

This comment has been minimized.

Show comment Hide comment
@ThePhen

ThePhen Aug 26, 2014

Thx. DomT4. Your script and 'Success 1' worked like a charm on my borked Yosemite 10.10 Homebrew install of node & npm.

ThePhen commented Aug 26, 2014

Thx. DomT4. Your script and 'Success 1' worked like a charm on my borked Yosemite 10.10 Homebrew install of node & npm.

@DomT4

This comment has been minimized.

Show comment Hide comment
@DomT4

DomT4 Aug 26, 2014

Contributor

Awesome! Glad the script did the job for you.

I'm going to spend a little time later reviewing the Node Homebrew formula to see if there's anything we can weave into the formula to prevent this popping up in the future. Hopefully the script just becomes the temporary solution till we can find a non-destructive way for people to deal with previous Node installations lingering around.

Very relieved the script seems to be doing the job for everyone thus far though. I appreciate all the feedback.

Contributor

DomT4 commented Aug 26, 2014

Awesome! Glad the script did the job for you.

I'm going to spend a little time later reviewing the Node Homebrew formula to see if there's anything we can weave into the formula to prevent this popping up in the future. Hopefully the script just becomes the temporary solution till we can find a non-destructive way for people to deal with previous Node installations lingering around.

Very relieved the script seems to be doing the job for everyone thus far though. I appreciate all the feedback.

@mietek

This comment has been minimized.

Show comment Hide comment
@mietek

mietek Aug 26, 2014

Contributor

The node formula should not be doing a npm -g update npm on post_install. Currently, this results in the initially installed npm-1.4.9 being replaced with npm-2.0.0-beta.0.

According to @othiym23, there was a bug in npm before about 1.4.23 where npm -g update would ignore the latest distribution tag in favor of whatever version is newest. The newest npm beta has other bugs, leading to a brew upgrade breaking existing npm-based projects.

Contributor

mietek commented Aug 26, 2014

The node formula should not be doing a npm -g update npm on post_install. Currently, this results in the initially installed npm-1.4.9 being replaced with npm-2.0.0-beta.0.

According to @othiym23, there was a bug in npm before about 1.4.23 where npm -g update would ignore the latest distribution tag in favor of whatever version is newest. The newest npm beta has other bugs, leading to a brew upgrade breaking existing npm-based projects.

@DomT4

This comment has been minimized.

Show comment Hide comment
@DomT4

DomT4 Aug 26, 2014

Contributor

Yeah, that's a known issue. I'm going to look at seeing if I can scope the npm -g update npm post-install process to a specific npm version to get around the bug of accidentally shoving people onto the alpha/beta npm versions.

Contributor

DomT4 commented Aug 26, 2014

Yeah, that's a known issue. I'm going to look at seeing if I can scope the npm -g update npm post-install process to a specific npm version to get around the bug of accidentally shoving people onto the alpha/beta npm versions.

@othiym23

This comment has been minimized.

Show comment Hide comment
@othiym23

othiym23 Aug 26, 2014

The safe thing to do is to run npm install --global npm@latest. That will always get you the newest supported version of npm, regardless of what version of npm you're starting from.

The safe thing to do is to run npm install --global npm@latest. That will always get you the newest supported version of npm, regardless of what version of npm you're starting from.

@DomT4

This comment has been minimized.

Show comment Hide comment
@DomT4

DomT4 Aug 26, 2014

Contributor

@othiym23 Thanks! I'm just testing that through Homebrew now to make sure it doesn't bork inside the Homebrew sandbox, but providing it works alright I think that's the solution I'll push. Hopefully that should fix the npm issue at least, and then I can get to trying to figure out how to handle the other Node in Homebrew issues.

Contributor

DomT4 commented Aug 26, 2014

@othiym23 Thanks! I'm just testing that through Homebrew now to make sure it doesn't bork inside the Homebrew sandbox, but providing it works alright I think that's the solution I'll push. Hopefully that should fix the npm issue at least, and then I can get to trying to figure out how to handle the other Node in Homebrew issues.

BrewTestBot pushed a commit to BrewTestBot/homebrew that referenced this issue Aug 27, 2014

Dominyk Tiller BrewTestBot
Node: npm bump, devel killed, npm update change.
Okay, this is part 1 of what will likely become a host of wider changes
I propose on Node to tackle the issues discussed in
[#31777](Homebrew#31777).

Part 1: I’ve killed the devel build. It hasn’t been updated since May,
and Node haven’t expressed any sort of haste in issuing even a new
minor bump to the devel build that fixes the rather large [OpenSSL
vulnerabilities](https://github.com/joyent/node/tree/v0.11.13-release/de
ps/openssl/openssl) in 0.11.13. At this point, my feeling is that it’s
dangerously irresponsible to leave the devel build present given those
vulnerabilities, and I’d like to see us scrap it until we see some
movement on patching those issues. This issue is open with Node
[here](nodejs/node-v0.x-archive#8000) but remains largely
ignored and dormant.

Second change: Bumps the npm version that we ship back to the latest
stable release. A minor thing, but an early step towards fixing some of
the bigger npm problems.

Third change: Changes the way we handle npm updates post-install to
specifically target the latest stable release. Our current ``` npm
update npm -g ``` has been habitually dumping people onto the alpha &
beta builds for npm, and this solution (according to the npm team)
should solve that problem permanently. Having done local testing with
this, It does indeed seem to do the job.

These are largely minor fixes to patch things over in a stable, solid
fashion till I can work out ways to avoid the Node issues we’ve been
encountering so rampantly lately.
@MikeMcQuaid

This comment has been minimized.

Show comment Hide comment
@MikeMcQuaid

MikeMcQuaid Aug 27, 2014

Owner

@mietek @othiym23 In future please consider submitting pull requests to do the right thing instead of comments, thanks.

Owner

MikeMcQuaid commented Aug 27, 2014

@mietek @othiym23 In future please consider submitting pull requests to do the right thing instead of comments, thanks.

@tom--

This comment has been minimized.

Show comment Hide comment
@tom--

tom-- Aug 29, 2014

i had prefix = ${HOME}/.npm-packages in my .npmrc. deleting it resolved the install issues

tom-- commented Aug 29, 2014

i had prefix = ${HOME}/.npm-packages in my .npmrc. deleting it resolved the install issues

@maikdiepenbroek

This comment has been minimized.

Show comment Hide comment
@maikdiepenbroek

maikdiepenbroek Aug 30, 2014

Awesome, succes1 worked for me!

Awesome, succes1 worked for me!

MikeMcQuaid added a commit that referenced this issue Aug 31, 2014

node: npm bump, devel killed, npm update change.
Okay, this is part 1 of what will likely become a host of wider changes
I propose on Node to tackle the issues discussed in
[#31777](#31777).

Part 1: I’ve killed the devel build. It hasn’t been updated since May,
and Node haven’t expressed any sort of haste in issuing even a new
minor bump to the devel build that fixes the rather large [OpenSSL
vulnerabilities](https://github.com/joyent/node/tree/v0.11.13-release/de
ps/openssl/openssl) in 0.11.13. At this point, my feeling is that it’s
dangerously irresponsible to leave the devel build present given those
vulnerabilities, and I’d like to see us scrap it until we see some
movement on patching those issues. This issue is open with Node
[here](nodejs/node-v0.x-archive#8000) but remains largely
ignored and dormant.

Second change: Bumps the npm version that we ship back to the latest
stable release. A minor thing, but an early step towards fixing some of
the bigger npm problems.

Third change: Changes the way we handle npm updates post-install to
specifically target the latest stable release. Our current ``` npm
update npm -g ``` has been habitually dumping people onto the alpha &
beta builds for npm, and this solution (according to the npm team)
should solve that problem permanently. Having done local testing with
this, It does indeed seem to do the job.

These are largely minor fixes to patch things over in a stable, solid
fashion till I can work out ways to avoid the Node issues we’ve been
encountering so rampantly lately.
@DomT4

This comment has been minimized.

Show comment Hide comment
@DomT4

DomT4 Sep 4, 2014

Contributor

Oh oh. It's back. npm install -g npm (There's a new npm out) has managed to kill my Node installation. Sigh.

==> Reinstalling node
==> Downloading http://nodejs.org/dist/v0.10.31/node-v0.10.31.tar.gz
######################################################################## 100.0%
==> ./configure --prefix=/usr/local/Cellar/node/0.10.31 --without-npm
==> make install
==> Downloading https://registry.npmjs.org/npm/-/npm-1.4.24.tgz
######################################################################## 100.0%
Warning: The post-install step did not complete successfully
You can try again using `brew postinstall node`
Contributor

DomT4 commented Sep 4, 2014

Oh oh. It's back. npm install -g npm (There's a new npm out) has managed to kill my Node installation. Sigh.

==> Reinstalling node
==> Downloading http://nodejs.org/dist/v0.10.31/node-v0.10.31.tar.gz
######################################################################## 100.0%
==> ./configure --prefix=/usr/local/Cellar/node/0.10.31 --without-npm
==> make install
==> Downloading https://registry.npmjs.org/npm/-/npm-1.4.24.tgz
######################################################################## 100.0%
Warning: The post-install step did not complete successfully
You can try again using `brew postinstall node`
@MikeMcQuaid

This comment has been minimized.

Show comment Hide comment
@MikeMcQuaid

MikeMcQuaid Sep 4, 2014

Owner

@DomT4 Perhaps we should just stop running that in post_install.

Owner

MikeMcQuaid commented Sep 4, 2014

@DomT4 Perhaps we should just stop running that in post_install.

@homerjam

This comment has been minimized.

Show comment Hide comment
@homerjam

homerjam Sep 4, 2014

@DomT4 this worked for me:

$ sudo chown -R `whoami` ~/.npm

homerjam commented Sep 4, 2014

@DomT4 this worked for me:

$ sudo chown -R `whoami` ~/.npm
@DomT4

This comment has been minimized.

Show comment Hide comment
@DomT4

DomT4 Sep 4, 2014

Contributor

@MikeMcQuaid The problem seems to be that running npm install -g npm breaks Node completely, and obviously people are bound to run that command from time to time to update their npm versions (1.4.25 was released a couple days back). I'm not overly sure how to get around this particular issue 😕.

Contributor

DomT4 commented Sep 4, 2014

@MikeMcQuaid The problem seems to be that running npm install -g npm breaks Node completely, and obviously people are bound to run that command from time to time to update their npm versions (1.4.25 was released a couple days back). I'm not overly sure how to get around this particular issue 😕.

@MikeMcQuaid

This comment has been minimized.

Show comment Hide comment
@MikeMcQuaid

MikeMcQuaid Sep 4, 2014

Owner

How did/does it break Node?

Owner

MikeMcQuaid commented Sep 4, 2014

How did/does it break Node?

@DomT4

This comment has been minimized.

Show comment Hide comment
@DomT4

DomT4 Sep 4, 2014

Contributor

It bumped me back onto the beta npm over the stable, and then panicked, and then permissions errors kicked in.

I probably could have saved myself by running npm install --global npm@latest over npm install -g npm but the second is so familiar to me it trips off my fingers before my mind goes "Oh!".

Contributor

DomT4 commented Sep 4, 2014

It bumped me back onto the beta npm over the stable, and then panicked, and then permissions errors kicked in.

I probably could have saved myself by running npm install --global npm@latest over npm install -g npm but the second is so familiar to me it trips off my fingers before my mind goes "Oh!".

@MikeMcQuaid

This comment has been minimized.

Show comment Hide comment
@MikeMcQuaid

MikeMcQuaid Sep 4, 2014

Owner

Ah, ok, well at least we aren't running that exact invocation in post-install.

Owner

MikeMcQuaid commented Sep 4, 2014

Ah, ok, well at least we aren't running that exact invocation in post-install.

@DomT4

This comment has been minimized.

Show comment Hide comment
@DomT4

DomT4 Sep 4, 2014

Contributor

I'd really like upstream to kill off the npm install -g npm option all together, and move towards npm install --global npm@latest and npm install --global npm@beta and such as the default options. I don't know if that idea would gain any traction with them though.

Contributor

DomT4 commented Sep 4, 2014

I'd really like upstream to kill off the npm install -g npm option all together, and move towards npm install --global npm@latest and npm install --global npm@beta and such as the default options. I don't know if that idea would gain any traction with them though.

@MikeMcQuaid

This comment has been minimized.

Show comment Hide comment
@MikeMcQuaid

MikeMcQuaid Sep 4, 2014

Owner

Yeh, probably not. It's ok for now, upstream issue.

Owner

MikeMcQuaid commented Sep 4, 2014

Yeh, probably not. It's ok for now, upstream issue.

@DomT4

This comment has been minimized.

Show comment Hide comment
@DomT4

DomT4 Sep 4, 2014

Contributor

Yup. There's nothing we can do here to stop this happening, barring perhaps throwing a caveat in the formula reminding people when they update to do npm install --global npm@latest, but I'm not sure how much that would help, given I've probably been over the Node/npm formula a few hundred times and still forget not to do npm install -g npm.

Contributor

DomT4 commented Sep 4, 2014

Yup. There's nothing we can do here to stop this happening, barring perhaps throwing a caveat in the formula reminding people when they update to do npm install --global npm@latest, but I'm not sure how much that would help, given I've probably been over the Node/npm formula a few hundred times and still forget not to do npm install -g npm.

@othiym23

This comment has been minimized.

Show comment Hide comment
@othiym23

othiym23 Sep 4, 2014

I'd really like upstream to kill off the npm install -g npm option all together, and move towards npm install --global npm@latest and npm install --global npm@beta

  • npm -g == npm --global
  • npm -g install npm == npm -g install npm@latest for almost all versions of npm
  • npm@beta is not a thing, for reasons I've described elsewhere.
  • given npm's current weekly release schedule, it doesn't make sense to have Homebrew install npm@next – if people want that, they should update it themselves

If you want to autoupdate npm to what the npm team believes to be the latest stable version, npm -g install npm@latest is the command you want. We did have to roll latest back from npm@2.0.0-beta.0 to npm@1.4.25 this week, due to a nasty bug that breaks some packages with optional dependencies, but we're going to try to not make a habit of that.

othiym23 commented Sep 4, 2014

I'd really like upstream to kill off the npm install -g npm option all together, and move towards npm install --global npm@latest and npm install --global npm@beta

  • npm -g == npm --global
  • npm -g install npm == npm -g install npm@latest for almost all versions of npm
  • npm@beta is not a thing, for reasons I've described elsewhere.
  • given npm's current weekly release schedule, it doesn't make sense to have Homebrew install npm@next – if people want that, they should update it themselves

If you want to autoupdate npm to what the npm team believes to be the latest stable version, npm -g install npm@latest is the command you want. We did have to roll latest back from npm@2.0.0-beta.0 to npm@1.4.25 this week, due to a nasty bug that breaks some packages with optional dependencies, but we're going to try to not make a habit of that.

@othiym23

This comment has been minimized.

Show comment Hide comment
@othiym23

othiym23 Sep 4, 2014

And yes, moving away from npm update -g npm would be a really good idea. Depending on the version of npm installed at the start of that process, terrible things can happen to your install. npm update is really a tool for package developers more than npm end users.

othiym23 commented Sep 4, 2014

And yes, moving away from npm update -g npm would be a really good idea. Depending on the version of npm installed at the start of that process, terrible things can happen to your install. npm update is really a tool for package developers more than npm end users.

@DomT4

This comment has been minimized.

Show comment Hide comment
@DomT4

DomT4 Sep 4, 2014

Contributor

@othiym23 Yeah, I'm aware npm@beta isn't a thing right now, but I wasn't sure of the reasoning behind that. I'll check out the link you referenced. I know -g is --global but I wanted to stick the to the syntax you previously suggested aha.

Homebrew by default now no longer runs npm install -g npm as a post-install step, we moved to npm install --global npm@latest to avoid throwing people onto the beta builds accidentally. However, this doesn't stop users, me in this example, from sleepily bashing npm install -g npm into the Terminal and ending up on a beta by accident anyway. Sadly, we can't do much to eliminate end users making mistakes as to what command they use to update npm.

Contributor

DomT4 commented Sep 4, 2014

@othiym23 Yeah, I'm aware npm@beta isn't a thing right now, but I wasn't sure of the reasoning behind that. I'll check out the link you referenced. I know -g is --global but I wanted to stick the to the syntax you previously suggested aha.

Homebrew by default now no longer runs npm install -g npm as a post-install step, we moved to npm install --global npm@latest to avoid throwing people onto the beta builds accidentally. However, this doesn't stop users, me in this example, from sleepily bashing npm install -g npm into the Terminal and ending up on a beta by accident anyway. Sadly, we can't do much to eliminate end users making mistakes as to what command they use to update npm.

@DomT4

This comment has been minimized.

Show comment Hide comment
@DomT4

DomT4 Sep 4, 2014

Contributor

And npm update -g npm was a typo in my earlier post. I've corrected that now. We've never used that command inside Homebrew, to my knowledge.

Contributor

DomT4 commented Sep 4, 2014

And npm update -g npm was a typo in my earlier post. I've corrected that now. We've never used that command inside Homebrew, to my knowledge.

@joernhees

This comment has been minimized.

Show comment Hide comment
@joernhees

joernhees Sep 10, 2014

Contributor

For those still experiencing problems with a fresh install of node...

None of the mentioned and linked tricks helped me and it turns out that many of the problems are probably caused by the default registry just being unavailable. That would explain why many of the node issues end along the line "and then i re-ran all the above steps and it worked".

So should your brew postinstall node -v look like this and you find a line like

npm ERR! network getaddrinfo ENOTFOUND

then you should probably try switching the registry:

Create the file ~/.npmrc file with the following content:

registry = http://registry.npmjs.eu/

Afterwards re-run the brew postinstall node -v step.

I'm not sure if there is such a thing as "automatic mirror selection" for install npm and later installing packages with it... If there is maybe brew could trigger this step early?

Contributor

joernhees commented Sep 10, 2014

For those still experiencing problems with a fresh install of node...

None of the mentioned and linked tricks helped me and it turns out that many of the problems are probably caused by the default registry just being unavailable. That would explain why many of the node issues end along the line "and then i re-ran all the above steps and it worked".

So should your brew postinstall node -v look like this and you find a line like

npm ERR! network getaddrinfo ENOTFOUND

then you should probably try switching the registry:

Create the file ~/.npmrc file with the following content:

registry = http://registry.npmjs.eu/

Afterwards re-run the brew postinstall node -v step.

I'm not sure if there is such a thing as "automatic mirror selection" for install npm and later installing packages with it... If there is maybe brew could trigger this step early?

@DomT4

This comment has been minimized.

Show comment Hide comment
@DomT4

DomT4 Sep 10, 2014

Contributor

I presume Node has some sort of automatic mirror location grabbing. I touch the Amsterdam mirror, rather than any of the many many mirrors they have in the US, so they must have something in place. I suppose we could always touch a file in the Home directory if necessary - Does the default Non-Homebrew Node installer create a file there?

Edit - Nope. We don't like to touch otherwise redundant files, understandably. See Mike's comment below.

Contributor

DomT4 commented Sep 10, 2014

I presume Node has some sort of automatic mirror location grabbing. I touch the Amsterdam mirror, rather than any of the many many mirrors they have in the US, so they must have something in place. I suppose we could always touch a file in the Home directory if necessary - Does the default Non-Homebrew Node installer create a file there?

Edit - Nope. We don't like to touch otherwise redundant files, understandably. See Mike's comment below.

@MikeMcQuaid

This comment has been minimized.

Show comment Hide comment
@MikeMcQuaid

MikeMcQuaid Sep 10, 2014

Owner

I suppose we could always touch a file in the Home directory if necessary

Homebrew doesn't do stuff like that.

It really shouldn't be necessary to set this in an .npmrc file; I suspect this is an issue with your local internet connection or local mirror.

Owner

MikeMcQuaid commented Sep 10, 2014

I suppose we could always touch a file in the Home directory if necessary

Homebrew doesn't do stuff like that.

It really shouldn't be necessary to set this in an .npmrc file; I suspect this is an issue with your local internet connection or local mirror.

@DomT4

This comment has been minimized.

Show comment Hide comment
@DomT4

DomT4 Sep 10, 2014

Contributor

Yeah, I noticed. Was only throwing the thought out there largely if it's something the default install creates. (Which from memory, I can't seem to remember it doing so. Anyone else?). But theoretically, if it's something the default install creates we should be getting it automatically too, unless it has to be triggered by a specific compile option, which would be peculiar. So I can't imagine that file isn't being created if it needs to be. Like Mercurial perhaps the config file stashed in the Home directory is a personal user creation preference.

But yes, I'm almost certain Node hits up your IP address and picks the closest mirror possible, so @joernhees's issue shouldn't be widespread. I presume that if it can't reach a particular mirror it hunts out another, but I'm afraid that is something people would need to query with upstream.

Contributor

DomT4 commented Sep 10, 2014

Yeah, I noticed. Was only throwing the thought out there largely if it's something the default install creates. (Which from memory, I can't seem to remember it doing so. Anyone else?). But theoretically, if it's something the default install creates we should be getting it automatically too, unless it has to be triggered by a specific compile option, which would be peculiar. So I can't imagine that file isn't being created if it needs to be. Like Mercurial perhaps the config file stashed in the Home directory is a personal user creation preference.

But yes, I'm almost certain Node hits up your IP address and picks the closest mirror possible, so @joernhees's issue shouldn't be widespread. I presume that if it can't reach a particular mirror it hunts out another, but I'm afraid that is something people would need to query with upstream.

@joernhees

This comment has been minimized.

Show comment Hide comment
@joernhees

joernhees Sep 10, 2014

Contributor

sorry, didn't want to steer this issue away from its intent... i just wanted to report that some of "all the bugs" could actually be mirror reliability problems. If or how to counteract this is probably for some npm guru (not me) to decide.

@MikeMcQuaid @DomT4 well, i'm on a university connection in Germany. As the universities are connected via the DFN this would mean that most people in university networks in Germany have that problem.

If at all (and there isn't something in npm already that failed for me) I agree that setting this in ~/.npmrc is maybe the wrong approach as the user might use that location for own settings. Maybe /usr/local/lib/node_modules/npm/.npmrc.

Contributor

joernhees commented Sep 10, 2014

sorry, didn't want to steer this issue away from its intent... i just wanted to report that some of "all the bugs" could actually be mirror reliability problems. If or how to counteract this is probably for some npm guru (not me) to decide.

@MikeMcQuaid @DomT4 well, i'm on a university connection in Germany. As the universities are connected via the DFN this would mean that most people in university networks in Germany have that problem.

If at all (and there isn't something in npm already that failed for me) I agree that setting this in ~/.npmrc is maybe the wrong approach as the user might use that location for own settings. Maybe /usr/local/lib/node_modules/npm/.npmrc.

@DomT4

This comment has been minimized.

Show comment Hide comment
@DomT4

DomT4 Sep 10, 2014

Contributor

@joernhees If most people at your university are having trouble with Node/Npm I would most definitely upstream those concerns. Unless Node explicitly say "Yes, this is a mirror problem which can be fixed by doing x" Homebrew will probably be reluctant to start patching things where upstream is in a vastly better position to do so, especially since presumably if we slap registry = http://registry.npmjs.eu/ in every .npmrc we're likely to get some very irate Americans & Canadians here.

We do actually create /usr/local/lib/node_modules/npm/.npmrc already. It's part of the default install, and should read something like:

save-prefix = ~
proprietary-attribs = false

If it needs more than that, one would hope upstream would issue a fix.

Contributor

DomT4 commented Sep 10, 2014

@joernhees If most people at your university are having trouble with Node/Npm I would most definitely upstream those concerns. Unless Node explicitly say "Yes, this is a mirror problem which can be fixed by doing x" Homebrew will probably be reluctant to start patching things where upstream is in a vastly better position to do so, especially since presumably if we slap registry = http://registry.npmjs.eu/ in every .npmrc we're likely to get some very irate Americans & Canadians here.

We do actually create /usr/local/lib/node_modules/npm/.npmrc already. It's part of the default install, and should read something like:

save-prefix = ~
proprietary-attribs = false

If it needs more than that, one would hope upstream would issue a fix.

@othiym23

This comment has been minimized.

Show comment Hide comment
@othiym23

othiym23 Sep 10, 2014

Since npm's registry is fronted by a CDN, it should not ever be necessary for end users to switch to a mirror. There are several CDN nodes in Europe (although unfortunately, for whatever reason, the node in Frankfurt tends to be a little flaky, which might explain your intermittent issues, @joernhees). Putting the registry behind a CDN is a different architecture than having a "mirror network", and it doesn't make sense to have Homebrew trying to autoselect from mirrors.

To wit: npm doesn't maintain npmjs.eu, but my understanding from talking to @mmalecki is that he's considering sunsetting it. It uses registry-static, which is a pretty good piece of software, but occasionally it falls out of sync with the master registry, and as Maciej maintains registry.npmjs.eu in his spare time, it's not getting the same kind of operational attention that registry.npmjs.com is.

Since npm's registry is fronted by a CDN, it should not ever be necessary for end users to switch to a mirror. There are several CDN nodes in Europe (although unfortunately, for whatever reason, the node in Frankfurt tends to be a little flaky, which might explain your intermittent issues, @joernhees). Putting the registry behind a CDN is a different architecture than having a "mirror network", and it doesn't make sense to have Homebrew trying to autoselect from mirrors.

To wit: npm doesn't maintain npmjs.eu, but my understanding from talking to @mmalecki is that he's considering sunsetting it. It uses registry-static, which is a pretty good piece of software, but occasionally it falls out of sync with the master registry, and as Maciej maintains registry.npmjs.eu in his spare time, it's not getting the same kind of operational attention that registry.npmjs.com is.

@othiym23

This comment has been minimized.

Show comment Hide comment
@othiym23

othiym23 Sep 10, 2014

@DomT4

We do actually create /usr/local/lib/node_modules/npm/.npmrc already. It's part of the default install, and should read something like:

save-prefix = ~
proprietary-attribs = false

If it needs more than that, one would hope upstream would issue a fix.

Homebrew deciding on its own custom configuration is a bad idea. I'm very uncomfortable with Homebrew making decisions about default configuration properties that are different from what the mainline distribution of npm is doing. This is part of the reason why we've discouraged people from using Homebrew to install npm in the past.

@DomT4

We do actually create /usr/local/lib/node_modules/npm/.npmrc already. It's part of the default install, and should read something like:

save-prefix = ~
proprietary-attribs = false

If it needs more than that, one would hope upstream would issue a fix.

Homebrew deciding on its own custom configuration is a bad idea. I'm very uncomfortable with Homebrew making decisions about default configuration properties that are different from what the mainline distribution of npm is doing. This is part of the reason why we've discouraged people from using Homebrew to install npm in the past.

@DomT4

This comment has been minimized.

Show comment Hide comment
@DomT4

DomT4 Sep 10, 2014

Contributor

@othiym23 I think you misunderstood my point. By

We do actually create /usr/local/lib/node_modules/npm/.npmrc already

I meant one of those files is created during the install process of npm. If that file isn't meant to be created, it's an upstream issue. We don't create any new config files for Node in Homebrew.

Contributor

DomT4 commented Sep 10, 2014

@othiym23 I think you misunderstood my point. By

We do actually create /usr/local/lib/node_modules/npm/.npmrc already

I meant one of those files is created during the install process of npm. If that file isn't meant to be created, it's an upstream issue. We don't create any new config files for Node in Homebrew.

@othiym23

This comment has been minimized.

Show comment Hide comment
@othiym23

othiym23 Sep 11, 2014

@DomT4

I think you misunderstood my point

My apologies, I see that now.

Be aware that that's the .npmrc for npm itself (i.e. used by npm developers), not the defaults that get applied for users of npm (see the docs for details on how that configuration is set up).

@DomT4

I think you misunderstood my point

My apologies, I see that now.

Be aware that that's the .npmrc for npm itself (i.e. used by npm developers), not the defaults that get applied for users of npm (see the docs for details on how that configuration is set up).

@jacknagel

This comment has been minimized.

Show comment Hide comment
@jacknagel

jacknagel Sep 21, 2014

Contributor

Are there any outstanding issues here?

Contributor

jacknagel commented Sep 21, 2014

Are there any outstanding issues here?

@DomT4

This comment has been minimized.

Show comment Hide comment
@DomT4

DomT4 Sep 21, 2014

Contributor

None that we can resolve.

There's a few things I'd like to do but aren't really possible inside Homebrew.

I've been pondering adding a stronger caveat to the formula that people should absolutely completely never ever ever run 'npm upgrade -g npm' despite that being the way to upgrade other Node 'formula', but I'm Eh on how effective a stronger caveat would be.

This can be closed though. Anyone having issues after this should be able to find this thread again easily enough.

Sent from my iPhone

On 21 Sep 2014, at 08:28, Jack Nagel notifications@github.com wrote:

Are there any outstanding issues here?


Reply to this email directly or view it on GitHub.

Contributor

DomT4 commented Sep 21, 2014

None that we can resolve.

There's a few things I'd like to do but aren't really possible inside Homebrew.

I've been pondering adding a stronger caveat to the formula that people should absolutely completely never ever ever run 'npm upgrade -g npm' despite that being the way to upgrade other Node 'formula', but I'm Eh on how effective a stronger caveat would be.

This can be closed though. Anyone having issues after this should be able to find this thread again easily enough.

Sent from my iPhone

On 21 Sep 2014, at 08:28, Jack Nagel notifications@github.com wrote:

Are there any outstanding issues here?


Reply to this email directly or view it on GitHub.

@jacknagel jacknagel closed this Sep 21, 2014

@DomT4 DomT4 referenced this issue Oct 8, 2014

Closed

Node: Npm bump #33017

BrewTestBot pushed a commit to BrewTestBot/homebrew that referenced this issue Oct 8, 2014

Node: Npm bump
I’d like us to consider changing the way we handle npm inside of Node.
Currently, we generally only touch the npm version with each Node
release, but this behaviour contributed a little towards some of the
issues discussed in #31777, because npm releases are outpacing Node
releases considerably.

I’d like us to consider bumping the shipped npm version every 3 minor
releases (1.4.24 to 1.4.27) or every 1 major release (1.4.24 to 2.0.0),
and revisioning the formula to nudge users onto that npm bump.

Rationale:

1) It’ll make debugging less of a pain in the neck, by reducing the
vast environmental variable we currently have between Dave never
updating his npm install, and Sandra constantly updating her npm
install, and anything in-between.

2) It creates less room for things to go wrong towards the end of the
install. A jump of a few versions is generally a lot smoother than a
larger jump. It also means if we do start seeing issues we know it’s
something in a relatively short, fairly-defined timeframe. (Roughly,
this change would ensure that nobody is using npm code older than 5
weeks). This also makes for (marginally) quicker installs for users as
it shortens the npm stage a tiny touch.

3) We’re already adhering to the decision to bump users onto the latest
npm release with each new install, and this roughly follows the same
idea that we want to ensure users are using the newer npm versions.

Potential issues:

1) Theoretically, this could cause #31777 to flare back up more
regularly than it did. I consider this a very low-change risk, based
primarily on bullying the heck out of my system with successive npm
upgrades in this manner over the last two weeks without issues.

2) It’s a wee bit more of a pain for users to have to upgrade Node
every 5 weeks than every 2 or 3 months.

3) It makes the Node formula a little more high maintenance for the
maintainers or me or Bob or Sandra or Dave who propose PRs on this
subject to keep track of npm releases and handle the testing and
revision process. Happy to sacrifice myself for this.

Ultimately, I’ll pass the decision on this over to the maintainers and
their greater knowledge. This is something that has been on my mind &
radar for a while now, but I wholly accept this could be something the
maintainers decide to pass on.

BrewTestBot pushed a commit to BrewTestBot/homebrew that referenced this issue Oct 9, 2014

Node: Npm bump
I’d like us to consider changing the way we handle npm inside of Node.
Currently, we generally only touch the npm version with each Node
release, but this behaviour contributed a little towards some of the
issues discussed in #31777, because npm releases are outpacing Node
releases considerably.

I’d like us to consider bumping the shipped npm version every 3 minor
releases (1.4.24 to 1.4.27) or every 1 major release (1.4.24 to 2.0.0),
and revisioning the formula to nudge users onto that npm bump.

Rationale:

1) It’ll make debugging less of a pain in the neck, by reducing the
vast environmental variable we currently have between Dave never
updating his npm install, and Sandra constantly updating her npm
install, and anything in-between.

2) It creates less room for things to go wrong towards the end of the
install. A jump of a few versions is generally a lot smoother than a
larger jump. It also means if we do start seeing issues we know it’s
something in a relatively short, fairly-defined timeframe. (Roughly,
this change would ensure that nobody is using npm code older than 5
weeks). This also makes for (marginally) quicker installs for users as
it shortens the npm stage a tiny touch.

3) We’re already adhering to the decision to bump users onto the latest
npm release with each new install, and this roughly follows the same
idea that we want to ensure users are using the newer npm versions.

Potential issues:

1) Theoretically, this could cause #31777 to flare back up more
regularly than it did. I consider this a very low-change risk, based
primarily on bullying the heck out of my system with successive npm
upgrades in this manner over the last two weeks without issues.

2) It’s a wee bit more of a pain for users to have to upgrade Node
every 5 weeks than every 2 or 3 months.

3) It makes the Node formula a little more high maintenance for the
maintainers or me or Bob or Sandra or Dave who propose PRs on this
subject to keep track of npm releases and handle the testing and
revision process. Happy to sacrifice myself for this.

Ultimately, I’ll pass the decision on this over to the maintainers and
their greater knowledge. This is something that has been on my mind &
radar for a while now, but I wholly accept this could be something the
maintainers decide to pass on.

@xu-cheng xu-cheng locked and limited conversation to collaborators Feb 17, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.