Rejecting lifecycle scripts, especially pre-emptively, should be easier #14067

Contribution

• I'd be willing to implement this feature (contributing guide)

Describe the user story

Currently it is difficult to preemptively disallow builds for a known dependency:

• If I say pnpm add --ignore-scripts, the script is ignored once but anyone who clones the repository and tries and pnpm install will get a warning about it.
• If I say pnpm add --allow-build=!core-js, it adds !core-js: true to the allowBuilds config, which does not work.
• If I say pnpm approve-builds '!core-js' before pnpm add, it says There are no packages awaiting approval and does not modify the config file.
• As per pnpm config set for array and object values #10015, I cannot use pnpm config to modify a single item in an object.
• I could run the pnpm add command and then use pnpm approve-builds !core-js, but that prints an error message, has an intermediate command fail with exit code 1, and fails if itʼs already in the config file.

I think that leaves manually or programmatically editing the config file before any pnpm commands, which is harder in automated environments like when setting up a new repository.

Describe the solution you'd like

Ideally this would be fixed in a few places:

• The --allow-build flag should support !<pkg> syntax. Maybe it could also have an inverted --reject-build, to be easier to find if you want to reject builds.
• The approve-builds command with command line parameters should work even if no builds are pending approval. Maybe it could also have an inverted reject-builds, for the same reason as above.

Additionally, for if you arenʼt sure in advance

• The approve-builds command should have a --none option to reject all pending builds
• There should be --allow-no-builds or --reject-all-builds flag to be the safe equivalent of --dangerously-allow-all-builds

Only one of these needs to be implemented to get the behavior I want, except the last one which still wouldnʼt quite work because it doesnʼt let you change the answer if somethingʼs already approved. But I think all of them would be good, even if the others also happen.

Describe the drawbacks of your solution

Some of the mentioned solutions create synonyms or antonyms of existing flags/commands, which might get out of sync. But the existing solutions are already out of sync with each other.

Describe alternatives you've considered

Solving #10015 would provide a workaround to the solutions above, but any or more of them better handle this particular use case. Iʼm listing the rest all as main solutions instead of alternatives because I think they should all happen to make rejecting build scripts easier, but any one of them can get most of the way their on its own.