Earlier quoted context omitted.
`sudo npm install -g` is one of several examples of the normalization of deviance rife in the NodeJS community. Most command-line utilities distributed through NPM recommend running as root (implicitly—because they all suggest installing it as a global package). Here's[1] Microsoft's instructions to install the TypeScript compiler, for example. NPM's awfulness notwithstanding, it's trivial to write a shell script to…
~/bin is not in the PATH for many systems. So, if you want beginners to be able to use your program, you'd have to provide instructions on how to change the PATH on each platform that requires it. Then you have to hope that they don't accidentally screw anything up in their profile scripts while making the changes, as I did back when I was new to Linux. It's extra-frustrating writing those instructions, because not o…
Do not use NPM 5.7
101–110 of 233 posts
Re: Do not use NPM 5.7
#102Re: Do not use NPM 5.7
#103Earlier quoted context omitted.
I'm mostly a Windows user, so maybe I'm misunderstanding *nix stuff here, but I don't see how recommending npm i -g package is remotely the same as recommending sudo npm. Could you clarify?
On Linux you can’t install globally without sudo. Unlike on Windows global means system global, not user-global. Such a thing does simply not exist for Linux’s npm. If they fixed that, 99% of these issues would go away. This is actually an example of something from the node universe working better on Windows.
thats not right. you've just got npm setup wrong. https://docs.npmjs.com/getting-started/fixing-npm-permission...
Re: Do not use NPM 5.7
#104If you are reading this: You are doing great work, I wish you the energy and strength to ignore the trolls.
Re: Do not use NPM 5.7
#105I just can't feel sorry for folks when I see comments like this one: > This destroyed 3 production server after a single deploy! I do think that the developers have a duty to do some testing of their software before putting out releases/updates. However, users also have a duty to perform sufficient testing before they push new versions to their production environments. In my opinion, it's kinda like losing data becau…
You have a responsibility to test before releasing to production, yes. But the amount of fucked up your program has to be for `sudo ___ --help` to wreck the operating system, the unexpectedness of that result... IMO attention should be focused here on the irresponsibility of the npm team, not their users.
Re: Do not use NPM 5.7
#106Earlier quoted context omitted.
The real fix is to not run npm with sudo. Why would you do that in the first place? npm runs install-scripts when you fetch packages, so you basically open up root access for all the packages you download.
How is this different than running apt or yum or pacman or most other package managers as sudo? Somebody has to install system software.
npm is basically a giant array that anyone can add package to.
I'm using them both accordingly.
Re: Do not use NPM 5.7
#107Re: Do not use NPM 5.7
#108Earlier quoted context omitted.
> It is not expected that updating npm will kill the complete system it is on... Yeah, but that is why you test your deployments BEFORE deploying them. Hell would be had had any developer at my company ran any such command on a production sever. The notion of even running a command at the terminal on a production server is even scary. Things like should be done on build servers which are in general throwaway. Your bu…
This response annoys me, because it's essentially victim-blaming. Yes, ideally you have some automation and staging in your server setup. We're grown-ups. We understand this. But it ignores many other dangerous possibilities here. Not everyone is blessed with working in a mature, well-funded environment full of experts. Maybe we're talking about a new or small organisation that simply doesn't have the resources and/o…
But lets take a closer look at your comments.
> Not everyone is blessed with working in a mature, well-funded environment full of experts. Maybe we're talking about a new or small organisation that simply doesn't have the resources and/or knowledge to isolate things with containers or VMs and related admin tools.
These are not excuses to knowing your trade. And the size and funding of your environment should not stop you from practicing your trade well.
> Maybe even taking out a staging server is still going to waste significant time resetting everything, blocking other development/deployment jobs in the meantime.
I fundamentally disagree. Having a stating environment will always cut cost and can't EVER be considered to "waste significant time". It can only save time and improve your product. Its these types of attitudes that result in your service going down and lost of real revenue and ultimately the failure of the project. Taking time to setup proper staging environments always pays back in spades.
> Maybe we're not talking about a server at all, but a developer's personal development workstation where they just use NPM to install a few Node-based tools.
Yeah, maybe we are talking about a developers personal station, nope, we are talking about production servers. Nuking a developers station is not even on the same scale as nuking a production system. And had somebody complained about nuking their dev environment my reply would have been about not running tools as root.
> Maybe we're not talking about a server at all, but a developer's personal development workstation where they just use NPM to install a few Node-based tools.
Again, I am okay with a developers system being nuked, at least it was not production!
> It's all very well saying npm shouldn't be run on production servers, but that doesn't really address the fundamental problem. Do we also ban system package managers, and say the only way to deploy anything is via some sort of imaging tool? What if there's an equivalent screw-up in that orchestration tool and it bricks all 100 servers at once?
I would not advise running system package managers on production servers either -- not unless your staging environment had passed such test first. But that being said I am a big fan of fresh install and migrate -- where the migration code is something I own and can test to ensure it works before using it. If you have 100 servers then you should have the resources to handle setting up testing environments to ensure your production rolls out. You should also not update 100 servers at the same time.
Production is production is production is production is production! You don't run things the first time ever in production. If you want your product, company whatever to succeeded then there really is NO excuse for you not to have good practices when building and deploying software. You can come up with 2^64 what if's but if you are running something that for the first time and it nukes your system you are at fault. Things like testing environments or staging environments were created to just dream about, and talk about when things go bad with deploying directly to production. These things came about because they bring real value to a project. The notion that these things are a waste, or cost too much just non-since.
Anybody in this industry of deploying software to servers needs to stand-up to these ideas that these good practices are too costly. These are the ideas and notions I expect from executive teams who have never coded a line of code, the accountants trying to save money, and managers who only care about the next quarter. I don't expect to find these ideas on sites like HN or from peers in the industry, but when I do I think it is important to take a hard line and not allow the notion of bad programming, and deployment practices to be unmet with rebuke for fear of hurting somebodies feelings. So while I clearly towed a hard line in this reply Silhouette, please do not take this as a personal rebuke or attack at you. I am upset with the ideas, and the notion hat we have to settle for less, and have results like production servers falling on their face when we as a industry already know the answers to the problem, and have the solutions to minimize downtime and provide truly awesome software to others.
Re: Do not use NPM 5.7
#109Re: Do not use NPM 5.7
#110I just can't feel sorry for folks when I see comments like this one: > This destroyed 3 production server after a single deploy! I do think that the developers have a duty to do some testing of their software before putting out releases/updates. However, users also have a duty to perform sufficient testing before they push new versions to their production environments. In my opinion, it's kinda like losing data becau…
I am the one who reported this ;) In fact that was a single production server that I tried to reinstall 3 times before catching it was not really one of the commits that was doing this. No data was lost or connectivity (as long as you do not reboot it), you just lose any ssh connection/login. Should I have done this on a staging server? Sure, but that does not change the fact that I would have had to rebuild the whol…
chef-client -z -r 'my-cookbook::npm_web_server'
Obviously the behavior of NPM absolutely sucks and is a total mess here, but "I had to rebuild the server", in 2018, is not nearly the material complaint it was a decade ago.The tradeoff of using rapidly-evolving tools with minimal oversight from the people creating them is that sometimes stuff blows up and not even always for good reasons. It is incumbent upon you, as the recipient of this enormous, jaw-dropping raft of free stuff that occasionally explodes, to write code and operate your systems defensively. Part of which is implementing those systems to be repeatable and quickly reinstantiated.
If you do not like this tradeoff, you have other options as well.