Should pnpm v10 throw an error if there are unreviewed packages with postinstall scripts?

[zkochan]

Related issue.

Seems like many of our users upgrade to pnpm v10 without reading through the breaking changes, and they don't notice pnpm's message about blocking installed scripts. As a result, they spend a lot of time investigating why their dependencies stopped working.

In order to help our users, we could throw an error instead of printing an info or warning message. This will force them review and approve their dependencies for running install scripts.

This could be considered a breaking change. However, most of the projects with unapproved builds must be already broken.

[jineshshah36]

Forcing explicit decision-making on this by default seems like a great pro-security decision.

[zkochan]

It is secure currently as the scripts don't run by default. This is more about notifying users more prominently as some complain that they don't notice the message during installation.

[eamodio]

Personally I'd rather a prompt with helpful actions to either allow or ignore rather than just an error.

Wouldn't there also need to be an ignore list? (Or is there one already )

[zkochan]

Yes, there is an ignore list.

[WoodyWoodsta]

Have run into something similar to #9045. My thoughts on the above are whether it's a warning or an error, it should be possible to somehow analyse the project repeatedly regardless of the state of installation.

I think it's a touch unfair to suggest we aren't reading the breaking changes list - the upgrade path on some of our almost 100 projects were completely silent about packages requiring attention.

[zkochan]

The issues in the referenced issue will be fixed in the next version of pnpm.

[remorses]

Throw an error in a non interactive terminal, if terminal is interactive, show a prompt to choose which packages to allow scripts for

Running a second command copying it from pnpm output adds too much friction