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

161–170 of 221 posts

Re: Upcoming breaking changes for npm v12

#161

Post by vbezhenar »

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…

You can build application outside of container, but run it in container. I think that it is simpler workflow, than everything in container (when you actually need to develop it with IDE).

I didn't try devcontainers stuff, TBH. But that's how I often develop my apps.

That said, there are other attack surfaces for that approach. For example I'm not sure if I can trust LSP server not to execute application code. So keeping everything in a container or in a VM seems to be the only sane approach to work with code you don't trust.

Re: Upcoming breaking changes for npm v12

#162

Post by [deleted] »

Eji1700 wrote: post #93
tuckwat wrote: post #46

I bet there have been a hundred different discussions about this inside of NPM since it was disclosed 10 years ago. With Shai Halud it's gotten too big to ignore.

I do love that javascript's history is basically just coder mentality distilled. "oh yeah we'll fix that shortly" is almost always "oh fuck now we have to"

[deleted]

Re: Upcoming breaking changes for npm v12

#163

Post by rafaelmn »

vbezhenar wrote: post #161
VMG wrote: post #156

Earlier quoted context omitted.

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…

You can build application outside of container, but run it in container. I think that it is simpler workflow, than everything in container (when you actually need to develop it with IDE). I didn't try devcontainers stuff, TBH. But that's how I often develop my apps. That said, there are other attack surfaces for that approach. For example I'm not sure if I can trust LSP server not to execute application code. So keep…

>You can build application outside of container, but run it in container. I think that it is simpler workflow, than everything in container (when you actually need to develop it with IDE).

At this point I will not do any dev outside of a container - so many things can be supply chained in the OSS dev stack it's just not worth it, and once you get used to developing in containers it's actually a lot cleaner to move between hosts - you're essentially treating your client as a remote terminal.

If you're doing web dev work in this day an age SSH with tmux or some editor with SSH server support should be your dev setup.

Re: Upcoming breaking changes for npm v12

#164

Post by imtringued »

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.

Re: Upcoming breaking changes for npm v12

#165

Post by mkesper »

arcatek wrote: post #148
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.

Of course. Modern Yarn releases (4.x) are deterministic to a fault and you can rely on it to have a consistent behavior across your whole team. As for feature-wise I'd say it's a lot of small details that together add up once you grow used to them. The next major release will keep pushing in that direction with both better performances and features we couldn't implement until now due to their reliance on said perfs i…

It was a giant mistake to keep 'classic' (umnaintained, unpatched) yarn around. Switched to pnpm in part due to that reason.

Re: Upcoming breaking changes for npm v12

#166

Post by jeremyjh »

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…

A lot of packages are only used in the browser; if you don't use SSR they'd only be executed by node in unit tests in something like jest, but that is not the only way to run unit tests (Cypress can run them in a headless browser [1], for example). Running those sand-boxed would be the next logical step.

Removing automated execution of postinstall is a necessary step and may as well be the first one.

[1] https://docs.cypress.io/app/component-testing/get-started?ut...

Re: Upcoming breaking changes for npm v12

#168

Post by arcatek »

mkesper wrote: post #165
arcatek wrote: post #148

Earlier quoted context omitted.

Of course. Modern Yarn releases (4.x) are deterministic to a fault and you can rely on it to have a consistent behavior across your whole team. As for feature-wise I'd say it's a lot of small details that together add up once you grow used to them. The next major release will keep pushing in that direction with both better performances and features we couldn't implement until now due to their reliance on said perfs i…

It was a giant mistake to keep 'classic' (umnaintained, unpatched) yarn around. Switched to pnpm in part due to that reason.

It's not exactly unmaintained (we merged a couple of security patches in the past years), I agree that we should have do something about it.

We'll be correcting this situation starting from the 6.x release, which we expect somewhere in August.

Re: Upcoming breaking changes for npm v12

#169

Post by arcatek »

tuwtuwtuwtuw wrote: post #159
arcatek wrote: post #148

Earlier quoted context omitted.

Of course. Modern Yarn releases (4.x) are deterministic to a fault and you can rely on it to have a consistent behavior across your whole team. As for feature-wise I'd say it's a lot of small details that together add up once you grow used to them. The next major release will keep pushing in that direction with both better performances and features we couldn't implement until now due to their reliance on said perfs i…

Deterministic to a fault unless you mix Windows and Linux. https://github.com/yarnpkg/berry/issues/6105

As mentioned in the issue you link the problem comes from third-party packages with non-deterministic build scripts in git dependencies, or files on disk being actually different (although I guess we could at least try to normalize crlf, but as you can guess it will break someone).
Post reply on HN