知ってる簡単な例だと、Mediasoupプロジェクトがある。これはインターネットで動画をストリーミングするためのC++で書かれたライブラリだよ。Nodeパッケージとして公開されていて、JS APIを提供してる。インストールすると、適切なC++ソースをダウンロードして、その場でコンパイルするんだ。プロジェクトのメンテナはコードを書きたかっただけで、プリコンパイルされたビルドを管理したくなかったから、これが一番論理的なインストール方法だったんだ。ちなみに、しばらく前に最も一般的なプラットフォーム用のダウンロード可能なビルドを追加したけど、それ以外はインストール時にソースをビルドすることが期待されてた（今でもそうだと思う）。

pnpm v10はデフォルトで全てのライフサイクルスクリプトを無効にして、ユーザーにパッケージをホワイトリストに登録させる必要があるよ。 https://github.com/orgs/pnpm/discussions/8945

一つのユースケースはバイナリのダウンロードだね。例えば、mongo-memory-server [0]はインストール後にmongoDBのバイナリをダウンロードするよ。[0] https://www.npmjs.com/package/mongodb-memory-server

確か、Huskyがライフサイクルフックを使って、NPMインストール時にリポジトリに設定されたgitフックをインストールするってことをやってた気がする。

これで痛い目にあったのは、gulp用の画像圧縮ツールや古いバージョンのsassをコンパイルした時、あとopensslの時が特に印象に残ってる。npmパッケージをダウンロードするのに、Cコンパイルツールをいじる必要があるなんて理想的じゃないよね。

パッケージをダウンロードするだけじゃなくて、コードも実行するんだよね。特に、LLMがこういう書き方をするのは、トレーニングデータに多くの人間がそう書いてたからだと思うと、ちょっと辛いな。

Swift Package ManagerはSwiftスクリプトを実行するんだ。Package.swiftファイル（マニフェスト）は実際には実行されるソースファイルなんだと思う。ただ、かなりサンドボックス化されてるだろうから、利用するのは難しいかもね。

でも、公式のインストール手順がcurl | bashの形になってるプロジェクトがどれだけあるか見たことある？

「趣味でやってるんだけど、こういう侵害からどうやって守られて、情報をキャッチアップすればいいのかな？」一般的なソフトウェアのケースでは、「Nodeを使わない方がいい」ってアドバイスするかな。それに加えて、外部監査や検証なしのパッケージバックエンドは避けた方がいい。PyPIにも問題があるし、Cargoも理論的には同じくらい悪いけど、実際には安全だよ。ゴールドスタンダードは、Debianが提供するソフトウェアを使うこと（Fedoraもいいし、Archはちょっと下だけど、Linuxの外のユーザー提出の混乱ほどひどくはない）。でも、君の質問はフロントエンドのウェブ開発についてのようだね。そこは私の領域じゃないから、同情以外のアドバイスはできない。>「時々、ちょっと面白いものを作って、誰かの役に立つかもしれないけど、逆に自分がボットの標的になっちゃうんじゃないかって心配になる。」まさにその通りだね。ソフトウェアを配布するのは難しい。プロセスのいろんなレベルでたくさんの作業が必要だし、誰かがそれをやることにコミットしないといけない。時間やリソースをコミットするつもりがないなら、消費可能な形で配布しない方がいいよ（もちろん、自分が作ったものを配布するのはいいけど、適切にライセンスされていれば、誰かがそれを商品化してくれるかもしれない）。NPMはそのオーバーヘッドをうまくやれると思ってたけど、振り返ってみると、早すぎて壊れた状況だったね。