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

191–200 of 221 posts

Re: Upcoming breaking changes for npm v12

#191

Post by re-thc »

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…

> So all of these setup scripts (good or bad) can just move their entrypoint from npm to wherever the `import` or `require` happens.

That would / could kill performance

> Usually, you run the actual packaged dependency code at some point anyway, and usually with the same permissions as the install process.

So I doubt most people trace every dependency they install all the way. So sometimes it comes upstream. Maybe you don't run it. It could have been a dev dependency accidentally set for runtime and now you have it.

Re: Upcoming breaking changes for npm v12

#192

Post by inigyou »

beezlewax wrote: post #86
tyre wrote: post #80

Earlier quoted context omitted.

Young people were… right? VS Code is open source. (Cursor is built on it!) GitHub didn’t embrace, extend, extinguish git. You can git push to a different company (e.g. Gitlab) and you’ve migrated. The biggest problems with GitHub are scaling and availability, not lock-in. Microsoft today is nothing like it was 30 or 20 years ago. Fifteen years ago we were writing HTML and JavaScript specifically for Internet Explorer…

Do microsoft own git now? I don't think so

Pedantically no, but in practice almost yes. So many programmers born after 2006 think that Git and GitHub are the same thing.

Re: Upcoming breaking changes for npm v12

#193

Post by inigyou »

MrBuddyCasino wrote: post #65
thatmf wrote: post #34

> allowScripts defaults to off Nice that they're following pnpm's lead on this after [checks watch]... 18 months?

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

Maven has plugins which are downloadable modules that run at install time, IIRC?

Re: Upcoming breaking changes for npm v12

#194

Post by stefan_ »

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 want to build a modern web frontend you will need to use npm. But a lot of those only ever run in the users browser where they can't do any harm. I would never consider the insanity of that ecosystem for backend work.

Re: Upcoming breaking changes for npm v12

#195

Post by inigyou »

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 pip with --break-system-packages heh

Re: Upcoming breaking changes for npm v12

#196

Post by inigyou »

zarzavat wrote: post #52

There's an easy way to stop most supply chain attacks: 1. Publishing users must approve each and every release from a smartphone app. 2. Publishing users must provide verified government ID. The first step prevents the types of attacks where an attacker gets control of a maintainer's computer and publishes a new release. The second step discourages attacks where a user tries to get a malicious package used by others.…

How would this prevent Shai Halud?

Re: Upcoming breaking changes for npm v12

#197

Post by sneak »

classified wrote: post #186
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.

Strategical positioning for enshittification, control and future squeezing of profits. Embrace, Extend, Extinguish. https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

I don't think Microsoft is trying to extend and extinguish javascript or typescript. I do, however, think they are using their standard anticompetitive playbook to disadvantage IDEs that aren't VS Code and agents that aren't Copilot.

For example, it requires some hackery to use your Copilot subscription via the Copilot extension in VSCodium (the f/oss distribution).

They want the default to be writing javascript (where the default is npm), written in VS Code, publishing to GitHub. You can already see NPC devs mindlessly following this pattern.

The response is to refuse to use Microsoft software. Use a Mac, don't use Excel or Word, don't use VS Code. I've also pulled my repos from GitHub and won't publish there or on npm. Their ecosystem makes the world worse, even before you factor in the fact that they happily provide services to ICE to aid them in running concentration camps.

Re: Upcoming breaking changes for npm v12

#198

Post by altruios »

sneak wrote: post #197
classified wrote: post #186

Earlier quoted context omitted.

Strategical positioning for enshittification, control and future squeezing of profits. Embrace, Extend, Extinguish. https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

I don't think Microsoft is trying to extend and extinguish javascript or typescript. I do, however, think they are using their standard anticompetitive playbook to disadvantage IDEs that aren't VS Code and agents that aren't Copilot. For example, it requires some hackery to use your Copilot subscription via the Copilot extension in VSCodium (the f/oss distribution). They want the default to be writing javascript (whe…

> The response is to refuse to use Microsoft software. Use a Mac

Or Linux: an actual FOSS OS.

Re: Upcoming breaking changes for npm v12

#199

Post by WorldMaker »

dgoldstein0 wrote: post #66
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?

Off the top of my head the purposes I've seen for them: - building native bindings (node-sass) - asking for funding (core-js) ... Probably a few more but the native case is probably the biggest and the packages I'm using nowadays ship precompiled blobs in optionalDependencies. Install scripts seem to be out of favor.

After the backlash of using postinstall scripts for funding requests, most of that moved to the dedicated infrastructure of the `"funding"` key in package.json [1] and the `npm fund` [2] command. (Not that most companies/users pay any more attention to this funding request messaging other than maybe adding `--no-fund` to some of their `npm install` scripts, but it is still an improvement over using scripts to do it.)

[1] https://docs.npmjs.com/cli/v10/configuring-npm/package-json?...

[2] https://docs.npmjs.com/cli/v11/commands/npm-fund

Re: Upcoming breaking changes for npm v12

#200

Post by dns_snek »

b112 wrote: post #114
jnwatson wrote: post #17

Earlier quoted context omitted.

If you need a quick patch, you pass another parameter to turn off the 1 day. 1 day delay will prevent more problems than it makes.

While I think this may be true, what validation do you have on this point? Have you rolled the numbers, vs all of the high-pri security updates that will be missed on day one, and exploited? What is really needed is simply more nuance. I agree the delay can help, but honestly the entire ecosystem is broken. There shouldn't be a single thing installed, without someone having an eyes-on. That's how this is fixed. Distr…

> Have you rolled the numbers, vs all of the high-pri security updates that will be missed on day one, and exploited?

(Different person here) I don't have data and I don't think I need it. You either have a process to push security-critical updates out very rapidly or you don't.

If you have that process then nothing changes for you because that cooldown won't be used in that context.

If you don't have that process then nothing changes for you because you weren't pushing out those time-sensitive patches to begin with. But now you won't get hit by drive-by supply chain attacks.

The vast majority of "high severity vulnerabilities" in your dependencies are just noise by the virtue of not being exploitable in the manner that they're used in your project.

Post reply on HN