Do not use NPM 5.7 • Hacker News Board

Re: Do not use NPM 5.7

#201

Post by slrz » Fri, Feb 23, 2018, 6:28 AM UTC

Silhouette wrote: post #67

vetinari wrote: post #56

Earlier quoted context omitted.

> For one thing, package managers are only useful on packages supplied by the distro (or otherwise bundled using that convention), and we need something that allows for installing (and uninstalling, and backing up configurations for, and...) software safely and systematically in the general case. There's nothing that limits rpm/deb to distribution. Anyone who publishes a tarball with software, can publish rpm/deb as…

There's nothing that limits rpm/deb to distribution. Anyone who publishes a tarball with software, can publish rpm/deb as well. Many do. Hence my "or otherwise bundled..." note. But you're still only thinking in terms of packages that are bundled and installed via the system tool. Anything not installed via that tool can typically do whatever it wants if its scripts run as root, and anything that is installed via tha…

If you assume that conventions don't work as people will just run whatever crap as root, I don't think you can solve the problem without taking away that right from the user (as is customary on mobile devices).

At that point, solving the problem comes at too high a cost. A few messed up npm installs seem to be the lesser evil here.

Re: Do not use NPM 5.7

#202

Post by tachyoff » Fri, Feb 23, 2018, 6:40 AM UTC

foepys wrote: post #24

Apart from being a horrific bug, why are people running npm as root? Why don't they install it somewhere below $HOME and modify $PATH? npm is working fine without root permissions. Everything is super dangerous as root, one should avoid using root at all costs until there is no other way.

I know a lot of inexperienced devs who run things as root to try to fix problems. It’s the first thing some of them do (after restarting). I think it’s a lack of awareness due to missing knowledge. When you don’t know much about how your system works, you can’t effectively troubleshoot it.

Re: Do not use NPM 5.7

#203

Post by mundanevoice » Fri, Feb 23, 2018, 6:41 AM UTC

felixfbecker wrote: post #188

mundanevoice wrote: post #162

Earlier quoted context omitted.

The quality of what's being delivered since version 5 leaves a lot to be desired. They should really more people to their team and someone better since a lot of people depend on this code. Also, what's up them not understanding how semver works and releasing a pre-release code as the regular version. That's pretty basic man and rarely someone is OSS fucks up this badly actually.

dist-tags/release channels are far superior to classic semver pre-releases. What is the difference between an unstable and a stable version? Testing by users. So as soon as enough users have tested / enough time has passed without issues, an unstable release becomes stable. In the best case nothing about the code needs to change, the release just needs to be promoted to the stable channel / dist-tag. That is pretty c…

I agree with most of what you said.

> That is pretty common practice for a lot of software and especially packages on npm.

This is mostly what I have a problem with. Almost everyone is other ecosystems do not do something like this and there is a very good reason for it. Why not just follow a known and standard process of releasing things. https://twitter.com/maybekatz/status/966730802187792386

Even the NPM dev acknowledge the current process to be faulty and are considering switching to use pre-release tags.

Re: Do not use NPM 5.7

#204

Post by piva00 » Fri, Feb 23, 2018, 8:04 AM UTC

diggan wrote: post #93

zaarn wrote: post #43

Earlier quoted context omitted.

I think the easy solution here would be to disable global installs. Pip does that same stuff and it also is known to get people's computers into quite advanced states. Ideally npm should simply setup a dedicated directory in /opt or /usr/local/ (ie, /usr/local/node/bin or /opt/node/bin) in which it dumps all the global stuff. That way you can easily set permissions for a user and/or contain any damages to that folder…

> easy solution here would be to disable global installs I think that's not optimal. Having package being installed "globally" (as in available on your PATH) is nice. You can install `yarn` by doing `npm install --global yarn`. The trouble is how people setup their node/npm installation. Instead of having global packages setup under the home directory, people use the default which requires root access. Instead, defau…

I don't get what is the issue on requiring a "global" installation to be added to $PATH, a lot of other tools ask for that during installation and it's by far the safest way to do it.

Re: Do not use NPM 5.7

#205

Post by po1nter » Fri, Feb 23, 2018, 8:37 AM UTC

officialchicken wrote: post #156

It's been almost 2 years since the great left-pad debacle[0]. The last major npm issue[1] was less than 2 months ago. While the underlying npm registry security issues will remain for a while (and other languages don't seem to have these issues with their package managers), there doesn't seem like there's too much I can do other than use yarn. And hope an alternative registry will appear. Since I 'vote' with my code…

> I use ncu to check updates every couple of days

You can use "yarn outdated" for that.

Re: Do not use NPM 5.7

#206

Post by zaarn » Fri, Feb 23, 2018, 8:51 AM UTC

diggan wrote: post #93

zaarn wrote: post #43

Earlier quoted context omitted.

I think the easy solution here would be to disable global installs. Pip does that same stuff and it also is known to get people's computers into quite advanced states. Ideally npm should simply setup a dedicated directory in /opt or /usr/local/ (ie, /usr/local/node/bin or /opt/node/bin) in which it dumps all the global stuff. That way you can easily set permissions for a user and/or contain any damages to that folder…

> easy solution here would be to disable global installs I think that's not optimal. Having package being installed "globally" (as in available on your PATH) is nice. You can install `yarn` by doing `npm install --global yarn`. The trouble is how people setup their node/npm installation. Instead of having global packages setup under the home directory, people use the default which requires root access. Instead, defau…

I basically want what you mentioned later but also available to other users.

Home folder installation only works when you A) only want to install for a user B) the user you run under exists on disk and has a home folder and C) the user can be setup to perform updates.

A lot of the time I run tools that will run as a service. The user it runs under might not have a home folder, probably not even a login or shell. I still need access to the tool installed as root and as normal user for maintenance.

So ideally, I add the path into /etc/profile and install the stuff into /usr/local/node/bin where it is perfectly isolated from the rest of the system.

Re: Do not use NPM 5.7

#207

Post by slavik81 » Fri, Feb 23, 2018, 8:56 AM UTC

Silhouette wrote: post #83

mbrumlow wrote: post #57

Earlier 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…

> This response annoys me, because it's essentially victim-blaming.

No. The victim is the end-user who suffered from the production outage. jguimont is a professional who has an obligation to his clients.

Adopting a third-party tool or library does not absolve you of the responsibilities that you have to your users. You choose your tools and your libraries.

Both npm and jguimont screwed up here. Mistakes happen, and I certainly wouldn't judge anyone harshly for the occasional learning experience. But, the first step to learning from your mistake is admitting that you made one. jguimont has done that, and I respect him for it.

Re: Do not use NPM 5.7

#208

Post by diggan » Fri, Feb 23, 2018, 10:03 AM UTC

paulddraper wrote: post #116

diggan wrote: post #106

Earlier quoted context omitted.

npm is not for managing system software and has not been developed as such. It's a javascript package manager. apt and pacman (and probably yum but never used so can't speak about it) have active maintainers for most packages and the mirrors are well taken care of. npm is basically a giant array that anyone can add package to. I'm using them both accordingly.

> npm is not for managing system software Debatable but irrelevant. I'm not saying npm is a good or bad system package manager, just that running arbitrary scripts for requested packages and their dependencies is hardly unique. It's oblivious to single out npm as a package manager that allows you to be pwned by packages in whatever repo you pull from.

It's not unique, but apt/pacman does not run arbitrary scripts. It runs what has been reviewed by others while npm packages are often not reviewed by anyone except the author, that's the difference.

Re: Do not use NPM 5.7

#209

Post by vl-y » Fri, Feb 23, 2018, 10:08 AM UTC

po1nter wrote: post #205

officialchicken wrote: post #156

It's been almost 2 years since the great left-pad debacle[0]. The last major npm issue[1] was less than 2 months ago. While the underlying npm registry security issues will remain for a while (and other languages don't seem to have these issues with their package managers), there doesn't seem like there's too much I can do other than use yarn. And hope an alternative registry will appear. Since I 'vote' with my code…

> I use ncu to check updates every couple of days You can use "yarn outdated" for that.

and "yarn upgrade-interactive --latest"

Re: Do not use NPM 5.7

#210

Post by dozzie » Fri, Feb 23, 2018, 10:11 AM UTC

jmagoon wrote: post #150

kakwa_ wrote: post #82

Earlier quoted context omitted.

What you say is 100% true, but I would go one step further and not have npm installed on any production server. And it's not specific to npm, I would do the same with gem, pip, cpan, etc. Not to mention curl http://ex.io/install.sh | sudo bash. Call me old school, but personally, I would avoid installing anything from language specific package managers. I would instead either build an rpm/deb package for every depend…

I like this idea. Can you elaborate a little bit on how/where you would fetch the gem package without the language based package manager, and how this is linked to system deps? For dynamic web application deploys the self-contained binary seems ideal, but I've fallen back on Ansible to properly configure the server dependencies, along with gems that may have system dependencies (e.g. psql).

> [...] how/where you would fetch the gem package without the language based package manager, and how this is linked to system deps?

You unnecessarily constrain yourself too much. You don't need language specific package manager at all for deployment. For building a binary package you probably need it, but not connected to network. And then you need it with network for downloading source tarballs to include in source package (SRPM or similar). Note that the source package is an important step, as you want to host all necessary code yourself, without relying on randomly changing policies of package registries like NPM.

The sad part is that language specific package managers cram together downloading, building, and installing, instead of providing them primarly as three separate steps. (You usually can run each separately, but crippled in some whay, e.g. you don't get proper dependency solving for download, or you need to manually order building the dependencies.)

> [...] how [binary packages] is linked to system deps?

Normally. Your application requires libpq.so? You mention it in Depends: (or allow the build scripts to detect that). You need sloccount? You mention it in Depends:. You need crontab entries? You put them in /etc/cron.d and add cron to Depends:.