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

131–140 of 221 posts

Re: Upcoming breaking changes for npm v12

#131

Post by philipwhiuk »

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.

The entire use-case of that package is a security nightmare.

Re: Upcoming breaking changes for npm v12

#132

Post by philipwhiuk »

karakanb wrote: post #25

It is not obvious from the post but it seems like the allow list for the scripts supports whitelisting packages instead of a global setting. This should make it easier to maintain org-wise rules to allow scripts only for specific packages. Is there a linter that could be used for scenarios like this to prevent unsafe default on package manager config?

grep?

Re: Upcoming breaking changes for npm v12

#134

Post by gear54rus »

philipwhiuk wrote: post #131
gear54rus wrote: post #130

Earlier quoted context omitted.

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.

The entire use-case of that package is a security nightmare.

Then don't use it. Just don't presume to tell me if I can or can't.

Re: Upcoming breaking changes for npm v12

#135

Post by dgellow »

gear54rus wrote: post #134
philipwhiuk wrote: post #131

Earlier quoted context omitted.

The entire use-case of that package is a security nightmare.

Then don't use it. Just don't presume to tell me if I can or can't.

Given that has an impact over the whole industry, I will for sure tell you that patching on install SHOULD NOT be a thing. Up to you to run your own post install script yourself

Re: Upcoming breaking changes for npm v12

#136

Post by tpetry »

frabcus wrote: post #118
semiquaver wrote: post #11

Earlier quoted context omitted.

Ok? Not sure what a package manager can do about the fact that eventually you want to run the things you install.

Have any kind of provenance. eg like Debian has for 30 years. Key signing in person etc

That has also been implemented recently. With staged publishing the author must verify a new release with 2FA so automated attacks dont work anymore. Some human in the loop must verify a release.

Re: Upcoming breaking changes for npm v12

#137

Post by tpetry »

spartanatreyu wrote: post #35
Someone1234 wrote: post #13

Earlier quoted context omitted.

I’m sure we’d all welcome your alternative and or superior proposals. Without that, this just comes across like unconstructive commentary. This moves the needle a little your proposals or the lack thereof don’t move it at all. So I’ll take this over nothing.

We already have alternative and superior proposals, it's called Deno. It's node + npm compatible and its permission system locks everything down by default. If you know ahead of time, you can turn on which permissions something is supposed to have in the config file. Or you can just not use a config file at all. Anytime it needs a permission: it asks you what it wants. You can say yes or no, and those are saved in th…

Can you clarify why the node permission system is broken but the deno one works? For an outsider like me both look like the same.

Re: Upcoming breaking changes for npm v12

#138

Post by [deleted] »

sroussey wrote: post #100
tuananh wrote: post #68

Earlier quoted context omitted.

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…

Having a non-script method of downloading the right native binary would be a good next step.

[deleted]

Re: Upcoming breaking changes for npm v12

#139

Post by homebrewer »

partsch wrote: post #107

I wonder if there are still reasons to use yarn? Has yarn also implemented safeguards to protect against supply chain attacks? Until now, I only knew about pnpm. It’s great that npm has followed up.

One distinguishing feature is their optional install strategy: running packages directly from compressed archives instead of unpacking them into node_modules.

https://yarnpkg.com/features/pnp

Very similar to using .jar's in Java instead of directory trees of .class files.

It's somewhat hacky though, and editor/tool support varies.

- since there are far fewer small files, it can be faster especially on Windows if you're forced to work on it for some reason

- the archives can be stored into the git repository (through git-lfs or friends), removing dependency on the internet and the package registry

Re: Upcoming breaking changes for npm v12

#140

Post by vardump »

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…

There should be a path for local building as well. Node.js is being used on a lot of embedded systems. I’d imagine there are also lots of other reasons for local builds.
Post reply on HN