ハコヅミを作る #57：料理に写真を付ける、依存パッケージを上げる（公開の前に残していたもの）
前回（#56）に続いて、テスタを待つあいだの作業です。今回は、「一般に公開する前に片づける」と決めていた2つを入れました。
- 料理に写真を付ける
- 数える場所が、2つあった
- 依存パッケージを上げる
- どちらを先に出すか
- 書く欄があっても、書き忘れる
料理に写真を付ける
料理には、名前・レシピ・食材を登録できます。ここに、できあがりの写真を1枚付けられるようにしました。
画像だけ足しても、編集の画面でしか見えません。そこで、料理の一覧を、ギアやキャンプと同じように「リスト」「カード」で切り替えられるようにして、カードに写真を出すことにしました。
料理の一覧のカード表示（写真の代わりに、描いた絵を使っています）
ほとんどが、使い回し
ギアとキャンプには、もう画像があります。料理の画像は、その仕組みをほとんどそのまま使えました。
- 画像を選ぶ欄（ファイルを選ぶか、URL から取り込む。ブラウザで小さくしてから送る）
- 画像の置き場所（利用者ごとのフォルダ。退会したら、フォルダごと消える）
- 差し替えたら、古い画像を消す
- 画像の数の上限（ギア・キャンプ・料理を合わせて数える）
- データの書き出し（ZIP の中の
images/に入れる）
画像の欄は、ギア・キャンプと同じ部品
新しく決める必要があったのは、見た目だけです。Claude Code に、手元の画面で実際に写真を付けた絵を撮ってもらい、それを見て決めました。
| 決めること | 決めた形 |
|---|---|
| カードに出すもの | ギアのカードと同じ正方形に、名前と「食材 N 件」。写真のない料理は、名前の頭文字 |
| リスト表示 | 今までどおり、料理のアイコン（ギアのリスト表示にも写真は出していないので、そろえる） |
| キャンプの画面の料理の欄 | 写真を出さない（名前で足りる。出すと画面が重くなる） |
画像の数は、変えない
フリーの人が付けられる画像は、ギアとキャンプを合わせて 50 枚です。料理の写真もこの合計に入れるので、「50 枚で足りるかを見直す」ことも、この作業の中に入れていました。
結論は、変えないことにしました。ベータ版は始まったばかりで、まだ誰も使い込んでいません。決める材料がない状態で数を動かしても、根拠のない数が増えるだけです。フリーの料理は 20 件までなので、料理の写真で増えるのは、多くても 20 枚です。ベータ版で「足りない」という声が出たら、見直します。
使い方のページも直す
前回、「画面の動きを変えたら、使い方のページの文も直す」という決まりを作りました。早速、その出番でした。料理の説明に、写真とカード表示のことを書き足しました。
数える場所が、2つあった
画像の数は、2か所で数えています。
- 登録できるかを決めるとき（今の数と上限）
- 管理画面の、ユーザーごとの件数
Claude Code が、画像の列（image_key）を使っているところをコードの中から全部探したときに、2つ目に気づきました。上限のほうだけを直していたら、管理画面の件数は、料理の写真を数えないままになるところでした。
同じ数を、別々のコードで数えている場所が2つあると、片方だけ直して、もう片方を忘れます。今回は、列の名前で探したので見つかりました。
依存パッケージを上げる
もう1つは、依存パッケージの版上げです。3日前（10/6）、セカンドオピニオンのレビュー（#47〜）のときに npm audit（依存パッケージの、知られている脆弱性を調べるコマンド）を流して、8件を記録していました。「公開する前に片づける」と決めていたものです。
取りかかって流し直すと、12件に増えていました。
| 重さ | 10/6 | 10/9 |
|---|---|---|
| 高 | 0 | 4 |
| 中 | 4 | 4 |
| 低 | 4 | 4 |
何もしていなくても、3日で増えます。脆弱性は、見つかった日に増えるからです。
大きな版上げをしない「fix」だけを当てる
増えた「高」の4件は、どれも、デプロイに使う道具（wrangler）が中で使っているパッケージでした。手元の開発と、ビルドやデプロイのときにだけ動くもので、本番で動くコードには入りません。
npm audit fix は、大きな版上げ（メジャーバージョンの変更）を伴わない直しだけを当てるコマンドです。これで、「高」の4件が直りました。変わったのは、入っているパッケージの版を記録したファイル（package-lock.json）だけで、どの版を使うかを決めたファイル（package.json）は変わっていません。
残る8件を、上げない
残る8件は、10/6 から変わらないものです。直すには、大きな版上げが要ります。
| 件 | 直すには | 本番に効くか |
|---|---|---|
cookie（低） |
SvelteKit 3（使っているフレームワークの、次の大きな版） | 効かない。クッキーの名前などに変な文字を通す問題だが、ハコヅミはクッキーの名前を利用者の入力から作っていない |
esbuild（中） |
drizzle-kit 1.0（まだ正式版ではない） |
効かない。手元でマイグレーションを作るときだけ使う道具で、問題の機能（開発サーバー）も使っていない |
SvelteKit 3 への版上げは、それだけで1つの作業になります。一般に公開したあとに回すことにしました。
npm audit の件数は、ゼロにすることが目的ではありません。1件ずつ、「本番で動くコードに効くか」「ハコヅミの使い方で当たるか」を見て、上げるかを決めます。上げない理由は、PR に書いて残しました。
全部のテストを流す
版上げは、全部の画面に効くかもしれない変更です。手元でも、E2E テストを全件（542 件）流しました。全部通りました。
どちらを先に出すか
料理の写真は、開発環境での確認が済み、本番に出すだけの状態でした。そこで、「先に版上げをしても大丈夫？」と Claude Code に聞きました。
返ってきたのは、こういう答えでした。
- 大丈夫。版上げは画面の動きを変えないので、料理の写真と一緒に1回で出せば、リリースが1回で済む
- ただ、本番で何か起きたときに、どちらのせいかを切り分けにくくなる
料理の写真は、データベースに列を足すマイグレーションを伴います。何か起きても、データベースを過去の時点に戻せます。版上げは、開発環境で一通り触って確かめます。それで、まとめて出すことにしました。
書く欄があっても、書き忘れる
マイグレーションを伴う本番リリースでは、リリースの PR に「マージの直前の時刻」を書く欄を置いています。マイグレーションで本番のデータベースが壊れたときに、その時刻に戻すためです（データを戻す手順を作ったときに決めました）。
今回、その欄が空のままマージされました。リリースのあとに Claude Code が PR を読み直して、気づきました。
幸い、GitHub には、PR をマージした時刻が残っています。マイグレーションが当たったのは、その2分後でした。マージの時刻を、戻す時刻として、あとから書き足しました。
書く欄を置いても、書くのは人です。今回は、代わりになる記録（マージの時刻）が、たまたまありました。
おわりに
- 先に作った仕組み（ギア・キャンプの画像）があると、新しく決めることは見た目だけになる
- 根拠のない数は、動かさない。材料がそろってから決める
- 同じ数を数えている場所が2つあると、片方を直し忘れる。列の名前で探す
npm auditの件数は、何もしなくても増える。ゼロにするより、1件ずつ「本番に効くか」を見る- まとめて出すと楽になるが、何か起きたときに切り分けにくくなる。戻せる手段があるかで決める
- 書く欄を置いても、書くのは人。代わりになる記録がないかも、見ておく
次回こそ、テスタからの最初の声を聞く予定です。