--- og_image: "/images/guides/knip-vs-depcheck-2026.webp" title: "Knip vs depcheck: Finding Unused Dependencies in 2026" description: "Knip vs depcheck compared for finding unused npm dependencies and dead code in 2026. Features, TypeScript support, monorepo support, and which dependency." date: "2026-03-08" author: "PkgPulse Team" tags: ["knip", "depcheck", "dependencies", "dead-code", "nodejs", "typescript", "2026"] featured_comparison: "knip-vs-depcheck" --- Knip finds unused files, unused exports, unused dependencies, unlisted dependencies, unused devDependencies, duplicate dependencies, and unresolved imports — in a single run. depcheck finds unused and missing npm dependencies. Knip is a complete codebase hygiene tool; depcheck is a focused dependency scanner. In 2026, knip has become the standard recommendation for modern TypeScript/JavaScript projects — depcheck remains useful for a quick, focused dependency check. ## TL;DR **Knip** for comprehensive codebase analysis in modern TypeScript/JavaScript projects — finds unused files, unused exports, AND unused dependencies in one pass, with support for monorepos, Next.js, Vite, Astro, and most modern tooling. **depcheck** for a quick, zero-config dependency audit when you only care about `package.json` hygiene. For most projects in 2026, knip is the right default — it does everything depcheck does and more. ## Key Takeaways - Knip: Finds unused files, unused exports, unused deps, missing deps, unlisted deps, unused binaries — 7 categories in one pass - depcheck: Finds unused and missing `package.json` dependencies — focused and lightweight - Knip: First-class TypeScript support, monorepo awareness, framework plugins (Next.js, Nuxt, Astro, SvelteKit, Vite) - depcheck: Simpler output, faster for focused dependency-only audits - Knip `--fix`: Automatically removes unused dependencies from `package.json` - Maintenance: Knip is actively maintained; depcheck has slower update cadence - CI integration: Both can run in CI; knip's `--reporter json` makes integration easier ## Why Audit Dependencies? Over time, projects accumulate: ```json // package.json — dependencies nobody is sure about anymore { "dependencies": { "lodash": "^4.0", // Is this still imported anywhere? "moment": "^2.29", // Switched to date-fns months ago "axios": "^1.0", // Replaced with fetch but still in package.json "classnames": "^2.0", // Only one file uses this — is it needed? } } ``` Unused dependencies: - Increase `npm install` time - Increase attack surface (security vulnerabilities in packages you're not using) - Add confusion for new developers ("why is this here?") - Slow down startup in some runtimes ## Knip **Package**: `knip` **GitHub stars**: 8K **Creator**: Lars Kappert Knip performs a full codebase analysis — not just `package.json` scanning, but actual import graph traversal. It knows what files are actually imported, what exports are actually used, and what packages are actually referenced. ### Installation ```bash npm install -D knip # or: npx knip # No install needed ``` ### Basic Usage ```bash npx knip ``` ``` # Example output: Unused files (2) src/utils/legacy-helpers.ts src/components/OldModal.tsx Unused exports (5) src/utils/format.ts: formatCurrency src/api/client.ts: legacyFetch, OldError src/types.ts: DeprecatedConfig, OldEvent Unused dependencies (3) lodash moment axios (in package.json, but not imported anywhere) Unlisted dependencies (1) chalk (imported but not in package.json — missing dep!) ``` ### Configuration ```json // knip.json { "entry": ["src/index.ts", "src/app.tsx"], "project": ["src/**/*.{ts,tsx}"], "ignore": [ "src/legacy/**", "**/*.test.ts" ], "ignoreDependencies": [ "typescript", "@types/*" ] } ``` ### Framework Plugins Knip understands framework-specific conventions — no manual configuration for standard setups: ```bash # Next.js: knip understands app/ router, pages/, API routes, middleware npx knip # Auto-detects Next.js from package.json # Vite: understands vite.config.ts plugins # Astro: understands astro.config.mjs # SvelteKit: understands routes/ # NestJS: understands controllers, services, decorators # Vitest: understands test files as separate entry points ``` ### Auto-Fix ```bash # See what would be fixed: npx knip --fix --dry-run # Auto-remove unused dependencies from package.json: npx knip --fix # This modifies package.json directly: # - Removes unused dependencies # - Removes unused devDependencies # Doesn't touch your source code (for unused exports) ``` ### Monorepo Support ```bash # Knip understands workspace relationships # and cross-package imports in monorepos # knip.json for monorepo: { "workspaces": { "packages/*": { "entry": ["src/index.ts"] }, "apps/*": { "entry": ["src/main.ts"] } } } # Detects: # - Unused packages within a workspace # - Packages exported by one workspace but never imported by another # - Cross-workspace dependency issues ``` ### CI Integration ```yaml # .github/workflows/lint.yml - name: Check for unused code run: npx knip --reporter json | tee knip-report.json # Or fail CI on unused dependencies: - name: Knip check run: npx knip # exits 1 if any issues found ``` ```bash # Reporter options: npx knip --reporter json # Machine-readable JSON npx knip --reporter markdown # For PR comments npx knip --reporter compact # Minimal output ``` ### What Knip Reports ```bash npx knip --help # Knip analyzes these categories (all configurable): # --include files — unused files # --include exports — unused named exports # --include types — unused exported types # --include nsExports — unused namespace exports # --include classMembers — unused class members # --include enumMembers — unused enum members # --include duplicates — duplicate exports across files # --include dependencies — unused dependencies # --include devDependencies — unused devDependencies # --include optionalPeer — unused optional peer deps # --include binaries — unused CLI binaries (in package.json "bin") # --include unresolved — unresolved imports ``` ### Knip Limitations - More configuration needed for unusual project structures - Can produce false positives for dynamically-imported or runtime-resolved modules - Slower than depcheck (full import graph analysis vs package.json scan) - Learning curve for knip's configuration and `ignore` patterns ## depcheck **Package**: `depcheck` **GitHub stars**: 4.5K **Weekly downloads**: 400K+ depcheck is a focused dependency auditing tool. It scans your source files for `require()` and `import` statements, then cross-references against `package.json`. Fast and simple. ### Installation ```bash npm install -D depcheck # or: npx depcheck # No install needed ``` ### Basic Usage ```bash npx depcheck ``` ``` # Example output: Unused dependencies * lodash * moment * axios Unused devDependencies * @types/node Missing dependencies * chalk (used in src/cli.ts but not in package.json) ``` ### Configuration ```json // .depcheckrc (JSON) { "ignorePatterns": [ "dist", "coverage", ".next" ], "ignores": [ "typescript", "@types/node", "prettier", "eslint" ], "detectors": [ "requireCallExpression", "importDeclaration", "importCallExpression" ] } ``` ### Use Cases Where depcheck Wins ```bash # Quick scan before a PR — just want to know if any deps are unused: npx depcheck # Simpler output — easier to read for non-technical team members # Faster execution for large codebases: # depcheck only scans import/require statements # (no full export graph traversal like knip) ``` ### depcheck Limitations - No unused files detection - No unused exports detection (the dead code inside files) - No monorepo workspace awareness - Slower update cadence (framework plugins not always current) - Can't detect unused `package.json` scripts ## Feature Comparison | Feature | Knip | depcheck | |---------|------|---------| | Unused dependencies | Yes | Yes | | Missing dependencies | Yes | Yes | | Unused files | Yes | No | | Unused exports | Yes | No | | Unused types | Yes | No | | Monorepo support | Yes | Limited | | Framework plugins | 50+ (Next.js, Vite, etc.) | Basic | | `--fix` auto-remove | Yes (package.json) | No | | TypeScript support | Excellent | Good | | CI JSON reporter | Yes | Yes | | Speed | Slower (full analysis) | Faster (import scan) | | Configuration needed | More | Less | ## Choosing Between Them **Choose Knip if:** - TypeScript or modern JavaScript project - You want more than just dependency auditing (dead code, unused exports) - Monorepo with multiple workspaces - Using Next.js, Vite, Astro, SvelteKit, or another major framework - You want `--fix` to automatically clean up `package.json` - CI enforcement of codebase hygiene **Choose depcheck if:** - Quick, one-off dependency audit with no configuration - You only care about `package.json` dependencies, not internal dead code - Speed is a concern (large codebases, CI time budget) - Simple JavaScript project without complex framework conventions ## Running Both in Practice ```bash # Quick daily check (fast): npx depcheck # Thorough quarterly codebase audit (comprehensive): npx knip # Pre-cleanup audit — find everything: npx knip --reporter json > audit.json # Review the JSON, make decisions, then apply: npx knip --fix ``` ## Community Adoption in 2026 **Knip** is growing rapidly, with approximately 300,000 weekly downloads as of early 2026. Its growth has been driven by the TypeScript community's increasing attention to codebase quality tooling beyond linting and formatting. Knip's author, Lars Kappert, has been prolific in adding framework-specific plugins — over 50 major frameworks and tools are supported, including Next.js, Vite, Astro, SvelteKit, Nuxt, and Remix. This breadth of framework support means Knip can correctly understand that certain files (e.g., Next.js route files, Astro pages) are "entry points" that don't need to be explicitly imported elsewhere to be considered used. **depcheck** maintains approximately 400,000 weekly downloads, reflecting its longer history and the fact that it is often listed as a project hygiene tool in blog posts and tutorials predating Knip's rise. For teams that only need to catch `package.json` bloat — dependencies that were installed but never imported — depcheck remains faster and simpler to run with zero configuration. Its primary advantage in 2026 is speed: depcheck only scans `import`/`require` statements, while Knip builds a full import graph and export analysis. The trend in 2026 favors Knip for new project setups, particularly TypeScript projects. depcheck's limitation — it cannot detect unused exports within files, only unused package dependencies — is an increasingly significant gap as teams focus on dead code elimination as a first-class concern in large TypeScript codebases. Compare dependency auditing package downloads on [PkgPulse](https://pkgpulse.com). *Compare Knip and Depcheck package health on [PkgPulse](https://www.pkgpulse.com/compare/knip-vs-depcheck).* ## CI Integration and Codebase Maintenance Workflows Dead code and unused dependency detection are most valuable when integrated into pull request workflows, catching issues before they accumulate rather than requiring periodic manual audits. **knip in CI** works best with two complementary modes: strict mode for critical files (exports from `src/index.ts` that form the public API) and a more lenient configuration for internal code. A typical CI workflow runs `knip --no-exit-code` to report findings without failing the build, then gradually moves to `knip` (failing on any finding) as the codebase is cleaned up. Knip's `--reporter compact` output works well with GitHub Actions annotations — adding `--reporter github-actions` produces inline PR comments for each finding. **depcheck in CI** is simpler: `depcheck --json | jq '.dependencies | length'` exits non-zero if any unused dependencies are found. The challenge is managing false positives — `depcheck` doesn't understand every build tool configuration, and it commonly misses dynamic requires, CLI dependencies used in npm scripts, and peer dependencies. Teams typically maintain an `ignorePatterns` configuration file listing known false positives. Running depcheck on PRs that modify `package.json` (rather than all PRs) reduces noise. **Codebase maintenance cadence** matters as much as the tooling. Projects that run knip weekly and address findings incrementally accumulate less dead code than projects that run it quarterly and face hundreds of findings. The practical recommendation is to add a `knip` script to `package.json`, configure it to match your project structure once, and automate it in CI with a manageable threshold rather than trying to eliminate all findings immediately. For monorepos, knip's workspace support lets you run a single analysis across all packages while correctly handling cross-package exports and imports. depcheck must be run per-package, and dependency sharing between packages (hoisted dependencies in pnpm/yarn workspaces) can produce false positives for packages that use a hoisted dependency without declaring it explicitly. This monorepo handling difference is a significant advantage for knip in larger codebases. The best approach for most teams is to use both: knip for unused code and exports, depcheck for unused `package.json` dependencies, treating them as complementary rather than competing tools. Each catches a distinct category of technical debt. The most common false positive in both tools is barrel files — `index.ts` files that re-export everything from a directory. Knip identifies these correctly as "used" if the barrel's exports are consumed anywhere. depcheck may flag the packages imported inside barrel files as unused if it cannot follow the re-export chain. A consistent project pattern (either use barrel files everywhere or avoid them) reduces false positive rates significantly and makes both tools more reliable as CI gates. *See also: [How to Migrate from Express to Fastify](/guides/how-to-migrate-express-to-fastify) and [Node.js 22 vs 24 (2026): What Changed & Should You Upgrade?](/guides/nodejs-22-vs-nodejs-24-2026), [Best Environment Variable Management for Node.js 2026](/guides/best-env-variable-management-nodejs-2026).*