<p>自動テストについて調べてみたなかで手始めに「<a href="https://playwright.dev/" target="_blank" rel="noopener noreferrer nofollow"><u>Playwright</u></a>」を触ってみることに。</p><p>まずは簡単なところから、<strong>URLのリストをもとにスクリーンショットを取得する</strong>処理を試しました。</p><h2 id="h9f510f3156">やりたいこと</h2><ul><li>複数のURLに対して、順番にアクセスしながらスクリーンショットを取得</li><li>URLリストはJSONファイルで管理</li></ul><h3 id="h009dfaed07">番外</h3><ul><li>Basic認証がある場合も対応</li><li>特定の要素を非表示にしてからキャプチャを取得</li><li>モバイルサイズ・PCサイズなど、デバイスごとにサイズ指定</li><li>JPEGで保存する場合は画質を調整</li></ul>

npm init -y
npm install -D @playwright/test
npx playwright install

import { test } from "@playwright/test";
import fs from "fs";

const urls: string[] = JSON.parse(fs.readFileSync("./pages.json", "utf-8"));

for (const url of urls) {
  test(`screenshot for ${url}`, async ({ page }) => {
    await page.setViewportSize({
      width: 1280,
      height: 800,
    });
    await page.goto(url, { waitUntil: "networkidle" });

    // 特定の要素を非表示にする
    await page.locator(".クラス名").evaluateAll((els) => {
      els.forEach((el) => (el.style.display = "none"));
    });

    const u = new URL(url);

    // パス末尾の / を削除し、先頭の / を除き、/ を _ に変換
    const cleanPath = u.pathname
      .replace(/\/$/, "")
      .slice(1)
      .replace(/\//g, "_");

    // ホスト名（localhost や example.com）とパスを組み合わせてファイル名を生成
    const pathname = `${u.hostname}${cleanPath ? `_${cleanPath}` : ""}`;

    // 最終的なファイル名（screenshots/example.com_about_team.jpg など）
    const filename = `screenshots/${pathname}.jpg`;

    // 保存先ディレクトリ作成
    fs.mkdirSync("screenshots", { recursive: true });

    // スクリーンショット取得
    await page.screenshot({ path: filename, fullPage: true, quality: 80 });
  });
}


[
  "ページURL１",
  "ページURL２",
  "ページURL３"
]

<h3 id="h251ac368fd">実行して取得したスクリーンショット</h3><p>Chrome拡張機能などで取得したスクリーンショットほどスッキリ・クリアな感じの画像ではないけど、確認程度なら十分な画質。</p><p>qualityを100にしても変わらずでした。</p>

<h2 id="h5ca22457fd">特定の要素を非表示にする</h2>

await page.locator(".クラス名").evaluateAll((els) => {
  els.forEach((el) => (el.style.display = "none"));
});

<p>クラス名を指定して<code>display:none</code>にしています。</p><p>↓は、左側がもとの状態で右側がクラス名を指定してサイドバーを非表示にして取得したスクショです。</p>

<h2 id="h92d2633638">Basic認証を事前設定する</h2><p><code>httpCredentials</code>を指定するだけなので簡単に設定できます。</p>

const config = {
  use: {
    trace: 'on-first-retry',
    httpCredentials: {
      username: 'Basic認証ユーザ名',
      password: 'Basic認証パスワード',
    },
  },
};
export default config;

<h2 id="h4ae7f02243">今後やりたいこと</h2><p>今回は静的なページを対象にしたスクショ取得を試しましたが、次は<strong>フォームのテストや動的操作の自動化</strong>も試してみたいと思っています。</p><p>Playwright、おもしろい。</p>

<p>📝参考</p><ul><li><a href="https://testomat.io/blog/how-to-capture-screenshots-videos-playwright-js-tutorial/" target="_blank" rel="noopener noreferrer nofollow">How To Capture Screenshots &amp; Videos — Playwright JS Tutorial</a></li><li><a href="https://zenn.dev/frontendflat/articles/b2c98a68ff9687" target="_blank" rel="noopener noreferrer nofollow">Playwrightでサイトマップに記載されたページのスクリーンショットを保存する</a></li><li><a href="https://scrapeops.io/playwright-web-scraping-playbook/nodejs-playwright-take-screenshots/" target="_blank" rel="noopener noreferrer nofollow">Playwright Guide: How To Take Screenshots</a></li></ul>

Playwrightで自動スクリーンショット取得

<p>サイトがダウンしたときに通知してくれるサービスって何かいいのあるかな？と思い、監視サービスをいくつか調べてみました。</p><p>UptimeRobotを紹介している記事をいくつか読んでみて、無料で手軽に使えそうだったので、試してみることにしました。</p><p><span class="txt-small">※この記事ではアカウントの作成は省きます</span></p><h2 id="hc94cb75731">実際に設定してみた</h2><h3 id="h0d2764bff0">ページごとに監視できる</h3><p>試しにこのサイトとBasic認証を設定している別のサイトのそれぞれトップページを登録してみました。</p><p>管理画面がシンプルで、URLを入力するだけで設定完了。</p><p>簡単👀</p><h3 id="h3b51c5eaf3">5分間隔でチェック</h3><p>無料プランだと最短5分間隔。有料にすればもっと短く設定ができ、すぐに検知できますが、お試しなので5分でも十分です。</p><h2 id="hbe03623815">監視：稼働中</h2><p>Current status Upと表示されました。正常にアクセスできています。</p>

<h2 id="h1c721b3b0c">Basic認証を設定しているサイトの監視</h2><p>次にBasic認証を設定しているサイトへの監視する場合です。</p><p>設定画面にて認証情報を登録すると、Basic認証を通過して監視してくれます。</p><h3 id="hb29a6f5be1">認証情報が未登録の場合</h3><p>通過できず401が返ってきます。</p><p>Current status Downと判定された場合、フリープランではメール通知をしてくれます。復旧したときにも通知してくれるので、問題の始まりから終わりまでわかり安心です。</p>

<h3 id="h0d509e4764">認証情報の登録</h3><p>Auth.typeはBasic認証とDigest認証に対応しています。</p>

<h2 id="h24b523d27b">レポート</h2><p>シンプルなダッシュボードなので、瞬時に判断できるところもいいなと思います。一覧では、設定したURLページの状態がまとめて確認できます。</p>

<h2 id="hf6625118dc">使ってみた感想</h2><p>とにかくシンプル・直感的に操作できるのが良かったです🎉</p><p>50ページ分登録できるし5分間隔での監視なので、個人サイトなら十分だなと思います。</p>

UptimeRobot（Freeプラン）でサイトの稼働状況を監視してみる

<p>windowsの7-zipでは問題ない<br>windowsのコンテキストから解凍で文字化け<br>mac環境がないので↓で試す</p><ul><li><strong>✅7-Zip で解凍テストする</strong><ul><li>7-Zip は macOS の Finder に比べて UTF-8 に強いため、<strong>Windows のエクスプローラーで文字化けしても 7-Zip では正しく表示される</strong> 可能性がある。</li><li><strong>7-Zip で解凍して文字化けしないなら macOS でも問題ない</strong> 可能性が高い。</li><li><strong>逆に 7-Zip で文字化けするなら macOS でも文字化けする可能性大。</strong></li></ul></li><li><strong>✅Windows 上の WSL (Ubuntu) でテスト</strong><ul><li><strong>WSL (Windows Subsystem for Linux) に Ubuntu をインストールし、</strong><code>unzip</code> コマンドで解凍テスト</li><li>WSL の Linux 環境は macOS の Finder に近い挙動を示すため、<strong>正しく解凍されるか確認できる</strong>。</li></ul></li><li><strong>手順</strong><ol><li>WSL (Ubuntu) をインストール</li><li><code>unzip</code> コマンドをインストール (<code>sudo apt update &amp;&amp; sudo apt install unzip</code>)</li><li><code>unzip sample.zip -d test_folder/</code> で解凍してファイル名を確認</li></ol></li><li><strong>✅Mac 風の解凍ツールを試す</strong><ul><li>Windows で UTF-8 の解凍を適切に行うツールを使う</li></ul></li><li><strong>「Explzh（エクスプローラ風アーカイバ）」</strong> は Windows 上で macOS の UTF-8 に近い解凍挙動を持つ<ul><li><strong>Explzh</strong> → <a href="https://www.ponsoftware.com/" target="_blank" rel="noopener noreferrer">公式サイト</a></li><li><strong>「WinRAR」</strong> も試す価値あり。</li></ul></li><li><strong>✅オンラインの解凍ツールを使う</strong><ul><li>macOS の Finder での解凍と似た挙動のオンラインツールを使う</li><li>例: unzip-online.com</li></ul></li><li><strong>試してない｜仮想環境で macOS を動かす</strong><ul><li>最も確実なのは macOS の仮想環境を作る方法</li></ul></li><li>Windows で macOS を仮想マシンで動かせるツール：<ul><li><strong>「macOS-Simple-KVM」</strong> (Linux の KVM 上で macOS を動かす)</li><li><strong>「VMware Workstation」</strong>（macOS の ISO イメージが必要）</li></ul></li></ul><pre><code>        const blob = await zip.generateAsync({
          type: "blob",
          compression: "STORE",</code></pre><p>DEFLATEにしたら透過部分が透過だけど黒はいって圧縮かかってしまったので、STOREに変更<br>jszipのオプションです　STORE<br><a href="https://stuk.github.io/jszip/documentation/api_jszip/generate_async.html#compression-and-compressionoptions-options" target="_blank" rel="noopener noreferrer">https://stuk.github.io/jszip/documentation/api_jszip/generate_async.html#compression-and-compressionoptions-options</a></p>

<p>作成したFigmaプラグインで画像をZIP形式でエクスポートした際、日本語ファイル名が文字化けする問題に遭遇しました。</p><p>制作環境はWindowsで複数のツールで解凍を試すとツールによって文字化けしたりしなかったり...</p><p>またMac環境がないために完全な動作検証ができない状況でした。</p><p>そこで、Windows環境でできる限りの検証方法を試し、どのツールなら正しく解凍できるのか、またMacでの解凍結果を推測できる方法を探してみました。</p><h2 id="hd2325f5250">ZIP解凍時の文字化けとは？</h2><p>ZIPファイルは圧縮時の文字エンコーディングが環境によって異なるため、特に日本語ファイル名を含むZIPを異なるOSで解凍すると文字化けが発生することがあります。</p><p>Windowsの標準エクスプローラーはShift-JISベースの処理を行うため、UTF-8でエンコードされたZIPファイルを正しく扱えない場合があります。逆に、macOSのFinderはUTF-8を標準としているため、Windowsで作成したZIPを解凍すると文字化けすることがあります。</p><h2 id="h154d2be008">Windows環境でMacの解凍結果を予測する方法</h2><p>Mac環境が手元になくても、以下の方法でZIP解凍時の文字化けを事前に確認できます。</p><h3 id="h239ad9fe75">1. 7-Zip で解凍テストする</h3><p>7-ZipはWindowsのエクスプローラーよりもUTF-8に強いため、文字化けしにくいツールです。</p><ul><li>もし7-Zipで正常に解凍できれば、Macでも問題なく解凍できる可能性が高い。</li><li>逆に7-Zipで文字化けする場合、Macでも同様に文字化けする可能性が高い。</li></ul><h3 id="h3eaee0324b">2. Windows 上の WSL (Ubuntu) でテスト</h3><p>Windows Subsystem for Linux (WSL) のUbuntu環境で解凍テストを行うと、macOSに近い動作を確認できます。</p><h4 id="hf8bcafd588">手順：</h4><ol><li>WSL (Ubuntu) をインストール</li><li>unzip コマンドをインストール<pre><code>sudo apt update &amp;&amp; sudo apt install unzip</code></pre></li><li>ZIPを解凍してファイル名を確認<pre><code>unzip sample.zip -d test_folder/</code></pre></li></ol><p>WSLのLinux環境はmacOSのFinderと近い挙動を示すため、この方法で解凍結果を確認できます。</p><h3 id="hef414b6b17">3. Mac風の解凍ツールを試す</h3><p>Windows上でUTF-8の解凍を適切に行うツールを試します。</p><ul><li><strong>Explzh（エクスプローラ風アーカイバ）</strong><ul><li>WindowsでmacOSのUTF-8に近い挙動を持つ解凍ツール。</li></ul></li><li><strong>WinRAR</strong><ul><li>ZIPのエンコーディング処理が異なるため、文字化けを回避できる可能性あり。</li></ul></li></ul><h3 id="h2edf506c9e">4. オンラインの解凍ツールを使う</h3><p>オンラインのZIP解凍ツールを使うことで、macOSのFinderで解凍した時と似た挙動を再現できます。</p><p><strong>例:</strong></p><ul><li><a href="https://www.unzip-online.com/" target="_blank" rel="noopener noreferrer nofollow">unzip-online.com</a></li></ul><h3 id="h4f32634529">5. 仮想環境でmacOSを動かす（未検証）</h3><p>最も確実な方法はmacOSの仮想環境を作ることですが、セットアップの手間がかかるため今回は試していません。</p><ul><li><strong>macOS-Simple-KVM</strong> (LinuxのKVM上でmacOSを動かす)</li><li><strong>VMware Workstation</strong>（macOSのISOイメージが必要）</li></ul><h2 id="hd01752ae03">FigmaのZIPエクスポート時の文字化け対策</h2><p>作成したFigmaプラグインはJSZipを使ってZIPファイルを生成しました。</p>

const blob = await zip.generateAsync({
  type: "blob",
  compression: "STORE",
});

<h3 id="h3264c1197c">圧縮方式の違い</h3><ul><li><strong>DEFLATE（デフォルト）</strong><ul><li>圧縮率が高いが、透過画像の一部が黒くなる問題が発生した。</li></ul></li><li><strong>STORE（非圧縮）</strong><ul><li>圧縮はされないが、透過部分の問題が解決。</li></ul></li></ul><p>そのため、<strong>今回は「STORE」オプションを使用してZIPを作成</strong>しました。</p><h2 id="ha214098e44">まとめ</h2><ul><li>ZIP解凍時の文字化けは、OSごとのエンコーディング処理の違いが原因。</li><li>Mac環境がなくても、<strong>7-Zip・WSL・Explzh・オンラインツールを使って動作確認</strong>できる。</li><li>FigmaのJSZipエクスポート時に「STORE」オプションを使うことで、透過画像の問題を回避。</li></ul><p>WindowsユーザーでもMac環境なしで検証できる方法を知っておくと、ZIPの互換性問題に対応しやすくなります。</p>

WindowsでZIPの文字化けを検証・Mac環境なしで試せる解凍方法まとめ

<p>ヘッドレスCMSやJamstack構成でよく使われるフレームワークで制作されたWebサイトでは、どのようなフォームが利用されているのか調査してみました。</p><p>調査対象は以下の2種類です。</p><ol><li>Webサイトギャラリー81-web.comの<a href="https://81-web.com/tag/astro" target="_blank" rel="noopener noreferrer nofollow">Astro</a>/<a href="https://81-web.com/tag/next" target="_blank" rel="noopener noreferrer nofollow">Next.js</a>/<a href="https://81-web.com/tag/nuxt" target="_blank" rel="noopener noreferrer nofollow">Nuxt.js</a>のカテゴリに属するWebサイトのお問い合わせフォーム（84サイト）</li><li>microCMSの<a href="https://microcms.io/partners/" target="_blank" rel="noopener noreferrer nofollow">パートナー企業</a>のWebサイトのお問い合わせフォーム（56サイト）</li></ol><p><span class="txt-small">※2025.1.26時点の掲載サイトから確認</span><br><span class="txt-small">※「フォームがないサイト」の数はグラフから除外</span></p>

<h2 id="hae492bb6b2">1. Webサイトギャラリー81-web.com</h2>

<h2 id="h7a5ff87729">2. microCMSのパートナー企業</h2>

<h2 id="h7e984ac5d3">👀見えてきたこと</h2><h3 id="h98b4be6866">Next.jsやNuxt.jsなどのサイトでは外部サービスの利用か判断がむつかしい</h3><p>Next.jsやNuxt.jsで構築されたサイトでは、フォームが外部のサービスを利用しているのか、独自に実装されているのか判断ができませんでした。多くのケースでは、フォームの送信先や処理方法が公開されていないためです。</p><h3 id="h77aa70f29a">Googleフォームの利用は少数ながら一定数存在</h3><p>Googleフォームは比較的簡単に設置できるため、一部のサイトでは利用されていました。特に、ヘッダー画像を設定すれば、デザイン的にも違和感が少なくなるため、簡易的なフォームとしては十分な印象を受けました。</p><h3 id="he2e1521221">HubSpotの利用が一定数存在</h3><p>企業向けのマーケティングツールであるHubSpotをフォームとして利用しているサイトが一定数見られました。特にmicroCMSのパートナー企業のサイトでは9件と、比較的高い採用率を示しています。</p><h3 id="h09cccba78a">フォームが存在しないサイトも多い</h3><p>Webサイトによっては、お問い合わせフォームを設置せず、メールアドレスのみを記載しているケースや、そもそも問い合わせ手段を設けていないサイトも一定数ありました。特にWebリンク集サイトに掲載されているサイトでは、メールアドレスの記載が10件と、フォームを設置しない選択をしているサイトも少なくありませんでした。</p><h2 id="ha214098e44">まとめ</h2><p>Jamstack構成のWebサイトにおけるフォームの利用状況を調査した結果、Next.jsやNuxt.jsを利用したフォームが多く見られましたが、外部サービスを利用しているかどうかの判断が難しいケースもありました。</p><p>Googleフォームの利用は少数派ながらも一定の需要があり、HubSpotのようなマーケティングツールを活用したフォームの導入も見られました。一方で、フォーム自体を設置しないサイトも少なくなく、サイトの目的に応じて異なる選択肢が取られていることがわかりました。</p><p>今後、Jamstackサイトにおけるフォーム実装のトレンドを追いながら、より効果的な導入方法を検討していくのも興味深いテーマになりそうです。</p>

フォームなしもあり？Webサイトのお問い合わせの実態を探る

<p>もし <code>0.1.x</code> を使用しているユーザーには <code>0.1.10</code> にアップグレードさせる必要があるので、<code>"0.1.x"</code> に対して <code>"0.1.10"</code> を指定します。<br>それ以外のユーザーには <code>8.0.0</code> にアップグレードさせる必要があるので、 <code>"*" </code>もしくは <code>"^0.1.10"</code> 以外のバージョンを持つすべてのユーザーに対して <code>"8.0.0"</code> を指定します。</p><h3 id="h3a193bd26b">2. <code>resolutions</code>フィールドを使って全体でバージョンを上げる（npm 7以降は対応）</h3><p>複数の依存関係のサブ依存も含めて、特定のパッケージのバージョンを一括で上げたい場合、<code>yarn</code>や<code>npm 7</code>以上の環境では、<code>package.json</code>に<code>resolutions</code>フィールドを追加して、特定のパッケージのバージョンを指定できます。</p><ol><li><code>package.json</code>ファイルに次のように<code>resolutions</code>フィールドを追加します。</li></ol><pre><code>json</code></pre><p>コードをコピーする<br><code>"resolutions": { "&lt;package-name&gt;": "&lt;version&gt;" }</code><br>たとえば、<code>lodash</code>のバージョンを最新の安定版にする場合：</p><pre><code>json</code></pre><p>コードをコピーする<br><code>"resolutions": { "lodash": "^4.17.21" }</code></p><ol><li><code>npm install</code>を実行して、<code>resolutions</code>で指定されたバージョンがインストールされるようにします。</li></ol><h3 id="h4d9bc145ea">3. <code>npm-force-resolutions</code>を使ってサブ依存を強制的にアップデートする</h3><p><code>npm</code>では、サブ依存パッケージのバージョンを強制的に上げるために<code>npm-force-resolutions</code>を使うことができます。</p><ol><li><code>npm-force-resolutions</code>をインストール：</li></ol><pre><code>bash</code></pre><p>コードをコピーする<br><code>npm install npm-force-resolutions --save-dev</code></p><ol><li><code>package.json</code>に<code>resolutions</code>フィールドを追加して、特定のパッケージをアップデート：</li></ol><pre><code>json</code></pre><p>コードをコピーする<br><code>"resolutions": { "&lt;package-name&gt;": "&lt;version&gt;" }</code><br>例として、<code>lodash</code>をアップデートする場合：</p><pre><code>json</code></pre><p>コードをコピーする<br><code>"resolutions": { "lodash": "^4.17.21" }</code><br><a href="https://qiita.com/masato_makino/items/20d4fcfc9c05bd3907da" target="_blank" rel="noopener noreferrer">https://qiita.com/masato_makino/items/20d4fcfc9c05bd3907da</a><br></p><ol><li><code>preinstall</code>スクリプトに<code>npm-force-resolutions</code>を追加：</li></ol><pre><code>json</code></pre><p>コードをコピーする<br><code>"scripts": { "preinstall": "npx npm-force-resolutions" }</code></p><ol><li>最後に<code>npm install</code>を実行して依存関係を更新：</li></ol><pre><code>bash</code></pre><p>コードをコピーする<br><code>npm install</code></p><h3 id="haf7a501fd0">4. 手動で依存パッケージのバージョンを調整</h3><p>直接依存しているパッケージのバージョンを個別に上げる場合、<code>package.json</code>内の依存パッケージを直接編集し、バージョンを更新することもできます。</p><pre><code>bash</code></pre><p>コードをコピーする<br><code>npm install &lt;package-name&gt;@latest</code><br>これにより、プロジェクト全体で特定のパッケージを最新版にすることができますが、サブ依存関係も影響を受ける場合がありますので、その際は<code>resolutions</code>を活用します。</p><h3 id="h5fe0caba45">5. テストと確認</h3><p>依存関係をアップデートした後は、必ずビルドとテストを実行して、プロジェクトが問題なく動作するか確認してください。<br>これらの方法で、プロジェクト全体で特定のパッケージのバージョンをアップデートできます。<br><br>エラーの中身を確認する<br>npm audit fixすればなおる！とあったのでやってみたけど減らなかった</p><pre><code># postcss はコマンドでは自動で直せないことを示している
No fix available
# semver は npm audit fix --force コマンドで修正できることを示している
fix available via `npm audit fix`
# word-wrap は npm audit fix コマンドで修正できることを示している
fix available via `npm audit fix --force`</code></pre><p><br></p>

<p>この備忘録ブログサイトを作ってから、パッケージの追加やアップデートは何度かしてきましたが、全体をしっかり見直すことはしていませんでした。<br>今回は、npmパッケージをまとめてバージョンアップデートしてみることに。</p><p>いくつかの記事を参考にしながら、自分なりに進めてみた備忘録です。</p>

<h2 id="h0bc54e2937">まずはnpm-check-updates</h2><p><a href="https://www.npmjs.com/package/npm-check-updates" target="_blank" rel="noopener noreferrer nofollow">npm-check-updates</a>はプロジェクトにインストールされているnpmパッケージのバージョンを一括で確認・更新することができます。</p>

# グローバルインストール
npm install -g npm-check-updates

# パッケージのバージョン確認
ncu

<p><code>ncu</code>（npm-check-updates）を実行すると、以下の情報が表示されます。</p><ol><li><strong>現在のバージョン</strong><br>プロジェクトにインストールされている各パッケージの現在のバージョン</li><li><strong>最新のバージョン</strong><br>各パッケージの最新バージョンが表示され、どのパッケージが更新可能かを把握できる</li><li><strong>更新が必要なパッケージの一覧</strong><br>どのパッケージを更新する必要があるかが一目でわかる</li></ol><table><tbody><tr><th colspan="1" rowspan="1"><p>文字色</p></th><th colspan="1" rowspan="1"><p>意味</p></th></tr><tr><td colspan="1" rowspan="1"><p>🔴赤</p></td><td colspan="1" rowspan="1"><p>メジャーアップグレード／major upgrade</p></td></tr><tr><td colspan="1" rowspan="1"><p>🔵青</p></td><td colspan="1" rowspan="1"><p>マイナーアップグレード／minor upgrade</p></td></tr><tr><td colspan="1" rowspan="1"><p>🟢緑</p></td><td colspan="1" rowspan="1"><p>パッチのアップグレード／patch upgrade</p></td></tr></tbody></table><h3 id="hdc7579b318">アップデートの実施：パッチからマイナーバージョンへ</h3><p>一気にすべてのパッケージをアップデートするのが不安だったので、まずはパッチバージョンだけをアップデートすることにしました。</p>

<p>アップデートが完了した後、変更をコミットし、デプロイを実行。</p><h4 id="hd15c229cf0">デプロイでこける😱</h4><p>npm installを実行してなかった..<br>package-lock.jsonを更新し、package.jsonと整合性を取る。</p><p>デプロイできた！</p>

<p>問題がなかったので次はマイナーバージョンをアップデート。</p>

<p><strong>📝参考</strong></p><ul><li><a href="https://qiita.com/nekyo/items/19be05578638fe3e4aec" target="_blank" rel="noopener noreferrer nofollow">【Mac+Node】Mac に node.js（と Python2）をインストール。時々 ncu。</a></li></ul>

<h2 id="h1003736836">パッケージのアップデートとknipの活用</h2><p>パッケージのアップデートを行ったものの、使ってないパッケージやプロジェクト内の整理できてなかった‥</p><p>これを機にknipを使って未使用のコードや依存関係を整理してみました。</p><blockquote><p>Knip finds <strong>unused files, dependencies and exports</strong> in your JavaScript and TypeScript projects. Less code and dependencies lead to improved performance, less maintenance and easier refactorings.</p><p>Knip は、JavaScript および TypeScript プロジェクト内の未使用のファイル、依存関係、エクスポートを検出します。コードと依存関係が少ないほど、パフォーマンスが向上し、メンテナンスが減り、リファクタリングが容易になります。</p><p><a href="https://github.com/webpro-nl/knip" target="_blank" rel="noopener noreferrer nofollow">https://github.com/webpro-nl/knip</a></p></blockquote><p>パッケージを入れて確認‥👀</p>

# インストール
npm install -D knip

# 実行
npx knip

# オプションを使うとmarkdownのレポート形式で出してくれる
npx knip --reporter markdown

<p>たくさん該当しました😂</p><p>使用していないファイル、パッケージ、型など削除します。</p><table><tbody><tr><th colspan="1" rowspan="1"><p>項目</p></th><th colspan="1" rowspan="1"><p>説明</p></th></tr><tr><td colspan="1" rowspan="1"><p>Unused files</p></td><td colspan="1" rowspan="1"><p>プロジェクト内で参照されていないファイル</p></td></tr><tr><td colspan="1" rowspan="1"><p>Unused dependencies</p></td><td colspan="1" rowspan="1"><p>インストールされているが、コードで使用されていないパッケージ</p></td></tr><tr><td colspan="1" rowspan="1"><p>Unused devDependencies</p></td><td colspan="1" rowspan="1"><p>開発環境でインストールされたが、プロジェクト内で使用されていない開発用パッケージ</p></td></tr><tr><td colspan="1" rowspan="1"><p>Unlisted binaries</p></td><td colspan="1" rowspan="1"><p><code>package.json</code>に記載されていない実行可能なバイナリファイル。</p></td></tr><tr><td colspan="1" rowspan="1"><p>Unused exports</p></td><td colspan="1" rowspan="1"><p>モジュールからエクスポートされているが、他のモジュールで参照されていないエクスポート</p></td></tr><tr><td colspan="1" rowspan="1"><p>Unused exported types</p></td><td colspan="1" rowspan="1"><p>型定義ファイルからエクスポートされているが、他のコードで使用されていない型</p></td></tr></tbody></table><h4 id="hbeb24e1e68">消したら動かなくなった😱</h4><p><code>image/loader.js</code>が未使用ファイルとして検出され、誤って削除してしまった。</p><p>今後同じような問題を避けるために、以下の手順で設定を変更することにしました。</p>

{
  "entry": [
    "image/loader.js",
    "next-sitemap.config.js"
  ]
}

<p>entryに指定されたファイルを未使用ファイルとしてマークしないため、検知されたくないファイルを指定しました！</p><h4 id="he16f0ec8e4">整理できた！</h4><pre><code>✂️  Excellent, Knip found no issues.</code></pre><p>📝<strong>参考</strong></p><ul><li><a href="https://tech.basemachina.jp/entry/introduction-knip" target="_blank" rel="noopener noreferrer nofollow">TypeScript/JavaScriptの不要なコードを削除するツール「Knip」の紹介</a></li><li><a href="https://zenn.dev/roboin/articles/3dfc5eba5433ba" target="_blank" rel="noopener noreferrer nofollow">不要なexportや依存関係を削除できるKnipの使い方</a></li></ul>

<h2 id="h10e8f9edeb">npm auditでセキュリティ脆弱性を確認</h2><p>npm auditを実行したらcriticalはありませんでしたが、highが10個も該当しました😓</p><p>23 vulnerabilities (4 low, 5 <span style="color: #d99200">moderate</span>, 10 <span style="color: #ff0000">high</span>)</p><table><tbody><tr><th colspan="1" rowspan="1"><p>レベル</p></th><th colspan="1" rowspan="1"><p>内容</p></th></tr><tr><td colspan="1" rowspan="1"><p>critical</p></td><td colspan="1" rowspan="1"><p>非常に危険な脆弱性</p></td></tr><tr><td colspan="1" rowspan="1"><p>high</p></td><td colspan="1" rowspan="1"><p>深刻な脆弱性</p></td></tr><tr><td colspan="1" rowspan="1"><p>moderate</p></td><td colspan="1" rowspan="1"><p>影響のある脆弱性</p></td></tr><tr><td colspan="1" rowspan="1"><p>low</p></td><td colspan="1" rowspan="1"><p>低リスクの脆弱性</p></td></tr></tbody></table>

# npm audit report

axios  0.8.1 - 0.27.2 || 1.3.2 - 1.7.3
Severity: high
Axios Cross-Site Request Forgery Vulnerability - https://github.com/advisories/GHSA-wf5p-g6vw-rhxx
Server-Side Request Forgery in axios - https://github.com/advisories/GHSA-8hc4-vh64-cxmj
fix available via `npm audit fix --force`
Will install @sendgrid/client@8.1.4, which is a breaking change
node_modules/@sendgrid/client/node_modules/axios
node_modules/axios
  @sendgrid/client  7.0.0 - 7.7.0
  Depends on vulnerable versions of axios
  node_modules/@sendgrid/client
    @sendgrid/mail  7.0.0 - 7.7.0
    Depends on vulnerable versions of @sendgrid/client
    node_modules/@sendgrid/mail

braces  <3.0.3
Severity: high
Uncontrolled resource consumption in braces - https://github.com/advisories/GHSA-grv7-fg5c-xmjg
fix available via `npm audit fix`
node_modules/braces

cookie  <0.7.0
cookie accepts cookie name, path, and domain with out of bounds characters - https://github.com/advisories/GHSA-pxg6-pf52-xh8x
No fix available
node_modules/cookie
  @cloudflare/next-on-pages  *
  Depends on vulnerable versions of cookie
  node_modules/@cloudflare/next-on-pages
  youch  2.0.4 - 3.3.3
  Depends on vulnerable versions of cookie
  node_modules/youch

…続く

<p>npm auditを実行して大量の情報が表示されると、おお、、これ全部か……↘</p><h3 id="h0a4eb18963">どんな情報が出力されている？</h3><p>dompurifyを見てみます。</p>

dompurify  3.0.0 - 3.1.2
Severity: high
DOMPurify allows tampering by prototype pollution - https://github.com/advisories/GHSA-mmhx-hmjr-r674
DOMpurify has a nesting-based mXSS - https://github.com/advisories/GHSA-gx9m-whjm-85jf
fix available via `npm audit fix`
node_modules/dompurify

<p>dompurify パッケージの 3.0.0 から 3.1.2 に関する脆弱性が報告されていて、2つの脆弱性が詳細リンクと一緒に記載されている。</p><p>npm audit fix を使用することで修正が可能である旨が表示され、最後に影響のあるパッケージのファイルパス（node_modules 配下の dompurify）も記載されている。</p><h3 id="hda65cb0310">npm audit レポートの構成</h3><table><tbody><tr><th colspan="1" rowspan="1"><p>セクション</p></th><th colspan="1" rowspan="1"><p>説明</p></th></tr><tr><td colspan="1" rowspan="1"><p>パッケージ情報</p></td><td colspan="1" rowspan="1"><p>対象のパッケージ名と影響を受けるバージョン範囲</p></td></tr><tr><td colspan="1" rowspan="1"><p>Severity（深刻度）</p></td><td colspan="1" rowspan="1"><p>脆弱性の深刻度</p></td></tr><tr><td colspan="1" rowspan="1"><p>脆弱性の詳細</p></td><td colspan="1" rowspan="1"><p>脆弱性の名称と内容、影響範囲の概要</p></td></tr><tr><td colspan="1" rowspan="1"><p>Advisory URL</p></td><td colspan="1" rowspan="1"><p>各脆弱性の詳細情報へのリンク</p></td></tr><tr><td colspan="1" rowspan="1"><p>修正方法</p></td><td colspan="1" rowspan="1"><p>npm audit fix による自動修正方法や推奨バージョンへのアップデート案内</p></td></tr><tr><td colspan="1" rowspan="1"><p>パス情報</p></td><td colspan="1" rowspan="1"><p>対象のパッケージの場所<br>依存関係の深いパスもここにリストされる</p></td></tr></tbody></table><h3 id="h5fa47394a1">修正してみる</h3><p>fix available via <code>npm audit fix</code>とあるので、<code>npm audit fix dompurify</code>を実行してみます。</p><p>17 vulnerabilities (3 low, 4 moderate, 10 high)</p><p>dompurifyのhighが消えて、npm auditレポートの該当件数も減りました！</p><p>npm audit fixで解消されるパッケージは、まとめて対応しました。</p><h2 id="hb3073dfb6d">npm audit fixでは解決できないパッケージ</h2><p>path-to-regexpを見てみます。</p>

path-to-regexp  4.0.0 - 6.2.2
Severity: high
path-to-regexp outputs backtracking regular expressions - https://github.com/advisories/GHSA-9wv6-86v2-598j
fix available via `npm audit fix`
node_modules/@vercel/routing-utils/node_modules/path-to-regexp
node_modules/path-to-regexp
  @vercel/node  >=2.11.0
  Depends on vulnerable versions of path-to-regexp
  node_modules/@vercel/node
  @vercel/routing-utils  *
  Depends on vulnerable versions of path-to-regexp
  node_modules/@vercel/routing-utils
    @vercel/gatsby-plugin-vercel-builder  *
    Depends on vulnerable versions of @vercel/routing-utils
    node_modules/@vercel/gatsby-plugin-vercel-builder
      @vercel/static-build  >=1.3.0
      Depends on vulnerable versions of @vercel/gatsby-plugin-vercel-builder
      node_modules/@vercel/static-build
    @vercel/redwood  >=0.6.1-canary.0
    Depends on vulnerable versions of @vercel/routing-utils
    node_modules/@vercel/redwood

<p>npm audit fix path-to-regexpを実行してみましたが、解消されません。</p><p>出力された脆弱性の詳細情報を確認してみます。</p><blockquote><p>path-to-regexp outputs backtracking regular expressions - <a href="https://github.com/advisories/GHSA-9wv6-86v2-598j">https://github.com/advisories/GHSA-9wv6-86v2-598j</a></p><p>path-to-regexp が出力する正規表現にはバックトラッキングが含まれており、悪意のある入力に対して正規表現の評価が長時間かかる可能性があります。</p></blockquote><blockquote><p>path-to-regexp outputs backtracking regular expressions<br>For users of 0.1, upgrade to 0.1.10. All other users should upgrade to 8.0.0.</p><p>0.1 のユーザーは 0.1.10 にアップグレードしてください。その他のすべてのユーザーは 8.0.0 にアップグレードする必要があります。</p></blockquote><p>8.0.0にする必要がありそうです。</p><h3 id="h8594afbbc5">npm lsで依存関係を確認</h3><p>npm ls path-to-regexpを実行。</p>

├─┬ @cloudflare/next-on-pages@1.13.5
│ └─┬ vercel@37.12.1
│   ├─┬ @vercel/fun@1.1.0
│   │ └─┬ path-match@1.2.4
│   │   └── path-to-regexp@1.9.0
│   ├─┬ @vercel/node@3.2.23
│   │ └── path-to-regexp@6.2.1
│   └─┬ @vercel/redwood@2.1.8
│     └─┬ @vercel/routing-utils@3.1.0
│       └── path-to-regexp@6.1.0
└─┬ wrangler@3.78.5
  └── path-to-regexp@6.3.0

<h3 id="h9354bfba43">具体的な依存関係</h3><p>@cloudflare/next-on-pages@1.13.5 パッケージが、以下のパッケージを持っている。</p><ul><li>vercel@37.12.1<ul><li>@vercel/fun@1.1.0: path-match@1.2.4 から path-to-regexp@1.9.0 に依存している。</li><li>@vercel/node@3.2.23: path-to-regexp@6.2.1 に依存している。</li><li>@vercel/redwood@2.1.8: @vercel/routing-utils@3.1.0 から path-to-regexp@6.1.0 に依存している。</li></ul></li></ul><p>👉特定のパッケージが他のパッケージに依存している状態</p><h3 id="he411664183">直接の依存関係</h3><p>wrangler@3.78.5 パッケージが path-to-regexp@6.3.0 に依存している。</p><p>👉プロジェクトが直接インストールしたパッケージ</p><h3 id="hebf37af91f">該当パッケージのバージョンを最新にしてみる</h3><p>@cloudflare/next-on-pagesとwranglerのパッケージを最新にアップデートしましたが、Severity: highのままでした。</p>

<h2 id="ha4650c7ed2">特定のパッケージとそのサブ依存のバージョンを一括で上げる</h2><p>npmの場合は依存関係ツリーをpackage.jsonで上書きするoverridesオプションがあります。</p><blockquote><p><strong>overrides</strong></p><p>If you need to make specific changes to dependencies of your dependencies, for example replacing the version of a dependency with a known security issue, replacing an existing dependency with a fork, or making sure that the same version of a package is used everywhere, then you may add an override.</p><p><a href="https://docs.npmjs.com/cli/v9/configuring-npm/package-json#overrides" target="_blank" rel="noopener noreferrer nofollow">https://docs.npmjs.com/cli/v9/configuring-npm/package-json#overrides</a></p></blockquote><p>package.jsonにpath-to-regexpのバージョンを8.0.0で固定します。</p>

{
  //略
  "overrides": {
    "path-to-regexp": "8.0.0"
  }
}

<p>追加したあとに<code>npm install</code>を実行。</p><p>17 vulnerabilities (4 low, 6 <span style="color: #d99200">moderate</span>, 7 <span style="color: #ff0000">high</span>)</p><p>highが10→7に減りました！</p><p><code>npm ls path-to-regexp</code>を確認してみる。</p>

├─┬ @cloudflare/next-on-pages@1.13.5
│ └─┬ vercel@37.4.2
│   ├─┬ @vercel/fun@1.1.0
│   │ └─┬ path-match@1.2.4
│   │   └── path-to-regexp@8.0.0 deduped
│   ├─┬ @vercel/node@3.2.14
│   │ └── path-to-regexp@8.0.0 deduped
│   └─┬ @vercel/redwood@2.1.5
│     └─┬ @vercel/routing-utils@3.1.0
│       └── path-to-regexp@8.0.0 deduped
└─┬ wrangler@3.83.0
  └── path-to-regexp@8.0.0 overridden

<h3 id="h9f572c40b1">残りのhighのパッケージもアップデート</h3><h4 id="he48ac23e5c">semver</h4>

semver  6.0.0 - 6.3.0 || 7.0.0 - 7.5.1
Severity: high
semver vulnerable to Regular Expression Denial of Service - https://github.com/advisories/GHSA-c2qf-rxjj-qqgw
semver vulnerable to Regular Expression Denial of Service - https://github.com/advisories/GHSA-c2qf-rxjj-qqgw
fix available via `npm audit fix`
node_modules/@vercel/fun/node_modules/semver
node_modules/eslint-plugin-jsx-a11y/node_modules/semver

<p>出力された情報の参照先に以下のバージョン以上に更新するようにと書いてあります。</p><ul><li>7.x ブランチ: 7.5.2 以上</li><li>6.x ブランチ: 6.3.1 以上</li><li>5.x ブランチ: 5.7.2 以上</li></ul><p>package.jsonのoverridesで7.5.2以上を設定。</p>

{
  //略
  "overrides": {
    "path-to-regexp": "8.0.0",
    "semver": ">=7.5.2"
  }
}

<h4 id="h9189d9ec57">next</h4><p>dependenciesのパッケージなので、nextはインストールしているバージョンをアップデートします。</p>

next  10.0.0 - 14.2.6
Severity: high
Next.js Server-Side Request Forgery in Server Actions - https://github.com/advisories/GHSA-fr5h-rqp8-mj6g
Denial of Service condition in Next.js image optimization - https://github.com/advisories/GHSA-g77x-44xx-532m
fix available via `npm audit fix --force`
Will install next@15.0.1, which is a breaking change
node_modules/next

<p>SSRFはv13.5.7・v14.2.10以降で、イメージ最適化はv14.2.7以降と..</p>

<p>9 vulnerabilities (3 low, 6 <span style="color: #d99200">moderate</span>)</p><p>highが全部消えた！</p><p>（こまめに動作するか確認を挟んでましたが）最後に動作確認をして完了です。</p><h2 id="had7a21d220">実際にやってみて</h2><ul><li>定期的にアップデートしないとまとめて実施するのが辛い。そもそもプロジェクト全体の健全性を保つためには、定期的に対応すべき。</li><li>パッケージの中のパッケージ＝サブ依存関係の確認方法やアップデート方法が学びになった。</li><li>npm audit の中身が読めるようになると、とっつきにくさは軽減される。<p></p></li></ul><p>📝参考</p><ul><li><a href="https://qiita.com/alfe_below/items/1141ec9acbb81b504855" target="_blank" rel="noopener noreferrer nofollow">package.json dependencies メンテの仕方 最短ルート</a></li><li><a href="https://zenn.dev/tm35/articles/c170eac0b22f5f" target="_blank" rel="noopener noreferrer nofollow">【npm audit】npm package の脆弱性対応してますか？</a></li><li><a href="https://qiita.com/masato_makino/items/20d4fcfc9c05bd3907da" target="_blank" rel="noopener noreferrer nofollow">依存パッケージの脆弱性修正には、package.jsonのoverrides / resolutionsフィールドを使いましょう</a></li></ul>