はじめに
Knipは、JavaScriptおよびTypeScriptプロジェクトで未使用のファイル、依存関係、エクスポートを検出するツールですね。
GitHubで9,700スター以上、月間1,690万ダウンロードという数字を見ると、急速に普及しているのがわかります。個人的には、プロジェクトのメンテナンスを真剣に考えている人なら導入必須のツールだと思っています。
正直なところ、最初は「未使用コードなんて手動で見つければいいじゃん」と思っていたんですよ。でも実際にKnipを使ってみたら、自分では気づけなかった不要なコードが大量に見つかって、「こんなに放置されてたのか」という感覚でした。
名前の由来は、オランダ語で「カット」を意味する言葉。不要なものをバッサリ切り落とすイメージですね。ライセンスはISCで、安心して使えます。
Knipとは
Knipは「Find unused files, dependencies and exports in your JavaScript and TypeScript projects」を掲げるツールです。コードベースを分析して、以下の3つを検出します。
- 未使用ファイル: どこからも参照されていないソースファイル
- 未使用依存関係: package.jsonにあるけど使われていないパッケージ
- 未使用エクスポート: exportしているけど誰もimportしていない関数・変数
これ、意外と重要で、プロジェクトが大きくなるほど「消し忘れ」が蓄積していくんですよね。リファクタリングで不要になったファイルとか、試しに入れてみたけど結局使わなかったライブラリとか。
特徴・メリット
1. 100以上のプラグインで主要ツールに対応
Knipは単純にimport文を追うだけじゃないんですよ。Astro、Cypress、ESLint、Jest、GitHub Actions、Next.js、Nx、Remix、Storybook、Svelte、Vite、Vitest、Webpackなど、100以上のツールやフレームワークに対応しています。
設定ファイルから依存関係を読み取ったり、テストランナーのパターンを理解したり。だから「設定ファイルでしか使ってないパッケージ」も正しく検出できます。
2. モノレポ対応
pnpm workspacesやnpm workspaces、Lerna、Nx、Turborepoなど、モノレポ構成にも対応しています。複数パッケージ間の依存関係も正しく分析してくれる。
30代になって思うのは、実務で使えるツールは「現実のプロジェクト構成」に対応していることが重要だということ。Knipはその点をしっかり押さえています。
3. 企業での採用実績
Adobe、AWS、Cloudflare、Microsoft、Sentry、Shopify、Vercelなど、大手企業でも採用されています。
印象的だったのは、ある利用者の声:「Knip helped us delete ~300k lines of unused code」。30万行の不要コードを削除できたという話。これはさすがに極端な例だと思いますが、大規模プロジェクトほど効果が出るということですね。
4. 詳細なレポート出力
検出結果をJSON、CSV、テキスト形式で出力できます。CIで使う場合はJSONが便利だし、チームで共有するならテキストが読みやすい。
5. 段階的な修正をサポート
いきなり全部直すのは現実的じゃないことが多い。Knipは特定のルールを無効化したり、特定のファイルを除外したりできるので、段階的にコードベースをクリーンにしていけます。
インストール方法
前提条件
Node.js 18以上を推奨。
プロジェクトへのインストール
# npm
npm install -D knip
# pnpm
pnpm add -D knip
# yarn
yarn add -D knip
# bun
bun add -D knip
シンプルですね。
基本的な使い方
とりあえず実行してみる
npx knip
これだけでプロジェクトを分析して、未使用のファイル・依存関係・エクスポートをレポートしてくれます。ゼロコンフィグで動くのがありがたい。
出力例
Unused files (3)
src/utils/oldHelper.ts
src/components/DeprecatedButton.tsx
src/hooks/useUnused.ts
Unused dependencies (2)
lodash
moment
Unused exports (5)
src/lib/api.ts: unusedFunction
src/lib/api.ts: DEPRECATED_CONSTANT
src/utils/format.ts: formatDate
src/utils/format.ts: formatTime
src/types/index.ts: OldInterface
こんな感じで、どこに何があるか一目瞭然。これ一択ですね。
package.jsonへの追加
{
"scripts": {
"knip": "knip",
"knip:fix": "knip --fix"
}
}
--fixオプションをつけると、可能な範囲で自動修正してくれます。未使用のexportを削除したり、package.jsonから未使用の依存関係を削除したり。
設定ファイルの作成
より細かく制御したい場合は、knip.jsonを作成します。
{
"$schema": "https://unpkg.com/knip@5/schema.json",
"entry": ["src/index.ts", "src/cli.ts"],
"project": ["src/**/*.ts"],
"ignore": ["src/**/*.test.ts", "src/**/*.spec.ts"],
"ignoreDependencies": ["@types/*"]
}
- entry: エントリーポイントとなるファイル
- project: 分析対象のファイルパターン
- ignore: 除外するファイルパターン
- ignoreDependencies: 無視する依存関係
設定がシンプルで見通しが良いのがありがたい。
TypeScript設定との連携
{
"typescript": {
"config": ["tsconfig.json", "tsconfig.build.json"]
}
}
tsconfig.jsonのpathsエイリアスも正しく解釈してくれます。
実践的なユースケース
CI/CDへの統合
GitHub Actionsでの使用例:
name: Code Quality
on: [push, pull_request]
jobs:
knip:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
- run: npm ci
- run: npx knip
PRで未使用コードが増えたらCIで検出できる。これでコードベースが汚れていくのを防げます。
レポートの活用
# JSON形式で出力
npx knip --reporter json > knip-report.json
# 問題数のみ出力(CIでの判定用)
npx knip --reporter summary
コスパ的に、CIでは--reporter summaryを使って、詳細はjsonで別途出力するのがいいと思います。
段階的な導入
既存の大規模プロジェクトにいきなり導入すると、大量のエラーが出て圧倒されることがあります。そういう時は段階的にやるのがおすすめ。
{
"rules": {
"files": "off",
"dependencies": "warn",
"exports": "off"
}
}
まずは依存関係だけチェックして、慣れてきたら範囲を広げていく。
Next.jsプロジェクトでの使用
Next.jsを使っている場合は、自動的にプラグインが適用されます。
{
"next": {
"entry": ["pages/**/*.tsx", "app/**/*.tsx"]
}
}
App RouterもPages Routerも対応しています。getServerSidePropsやgenerateMetadataといったフレームワーク固有のエクスポートも正しく認識してくれる。
モノレポでの使用
{
"workspaces": {
"packages/*": {
"entry": ["src/index.ts"],
"ignoreDependencies": ["shared-config"]
}
}
}
ワークスペースごとに設定をカスタマイズできます。
類似ツールとの比較
正直な比較をしておきます。
| 観点 | Knip | depcheck | unimported |
|---|---|---|---|
| 未使用ファイル | 対応 | 非対応 | 対応 |
| 未使用依存関係 | 対応 | 対応 | 非対応 |
| 未使用エクスポート | 対応 | 非対応 | 非対応 |
| プラグイン数 | 100+ | 少数 | 少数 |
| モノレポ対応 | 充実 | 限定的 | 限定的 |
| 自動修正 | 対応 | 非対応 | 非対応 |
Knipの強みは「3つの観点を統合的にチェックできる」こと。依存関係だけチェックしても、未使用のエクスポートは見つからない。Knipなら一度の実行で全部わかります。
まとめ
Knipを導入して感じた変化:
- コードベース: 確実にスリムになった
- 依存関係: 本当に必要なものだけに整理
- ビルド時間: 不要なコードが減った分、短縮
- 保守性: 「これ使ってるの?」という疑問が減った
- QOL: 確実に上がった
プロジェクトのメンテナンスを真剣に考えているなら、Knip一択ですね。
特に「プロジェクトが大きくなってきて、どこに何があるかわからなくなってきた」という状況なら、導入する価値があります。最初の実行で「こんなに不要なコードあったのか」と驚くと思います。
ただし、検出結果を鵜呑みにして全部削除するのは危険です。動的インポートやリフレクション、設定ファイルからの参照など、静的解析では追えないケースもあるので、削除前には必ず確認しましょう。