💬 Review commented: "削除された投稿はタイムライン上で表示しないようにする": shiroha-a "レビューありがとうございます。fork frontend の規約が口伝になっていたところを固定するのは価値があると思います。とくに submodule 系列の話は実際に踏みやすい罠です。
CLAUDE.md の[ドキュメントを直すときのレビュー条件](https://github.com/shiroha-a/mk/blob/develop/docs/contributing.md#ドキュメントを直すときのレビュー条件)に沿って、記述を実装と突き合わせました。
## 正しいことを確認できた主張
| 主張 | 根拠 |
|---|---|
| `frontend-check` job は eslint と vitest も走る | `.github/workflows/ci.yml` の `Lint (eslint)` / `Unit test (vitest)` step |
| `make frontend-check` は型だけ | `Makefile` の recipe は `npx vue-tsc --noEmit` のみ |
| vitest の include は `test/unit/**/*.test.ts` のみ | `packages/frontend/vitest.config.unit.ts` |
| `import/consistent-type-specifier-style: prefer-top-level` | `packages/frontend/eslint.config.js` |
| required check は submodule を checkout しない | `submodules: recursive` は `frontend-check` だけ |
| Playwright は required check でない | CLAUDE.md Section 8 と一致 |
## 要修正
### 1. `docs/development.md` の `make frontend-test` が重複
同ファイルの「コード品質」表に既に `| make frontend-test | fork frontend の vitest (#2844) |` があります。追加分と合わせて同じ target が 2 箇所に別の説明で載ります。どちらかに寄せてください。
### 2. `docs/ci.md` の `frontend-check` 実測「1.5 min」が古い
この PR は job の内容に eslint と vitest を足していますが、実測欄は据え置きです。直近 5 run を測ると **3m32s〜4m08s** でした。1.5 min は vitest を足した #2844 より前の値だと思われます。
### 3. eslint の手元再現が CI と同じ形になっていない
CI が実行するのは `pnpm eslint` です。`packages/frontend/package.json` の `eslint` script が既に `eslint --quiet "src/**/*.{ts,vue}"` なので、提案されている `pnpm eslint --quiet "src/**/*.{ts,vue}"` は同じ引数を重ねて渡すことになります。CI と揃えるなら `pnpm eslint` だけで十分です。
### 4. `i18n.t()` の理由が実装と食い違っている
`@deprecated` 自体は実在します (`packages/frontend-shared/js/i18n.ts`) が、コードが書いている理由は
> なるべくこのメソッド使うよりも ts 直接参照の方が vue のキャッシュ効いてパフォーマンスが良いかも
で、本番エラーの話ではありません。
実装を追うと `t()` は**正しい鍵なら production でも普通に動きます**。`TypeError` になるのは「存在しない鍵 + args」の組み合わせのときで (`devMode` なら `console.error` で握って鍵を返す)、しかもこれは `i18n.ts.foo.bar` の直接参照でも同じです。
現在の書き方だと「`i18n.t()` は本番で `TypeError` になる」と読めてしまい、**既存の正常な `t()` 呼び出しを不具合と誤認**させます。規約として「パラメータ付きは `i18n.tsx` を使う」を残すのは良いと思うので、理由をコード側の記述 (Vue のキャッシュ効率) に合わせるのが良さそうです。
### 5. 「52 ファイル分」の数え方が書かれていない
再現できませんでした。`origin/develop` ↔ `origin/mk-2026.9.0` で測ると削除は 26 ファイル (うち `packages/frontend/src/` が 13) です。
```
git diff --diff-filter=D --name-only origin/mk-2026.9.0 origin/develop | wc -l
```
どの SHA 間で数えたかを添えるか、数字を落とすのが良いと思います。CLAUDE.md の「数を書くなら数え方も書く」に該当します。
## 補足 (任意)
### 6. 「CI は巻き戻りを検出しない」は少し強い
`build` job に `Check submodule commit is pushed` step があり、**gitlink の SHA が fork に push 済みかは検査します** (祖先関係は見ません)。「何も見ていない」と読めると、この step で落ちたときに原因を探しづらくなります。「push 済みかは見るが、祖先関係は見ない」が正確です。
### 7. 「`develop` は数十コミット手前に分岐」
実測では `develop` 固有 11 / `mk-2026.9.0` 固有 **127**、merge-base は `Release: 2026.7.0` でした。「数十」より大きいので、具体値か測り方を添えるほうが確かだと思います。
```
git rev-list --left-right --count origin/develop...origin/mk-2026.9.0
```
---
4 と 5 は「読んだ人が誤った判断をする」種類なので、マージ前に直したいです。他は任意で構いません。
" https://github.com/misskey-dev/misskey/pull/2887#pullrequestreview-5129334773
CLAUDE.md の[ドキュメントを直すときのレビュー条件](https://github.com/shiroha-a/mk/blob/develop/docs/contributing.md#ドキュメントを直すときのレビュー条件)に沿って、記述を実装と突き合わせました。
## 正しいことを確認できた主張
| 主張 | 根拠 |
|---|---|
| `frontend-check` job は eslint と vitest も走る | `.github/workflows/ci.yml` の `Lint (eslint)` / `Unit test (vitest)` step |
| `make frontend-check` は型だけ | `Makefile` の recipe は `npx vue-tsc --noEmit` のみ |
| vitest の include は `test/unit/**/*.test.ts` のみ | `packages/frontend/vitest.config.unit.ts` |
| `import/consistent-type-specifier-style: prefer-top-level` | `packages/frontend/eslint.config.js` |
| required check は submodule を checkout しない | `submodules: recursive` は `frontend-check` だけ |
| Playwright は required check でない | CLAUDE.md Section 8 と一致 |
## 要修正
### 1. `docs/development.md` の `make frontend-test` が重複
同ファイルの「コード品質」表に既に `| make frontend-test | fork frontend の vitest (#2844) |` があります。追加分と合わせて同じ target が 2 箇所に別の説明で載ります。どちらかに寄せてください。
### 2. `docs/ci.md` の `frontend-check` 実測「1.5 min」が古い
この PR は job の内容に eslint と vitest を足していますが、実測欄は据え置きです。直近 5 run を測ると **3m32s〜4m08s** でした。1.5 min は vitest を足した #2844 より前の値だと思われます。
### 3. eslint の手元再現が CI と同じ形になっていない
CI が実行するのは `pnpm eslint` です。`packages/frontend/package.json` の `eslint` script が既に `eslint --quiet "src/**/*.{ts,vue}"` なので、提案されている `pnpm eslint --quiet "src/**/*.{ts,vue}"` は同じ引数を重ねて渡すことになります。CI と揃えるなら `pnpm eslint` だけで十分です。
### 4. `i18n.t()` の理由が実装と食い違っている
`@deprecated` 自体は実在します (`packages/frontend-shared/js/i18n.ts`) が、コードが書いている理由は
> なるべくこのメソッド使うよりも ts 直接参照の方が vue のキャッシュ効いてパフォーマンスが良いかも
で、本番エラーの話ではありません。
実装を追うと `t()` は**正しい鍵なら production でも普通に動きます**。`TypeError` になるのは「存在しない鍵 + args」の組み合わせのときで (`devMode` なら `console.error` で握って鍵を返す)、しかもこれは `i18n.ts.foo.bar` の直接参照でも同じです。
現在の書き方だと「`i18n.t()` は本番で `TypeError` になる」と読めてしまい、**既存の正常な `t()` 呼び出しを不具合と誤認**させます。規約として「パラメータ付きは `i18n.tsx` を使う」を残すのは良いと思うので、理由をコード側の記述 (Vue のキャッシュ効率) に合わせるのが良さそうです。
### 5. 「52 ファイル分」の数え方が書かれていない
再現できませんでした。`origin/develop` ↔ `origin/mk-2026.9.0` で測ると削除は 26 ファイル (うち `packages/frontend/src/` が 13) です。
```
git diff --diff-filter=D --name-only origin/mk-2026.9.0 origin/develop | wc -l
```
どの SHA 間で数えたかを添えるか、数字を落とすのが良いと思います。CLAUDE.md の「数を書くなら数え方も書く」に該当します。
## 補足 (任意)
### 6. 「CI は巻き戻りを検出しない」は少し強い
`build` job に `Check submodule commit is pushed` step があり、**gitlink の SHA が fork に push 済みかは検査します** (祖先関係は見ません)。「何も見ていない」と読めると、この step で落ちたときに原因を探しづらくなります。「push 済みかは見るが、祖先関係は見ない」が正確です。
### 7. 「`develop` は数十コミット手前に分岐」
実測では `develop` 固有 11 / `mk-2026.9.0` 固有 **127**、merge-base は `Release: 2026.7.0` でした。「数十」より大きいので、具体値か測り方を添えるほうが確かだと思います。
```
git rev-list --left-right --count origin/develop...origin/mk-2026.9.0
```
---
4 と 5 は「読んだ人が誤った判断をする」種類なので、マージ前に直したいです。他は任意で構いません。
" https://github.com/misskey-dev/misskey/pull/2887#pullrequestreview-5129334773
