Document that it is not safe to run pinst in the prepack step

[djcsdy]

As much discussed in other issues, "prepack": "pinst --disable" has never worked as intended. It always results in wrong information going into the npm database. It's just that most tools ignored the wrong information, including npm before npm v10.4.0. See https://gist.github.com/djcsdy/3ca078e23fdac4c50e077c84e8284a95

A lot of projects are starting to get hit by this problem:

• Can not install because of postinstall script. foray1010/ignore-sync#865
• Please remove the postinstall hook ver0-project/deep-equal#269
• Issue with husky install in post install script SimenB/add-asset-html-webpack-plugin#373
• npx create-eth@latest fails on node v20+ scaffold-eth/create-eth#49
• Installation fails with npm v10.x bun913/textlint-rule-aws-service-name#96
• The package can't be installed Pustur/whatsapp-chat-parser#256
• npx create-eth@latest fails on node v20+ scaffold-eth/create-eth#49

I assume this is just the tip of the iceberg. EVERY historical package that has been published using pinst in the recommended configuration is broken and cannot be installed correctly by npm >= 10.4. This problem is NOT limited to packages that were published recently.

I am seeing a lot of confusion about the underlying cause, which is not really surprising.

I think the only responsible course of action is to immediately stop recommending that developers use pinst in their prepack and postpack scripts since this results in broken packages and always has done.

Unfortunately the only safe way I know of to run pinst is to run it BEFORE yarn publish. There's no safe way I know of to cause yarn publish to run pinst --disable automatically. It's unfortunate that the solution is so unergonomic, but the only alternative is many broken packages.

Fixes #22, #23.

[JoelLefkowitz]

Ohhh I've started seeing this in my packages too. @djcsdy your gist really helped clarify things for me: https://gist.github.com/djcsdy/3ca078e23fdac4c50e077c84e8284a95.

I like your suggestion of invoking pinst at release time:

yarn pinst --disable
yarn publish
yarn pinst --enable

Rather than at install time:

{
  "prepack": "pinst --disable",
  "postpack": "pinst --enable"
}

This is because manipulating the scripts is really a 'release' task. Also the npm scripts section is always cluttered so this frees up some space.