CyberRex

terserとcssnanoを直接使って独自のビルドスクリプトを書けば・・と思ったけど保守性がないか

Checks書き換えるの忘れてた

ただ書き換えるだけじゃダメだった https://github.com/pnpm/action-setup

Docker 動作確認済み (arm64)

> .yarnrc.yml のようなものは不要？ 基本的に不要 .npmrcを使う https://pnpm.io/ja/npmrc

#9533 がマージされ次第Draftから普通のPRにする

やっぱりpnpmはそこまででもないんですかね

> 言いたいことが伝わっていないようです。 > > まず前提として、どのような提案にも、それに対する合意形成は適切に行われなければなりません。 しかし、たとえ提案されるものがどれだけ有意であったとしても、議論にさしあたって、提案の説明が誤った背景に基づいていたり、偏向的であったりするならば、議論で得られる合意形成は適切なものとはいえません。 同じ事を繰り返して言いたくないんですが、もし先日述べた点に異論がないのなら、現在の説明をそのままにするのはレビュアーとしていただけないです。 @acid-chicken 申し訳ありません。ネット上の情報が古かったようなので改めて調べ直し、訂正しました。

> あと 1 pnpm ユーザーの所感として、シンボリックリンクが所謂 dependency hell と同構造のツリー上になってるせいで VSCode on macOS などで node_modules を範囲に含めて検索を（故意過失問わず）かけてしまうとシンボリックリンク解決がいつまで経っても終わらずフリーズしてしまう問題を経験しており、大規模なプロジェクトでの使用がこの現象を顕著にしないかは気になっている（現状の Yarn Berry pnpm モードでも同じかも、こっちはあまり使ったことがないのでよく知らない） そのような事象は発生していません。不安な場合は、VSCodeの場合は `.vscode/settings.json` にて**/node_modulesを検索しない設定を記述しリポジトリに入れることで回避できます。 ```json "search.exclude": { "**/node_modules": true } ```

pnpmを採用するにあたって１つ注意点があります。 NODE_ENVに忠実に従うため、`production`の場合はdevDependenciesに含まれているパッケージはアンインストールされます。PRに含まれているDockerfileではproductionの状態でインストールからビルドまでを行っていたのでNODE_ENVをセットするタイミングを変更しています。 個人的に、Cypressやeslintを通常使わないのでproduction (`yarn install --production`)を使っていました。 この際、ビルドツールを通常のdependenciesに移動してはどうでしょうか。