Reconsidering the removal the postinstall script

[alcuadrado]

Hi,

I'm creating this issue because I think this other one ( #4085 ) may need to be reconsidered.

While I understand the points explained in the previous one, two things have changed:

• pnpm now doesn't install packages with postinall scripts by default, resulting on a failure, and not a warning.
• npm will incrementally move in the same direction: [RFC] Make install scripts opt-in npm/rfcs#868

I think this is specially important for people using esbuild as a transitive dependency, e.g. through tsx. As people installing it directly should have an easier time providing the required flag/settings.

Maybe a solution that would make the change simpler is splitting the package into two: esbuild (the cli), and esbuild-lib (the library).

[bakkot]

npm will incrementally move in the same direction

To be clear, the proposed npm behavior is not failure, just a warning that can be silenced by explicitly allowing or forbidding the script. The install will still succeed.

[evanw]

I'm not necessarily against potentially making a change like this but I'm not sure how to think about it.

One problem is that I'm actually not sure how many people would be affected. Specifically this would break esbuild for people who install it with --no-optional. But I have no idea if that's 0.1% or 1% or 10% of people who use esbuild. Here's a quote from this related issue describing the problem:

In my project, esbuild is a subdependency, and it's not realistic to run npm install without --no-optional on the entire project, installing gigabytes of unneeded optional dependencies just to get esbuild to work.

I'm guessing that splitting things into esbuild vs. esbuild-lib wouldn't help this person. Their nested dependency would be using esbuild-lib, which would still be broken by the use of --no-optional after the removal of the postinstall script. So I believe we're talking about a trade-off of deliberately breaking esbuild for some people who rely on --no-optional vs. making esbuild easier to use as package managers start to require additional configuration for packages with install scripts.

It'd also be a little unfortunate to cause a performance regression with the esbuild CLI due to node startup overhead, but such is life in the node ecosystem I guess.

One potential path forward could be to see how other similar tools are handling this and follow their lead. I no longer have a good pulse on what similar tools are doing these days.

[alcuadrado]

I think swc is in a similar situation, and they are considering always installing a wasm fallback: swc-project/swc#11898 — If a user uses --no-optional they would have the wasm version. As explained in the swc issue, the disadvantage is a larger default installation, and some execution overhead.