Hacker News Reader

Comment by atraac | Hacker News Reader

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.

View on HN

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, unless the whole ecosystem moves to a deno-like sandboxed environment. Maybe that is the plan?

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...

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.

>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.

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.

> 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.

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.

On a project with a 1GB node_modules directory (after aggressive cleanup) I think we only had one dependency that didn't work right with postinstall disabled. Though I can't recall which and I don't work there anymore so I can't hunt.

And IIRC that one was fixable by a PR, because they'd done something weird and there was an idiomatic way to accomplish the same thing.

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.

Your own link says that a proper package manager (e.g. pnpm) supports this out of the box.

If there are other use cases that really need post-install scripts, you can whitelist just those in pnpm. In projects I'm working with, there are often zero post-install scripts that must be enabled for everything to work properly, and it's usually from poorly cobbled packages that use them to download prebuilt binaries (well written packages, like biome or tsgo, use per-architecture subpackages).

You enable just one or two of those, and block everything else.

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

You’re free to allow scripts as per the linked docs for NPM 12. But the vast majority of us will appreciate the reduced attack surface.

TFA explains how this works, and how to opt out.

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.

Reply on news.ycombinator.com