Use pnpm for package manager

[CyberRex0]

Resolve #9532

What

パッケージマネージャーを Yarn v3 から pnpm にする。

Why

・Yarnよりも速く、省スペース ・ビルドの並列実行による高速化 ・Yarn v3にて一部環境で起きていたGitからのインストールの不具合が発生しない ・Yarn v3のようなパッケージマネージャー本体の同梱が必要ない ・npmよりかは良い

[CyberRex0]

Checks書き換えるの忘れてた

[tamaina]

Issueを書いてからPRしてほしい

[sousuke0422]

sharpとかが壊れてこうなるから変えたほうがいいかも

[CyberRex0]

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

[codecov[bot]]

Codecov Report

Merging #9531 (59a8583) into develop (fcca335) will increase coverage by 0.19%. The diff coverage is 23.48%.

:exclamation: Current head 59a8583 differs from pull request most recent head a620de8. Consider uploading reports for the commit a620de8 to get more accurate results

@@             Coverage Diff             @@
##           develop    #9531      +/-   ##
===========================================
+ Coverage    22.43%   22.62%   +0.19%     
===========================================
  Files          704      731      +27     
  Lines        65981    68477    +2496     
  Branches      2134     2028     -106     
===========================================
+ Hits         14801    15493     +692     
- Misses       51180    52984    +1804     

Impacted Files	Coverage Δ
packages/backend/src/core/CustomEmojiService.ts	51.06% <ø> (+10.08%)	:arrow_up:
packages/backend/src/core/DeleteAccountService.ts	51.16% <0.00%> (-3.84%)	:arrow_down:
...s/backend/src/core/FetchInstanceMetadataService.ts	22.29% <0.00%> (+0.03%)	:arrow_up:
packages/backend/src/core/NoteDeleteService.ts	33.90% <0.00%> (ø)
packages/backend/src/core/PollService.ts	42.34% <ø> (+2.51%)	:arrow_up:
...ckages/backend/src/core/PushNotificationService.ts	35.53% <ø> (+4.33%)	:arrow_up:
packages/backend/src/core/ReactionService.ts	28.93% <0.00%> (-0.09%)	:arrow_down:
packages/backend/src/core/S3Service.ts	55.00% <0.00%> (ø)
packages/backend/src/core/UserBlockingService.ts	28.76% <0.00%> (-0.82%)	:arrow_down:
packages/backend/src/core/WebfingerService.ts	64.70% <0.00%> (ø)
... and 189 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[CyberRex0]

Docker 動作確認済み (arm64)

[tamaina]

.yarnrc.yml のようなものは不要？

[CyberRex0]

.yarnrc.yml のようなものは不要？

基本的に不要 .npmrcを使う https://pnpm.io/ja/npmrc

[CyberRex0]

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

[tamaina]

普通に動いたしpnpmにしようぜ

[acid-chicken]

・セキュリティの向上 (意図しないパッケージへのアクセス制限) ・Yarnよりも速く、省スペース ・ビルドの並列実行による高速化 ・改良されたアルゴリズムで二重インストールや余分なスペースの使用を抑制

ここら辺がよくわからない（Yarn Classic の話を持ち出して比較しているように見える、Berry と比較すべきでは？）

・Yarn v3のようなパッケージマネージャー本体の同梱が不要

これはむしろ逆だと思っていて、バージョン違いによる面倒な問題が起こらないという利点がある（本来そのための Corepack なのであるが）

[acid-chicken]

特に

・セキュリティの向上 (意図しないパッケージへのアクセス制限)

については平気でこういうことする pnpm/pnpm#5499 ので

・Yarn v3のようなパッケージマネージャー本体の同梱が不要

という点では pnpm 自身の Semantic Versioning を期待すると不可解な問題を起こす可能性があり Yarn Berry と比較して向上するという評価は難しいと思っています

[acid-chicken]

（別に pnpm に移行するのを断固反対するわけではないが、説明には事実を書いて欲しい）

[CyberRex0]

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

[massongit]

https://github.com/misskey-dev/misskey/pull/9533 がマージされ次第Draftから普通のPRにする

https://github.com/misskey-dev/misskey/pull/9533 は実装が固まるまで時間がかかりそうなので、こちらのPRをすぐ出したい等あれば https://github.com/misskey-dev/misskey/pull/9533 のマージを待たずに進めていただいても問題ありません。

[acid-chicken]

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

言いたいことが伝わっていないようです。

まず前提として、どのような提案にも、それに対する合意形成は適切に行われなければなりません。 しかし、たとえ提案されるものがどれだけ有意であったとしても、議論にさしあたって、提案の説明が誤った背景に基づいていたり、偏向的であったりするならば、議論で得られる合意形成は適切なものとはいえません。 同じ事を繰り返して言いたくないんですが、もし先日述べた点に異論がないのなら、現在の説明をそのままにするのはレビュアーとしていただけないです。

[acid-chicken]

あと 1 pnpm ユーザーの所感として、シンボリックリンクが所謂 dependency hell と同構造のツリー上になってるせいで VSCode on macOS などで node_modules を範囲に含めて検索を（故意過失問わず）かけてしまうとシンボリックリンク解決がいつまで経っても終わらずフリーズしてしまう問題を経験しており、大規模なプロジェクトでの使用がこの現象を顕著にしないかは気になっている（現状の Yarn Berry pnpm モードでも同じかも、こっちはあまり使ったことがないのでよく知らない）

[massongit]

(議論の大枠についての指摘で恐縮ですが) 以下のような観点で整理してみると、説得力がある・議論のたたき台にしやすいDescriptionになりそうな気がしますね。

• 今何が問題なのか (As Is)
• 理想の状態とはどういった状態か (To Be)
• pnpm導入によって以下がどうなるか検討
  • As IsからTo Beにできる？ できない？ を1項目ずつ見る
  • As Isでは生じていない新たな問題は生じる？ 生じるとしたらそれはどういったものか？

[syuilo]

CHANGELOGの更新が要るかも

[syuilo]

手元で動かしてみた感じはYOSASOU

[tamaina]

YarnはLink Stepでのメモリ使用が気になっていたが、pnpmはというと…少々微妙な感じか？
（Link Stepはないっぽいけどre2のビルドで割りとメモリを食う？）

[CyberRex0]

言いたいことが伝わっていないようです。

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

申し訳ありません。ネット上の情報が古かったようなので改めて調べ直し、訂正しました。

[CyberRex0]

あと 1 pnpm ユーザーの所感として、シンボリックリンクが所謂 dependency hell と同構造のツリー上になってるせいで VSCode on macOS などで node_modules を範囲に含めて検索を（故意過失問わず）かけてしまうとシンボリックリンク解決がいつまで経っても終わらずフリーズしてしまう問題を経験しており、大規模なプロジェクトでの使用がこの現象を顕著にしないかは気になっている（現状の Yarn Berry pnpm モードでも同じかも、こっちはあまり使ったことがないのでよく知らない）

そのような事象は発生していません。不安な場合は、VSCodeの場合は .vscode/settings.json にて**/node_modulesを検索しない設定を記述しリポジトリに入れることで回避できます。

"search.exclude": {
    "**/node_modules": true
}

[CyberRex0]

pnpmを採用するにあたって１つ注意点があります。 NODE_ENVに忠実に従うため、productionの場合はdevDependenciesに含まれているパッケージはアンインストールされます。PRに含まれているDockerfileではproductionの状態でインストールからビルドまでを行っていたのでNODE_ENVをセットするタイミングを変更しています。

個人的に、Cypressやeslintを通常使わないのでproduction (yarn install --production)を使っていました。 この際、ビルドツールを通常のdependenciesに移動してはどうでしょうか。

[tamaina]

この際、ビルドツールを通常のdependenciesに移動してはどうでしょうか。

ビルドツールって全部dependenciesの中じゃない？

[CyberRex0]

ビルドツールって全部dependenciesの中じゃない？

tscが入ってるtypescriptがdevDependenciesの中に入ってます

[tamaina]

tscが入ってるtypescriptがdevDependenciesの中に入ってます

もしかして: バックエンドだけこう

[tamaina]

yarn clean-all; yarn buildしてもビルドできちゃうのはなんでなんだろうか

[CyberRex0]

もしかして: バックエンドだけこう

ルートのpackage.jsonにも入っているけれども……

[syuilo]

Arigathanks gozaimuch