Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Upcoming breaking changes for npm v12

github.blog

Post reply on HN
Print view View original

171–180 of 221 posts

Re: Upcoming breaking changes for npm v12

#171

Post by padjo »

VMG wrote: post #156
atraac wrote: post #122

postinstall scripts should've been removed long time ago, it's the cancer of NPM packages. There's so many deeply nested, uncontrolled postinstalls that run randomly when you pull something it's insane, I don't know how someone at some point ever though that was a good idea.

I must admit I don't really understand what the point of the post-install script concern is. Usually, you run the actual packaged dependency code at some point anyway, and usually with the same permissions as the install process. So all of these setup scripts (good or bad) can just move their entrypoint from npm to wherever the `import` or `require` happens. It seems to me that this is a small stumbling block at best…

If you only use npm to manage client side deps then it removes the ability to compromise a devs machine or the CI server. Seems like nice attack vectors to just eliminate entirely.

Re: Upcoming breaking changes for npm v12

#172

Post by atraac »

gear54rus wrote: post #130
atraac wrote: post #122

postinstall scripts should've been removed long time ago, it's the cancer of NPM packages. There's so many deeply nested, uncontrolled postinstalls that run randomly when you pull something it's insane, I don't know how someone at some point ever though that was a good idea.

Absolutely not, there are plenty of use-cases for them. https://www.npmjs.com/package/patch-package comes to mind off the top of my head. Hopefully current hysteria will not result in some bs decisions like this.

How would getting rid of postinstall break patch-package? If people use a package, and that package needs some kind of step to get working, user of that package should decide when that step happens. He can very well just call patch before building on his own. There's zero issues with that approach and the upside is he actually has control.

I work in a monorepo where running install calls dozens of deeply nested postinstalls of some elaborate NextJs or React Native dependencies other projects use. It's borderline insane. Unless you regularly screen everything, it's impossible to know whether one of those is compromised, especially in the world of Node where is-even is being used and the sheer amount of crypto scams around.

Re: Upcoming breaking changes for npm v12

#173

Post by cookiengineer »

imtringued wrote: post #164
cookiengineer wrote: post #67

What a pointless change. If you force every user to just use "--enable-unsecure-feature", guess what will happen? This is not about improving security. This is about shifting blame. A much better alternative would've been the introduction of sandboxes or simulation runs that would output which scripts and programs are running due to unpredictable dependencies. This way the user could check before the actual execution…

This is kind of like arguing that immutable by default variables are pointless. If you force every user to just write "mut", guess what will happen? They will write "mut" when they need mutable variables, which in practice turns out to be the minority of variables. It's the same with "Option". The vast majority of variables or struct members do not need to be nullable at all.

> If you force every user to just write "mut", guess what will happen?

This is the wrong analogy.

The equivalent analogy would be using a compiler flag that is triggered for all dependencies and all included libraries without a per-library or per-file changeability. Something like "gcc --force-mut-all-yolo".

Variables have scopes of concern. This new NPM feature has no scope. And that's what my critique is about, because it makes it still unpredictable if any of your dependencies of dependencies needs a script.

The spread vector of potential malware stays identical, because the reason the miasma worm is spreading so fast is because of dependencies of dependencies that are impossible to audit on a case-by-case basis, given the lack of sandboxes and the lack of allowlisting scripts on a per-dep-and-version basis.

Re: Upcoming breaking changes for npm v12

#174

Post by flexagoon »

bastawhiz wrote: post #170

I'm not sure how I missed that npm was acquired by GitHub, but man, a lot of stuff suddenly makes a lot of sense. I really can't think of a worse home for such a critical part of the Node ecosystem.

Happened in 2020 apparently

https://github.blog/news-insights/company-news/npm-is-joinin...

Re: Upcoming breaking changes for npm v12

#176

Post by jasonlotito »

tomnipotent wrote: post #111
7bit wrote: post #106

Earlier quoted context omitted.

Was that the case? Can you provide sources to your claims and provide a foundation to your theories?

It's literally a Google search away. If you had the time to write this comment, you had more than enough time to do the search.

Google said you are 100% wrong.

Re: Upcoming breaking changes for npm v12

#177

Post by SCLeo »

dlopes7 wrote: post #61
SCLeo wrote: post #53

I don't get it. How does this help with anything? You pull in a dependency to use it, right?

Well pulling some code is different than running a script on your machine

Frequency of actions matter, especially for security changes. If we are talking about git, I agree. If we are talking about npm, I bet 95%+ times people install packages in order to use them, not just to admire the code.

Someone else in this thread mentioned that npm can be used to manage pure front end libraries, which is a fair point.

Re: Upcoming breaking changes for npm v12

#178

Post by afavour »

bastawhiz wrote: post #170

I'm not sure how I missed that npm was acquired by GitHub, but man, a lot of stuff suddenly makes a lot of sense. I really can't think of a worse home for such a critical part of the Node ecosystem.

Eh, it was pretty terrible before the acquisition too...

Re: Upcoming breaking changes for npm v12

#179

Post by moi2388 »

_pythonlover_ wrote: post #101
shimman wrote: post #29

Earlier quoted context omitted.

MSFT acquisition of NPM was a massive shit show, they fired many staff engineers and people that were at github for quite a while. Top comment was a liar.

I was part of the npm team at GitHub. They laid off almost the entire team to focus on AI (CTO literally told us on the layoff announcement call that they're doing this to focus on Copilot)

Fortunately npm was a shitshow long before ai

Re: Upcoming breaking changes for npm v12

#180

Post by rswail »

tuananh wrote: post #68
MrBuddyCasino wrote: post #65

Earlier quoted context omitted.

Java‘s Maven never had them, never felt a need for them. What is their purpose in JS land?

native modules. nodejs can have native modules (written in C++, Rust, etc...). Projects usually ship prebuilt natives binaries (for each arch/OS/Nodejs ABI combination) hosted on GitHub Releases and download them automatically at installation time; fallback to build from source if not found. that's where scripts are used the reason for not bundling all native binaries is becasue the no. of combinations are huge and i…

Not an NPM user, but you can't specify a set of arch combinations and NPM will get the appropriate prebuilts?

That sounds like an NPM problem that would be relatively easy to fix.

Can the builds be sandboxed with strictly limited capabilities?

All of this sounds solvable, why hasn't it?

Post reply on HN