191–200 of 233 posts
Earlier quoted context omitted.
"everything you would expect of a Facebook-engineered library" So it collects your personal information, even when not using it, and uses it for profit?
I don’t like Facebook much, but their engineering is very good
This is really horrific. The idea that correctMkdir() exists at all seems to me to be so wrong-headed. This comment from the source says a lot: // annoying humans and their expectations! Good UX is an important, oft-overlooked consideration, but there is definitely such a thing as taking it too far. If your humans are expecting this level of hand-holding, it's because you've trained them to expect it by pandering to…
It all started with ubuntu pointing home to the user's dir when running sudo. This was done out of convenience to have gedit and other Xorg apps work when run with sudo...
Then there is also the terrible fact that ~/.local/bin didn't exist as a "standard" at the time. Which means your only sure-fire non-complicated way to install local bins guaranteed to work for the user was to put them in /usr/local/bin which meant running sudo.
But if you create a package cache dir during sudo in ubuntu in $HOME, thats with root permissions! Then you get errors when trying to run npm without root and it tries to manipulate the cache. How do we fix this, by changing cache dir permissions of course. https://github.com/npm/npm/commit/ebd0b32510f48f5773b9dd2e36...
Through series of refactorings, this became correctMkdirp, which is a non descriptive name of mkdir with (among other things) changing of permissions. And with a name like that it eventually was used in the wrong context and did the wrong thing.
I call this death-by-10-small-missteps. But I would pin the biggest problem on a missing omnipresent `~/.local/bin` standard (at the time). It doesn't cost much if anything, and it would single-handedly obliterate the need for users to much around in their paths (bad usability) or run sudo to install command line tools for personal use (clearly not the best idea).
Earlier 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 gathers sources from a central registry which anyone can upload packages to — and furthermore package references don’t even have to be references to entities in the registry but can also be links to arbitrary git repos ...
Furthermore the set of dependencies to actually be downloaded is quite a bit more dynamic with npm I think because of the version compatability satisfaction algorithm employed by npm — so it’s inherently harder to statically analyze the set of packages a given npm install execution will install vs rpm/apt.
- we are relying on 2 people team for our applications. - maintainer doesn't seem to care much about this horrific bug: https://imgur.com/a/v4Ndb
Earlier quoted context omitted.
Because sometimes you are writing software that interacts with hardware at a root level. This is really annoying advice you're giving since its absolute and without context. No, not everything is "super dangerous" with sudo. Get that FUD outta here!
Running npm as root is _super dangerous_ - full stop. npm install can run a large amount of arbitrary code downloaded from the internet via postinstall script hooks. Its absolutely banana-pants crazy to run `npm install` as a root user in any circumstance.
Earlier quoted context omitted.
Running npm as root is _super dangerous_ - full stop. npm install can run a large amount of arbitrary code downloaded from the internet via postinstall script hooks. Its absolutely banana-pants crazy to run `npm install` as a root user in any circumstance.
NPM does more than just npm install... Not full stop. How can you talk about a tool you dont understand?
‘npm run’ seems like it would be the most tempting — but it stills seems like a bad idea ... seems to me for most problems that people are likely to use ‘npm run’ as part the solution, the developer should be able to arrange things such that they don’t need to run those npm workflows with root privileges... for other tasks where they can’t get away from the need, it still seems dangerous — it’s always dangerous to run even trusted tooling with elevated privileges...
If you do use ‘sudo npm’ $(any command) where any command is pretty much any of the forms — (even run), you are more likely to have to run additional npm command with sudo privileges at some point in future as well - you are also more likely to _have_ to run npm commands with elevated privileges in future — which is also bad because it means you are likely to be using the tools in not the best way.
I really wish node would ship with Yarn instead of NPM. Every serious js project these days already uses it.
Does yarn run npm behind the scenes? Or does it even replicate the bugs in its attempt to be fully compatible? I used yarn to install global packages and see the packages in `/usr/lib/node_modules` with the permissions of my user rather than root.
Switching to yarn is not going to fix this. However, this raise some concern about npm cli - we are relying on 2 people team for our applications. - maintainer doesn't seem to care much about this horrific bug: https://imgur.com/a/v4Ndb
Yeah, but if you had switched to yarn beforehand, then you would not be facing this issue.
I 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…
To play devil's advocate, this was a dev version, without any UA or E2E testing, tagged as a major release. This after there have been major bugs for several releases. This isn't 0.7.0. Perhaps the problem is that the stability of the world's fastest growing development platform hangs on the implementation of best practices by a two person developer team . NPM needs to step up its game or we need to make something li…
Earlier quoted context omitted.
npm should never interact with hardware, it's job is to install and manage packages. I could understand that you have to run nodejs with root, since it actually can use the hardware. But using npm with root user? I can't think of a single usecase.
I am not a node guy but as far as I understand nodejs is a webserver, no? _Never_ run any webserver as root. This is just bad practice.
A webserver is one of many things that can be run using Node+JS, the point being that it's an entire runtime and can do pretty much anything any other language can do.