Hacker News Reader

Comment by VMG | Hacker News Reader

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?

View on HN

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.

Reply on news.ycombinator.com