Glob テスト — ファイルパスへの **/*.ts パターンマッチ確認

ファイルパスが示す業務のプロジェクト構造

glob パターンをテストするとき、入力するファイルパスは実際のプロジェクトのディレクトリ構造をそのまま反映することが多いです。src/features/billing/stripe-webhook.ts、internal/hr/salary-data/*.csv、/Users/username/projects/client-acme/ のようなパスには、社内プロジェクト名・顧客名・担当領域・ファイルの種別が含まれます。これらをオンラインの glob テスターに貼り付けると、ディレクトリ構成という形でプロジェクト情報が外部サーバーに送信されます。

ファイルパスは一見地味な情報ですが、プロジェクト名と組み合わさった /internal/hr/ や /client-acme/contracts/ といった断片は、組織の業務構造や顧客関係を推測するのに十分な素材になります。ホームディレクトリのパス (/Users/<実名>/... や C:\Users\<実名>\...) を含めて貼るケースでは、開発者個人を特定する情報まで一緒に渡してしまいます。

アップロード型の glob テスターが集めるリクエスト本文

オンラインの glob テスターは「パターンとパスを 2 つの textarea に貼って結果を見る」極めてシンプルな UI ですが、サーバー側ではパターン文字列とパスリストの両方が POST 本文に乗ります。多くのサービスは Cloudflare Workers や Vercel Functions の上に実装されており、上流のクラウド事業者のアクセスログにも同じリクエスト本文が記録される構造になっています。

ファイルパス一覧は「貼ったその瞬間に評価したいだけ」のものですが、外部に送信した記録は事業者側のログ保持ポリシーに従って一定期間残ります。プロジェクト名や顧客名がパスに含まれているなら、その期間中ずっと外部に存在する状態が続くことになります。

picomatch をバンドルしてブラウザ内に閉じる仕組み

このツールは picomatch (MIT、zero-dependency の glob マッチングライブラリ) をビルド時にバンドルしています。glob パターンとファイルパスのマッチング処理はすべてブラウザの JavaScript エンジンで実行され、外部 API への送信は発生しません。生成される等価な正規表現も picomatch の内部ロジックをそのまま JavaScript で実行して取得しています。

nocase / dot / extglob のオプション切替も純粋な picomatch の設定変更で、リクエストを伴いません。DevTools の Network タブを開いてパターンを入力してみると、リクエストがゼロであることを確認できます。

CI/CD 設定の確認チェックリストとして

Vitest の test 設定、Webpack の include / exclude、GitHub Actions の paths フィルター、ESLint の ignorePatterns、TypeScript の include / exclude — いずれも glob 構文を使います。本ツールで実際のファイルパス一覧を貼り付けて「意図したファイルだけにマッチしているか」を確認してから設定値を確定させることで、「思ったファイルがテスト対象に入っていなかった」「本来除外したいファイルが含まれていた」というミスを事前に防げます。等価正規表現の表示は、デバッグ時にパターンの意味を理解するのにも役立ちます。

glob 実装間の構文差異

「glob」と一括りに呼ばれる構文には実は複数の方言があります。bash の glob (shopt -s globstar で ** 有効)、minimatch (npm script の標準)、picomatch (本ツールが使用、Vitest / fast-glob のバックエンド)、Git の pathspec、.gitignore のパターン、TypeScript の include で使われる Microsoft 系 glob などです。共通点は * ? [abc] {a,b} ですが、** の解釈や extglob (@(a|b) !(a)) のサポート、否定パターンの扱いは実装ごとに異なります。

たとえば .gitignore の **/*.log は「任意の深さの .log」ですが、build/**/*.js の先頭 ** は省略可能で build/*.js と等価です。一方 picomatch ではこの省略を有効にするには globstar: true オプションが必要で、デフォルトでは ** は明示的に「ゼロ以上の階層」を要求します。同じパターン文字列が CI ツール間で違う結果を返す原因は、ほぼ常にこの方言差にあります。本ツールは picomatch を採用しているので、Vitest / fast-glob 利用時の挙動と一致します。

頻出する glob の落とし穴

最も多い罠は ドットファイル。デフォルトでは * と ** はドット始まりのファイル名にマッチしません。.eslintrc.json を含めたければ dot: true を有効にするか、明示的に .{*,*/**} のようなパターンを書く必要があります。.gitignore だけはドットファイルを暗黙にマッチさせる例外仕様で、混乱の原因になりがちです。

{a,b,c} ブレース展開は 空要素を許可しない: {a,,b} は壊れたパターンになります。範囲 [a-z] は ロケール依存で、LC_COLLATE の設定次第でアクセント付き文字を含むかが変わる実装もあります。さらに **/foo は foo がトップ階層にあるケースを含むかどうかが実装で割れます (picomatch は含む、Git は含まない)。これらは README を読むだけでは見抜きにくいので、実際のパス一覧を本ツールに貼って事前に確かめるのが最も安全です。glob を等価正規表現に展開した後、その正規表現自体を試したい場合は regex-test でフラグやキャプチャを含めて検証でき、各構造の意味を 1 つずつ言語化したい場面では regex-explain に貼り付けると読み下し説明をローカル生成できます。