Knip - Declutter JavaScript & TypeScript Projects

website·Indexed Apr 17, 2026

https://knip.dev/

Knip is a tool for decluttering JavaScript and TypeScript projects by identifying unused code, dependencies, and configuration issues. Trusted by major software teams, Knip v6 supports monorepos, workspaces, and various compilers. Features include auto-fix, production mode, source mapping, and plugin extensibility. The documentation covers getting started, configuration, CLI arguments, troubleshooting, and writing custom plugins.

Tokens
48.4K
Snippets
241
Records
327
Agent score
50%

What's inside Knip

  1. Overview of Knip capabilities and issue detection

    Knip is a tool designed to find unused code, dependencies, and configuration issues in your project. Its core capability is detecting many types of issues, including unused dependencies, unused exports, and unused files. Knip supports various advanced features to handle complex project structures and workflows, such as production mode, monorepos (both standalone and integrated), source mapping, rules and filters, auto-fixing, custom compilers, reporters, preprocessors, and a script parser. For a complete list of supported issue types, refer to the Issue Types reference.
  2. Overview of available Knip plugins for framework integration

    Knip supports 147 plugins that extend its capabilities to detect unused code in various frameworks, tools, and libraries. These plugins enable Knip to understand specific module resolution patterns, build configurations, and framework conventions. To use a plugin, install the corresponding package (e.g., @knip/plugin-astro) and enable it in your knip configuration. The plugins cover major frameworks like Angular, Astro, React, Vue, Svelte, and tools like Serverless Framework, Sentry, and more. Refer to the specific plugin documentation for installation and configuration details.
  3. Understand the Knip Language Server architecture

    The IDE integrations (VS Code and JetBrains) are powered by the Knip Language Server. This server builds the full module graph of your project and provides a session with a graph explorer. It is the core engine that enables diagnostics, hover information, and tree views in editors.

    For detailed integration instructions and technical documentation, refer to the Language Server repository README.

  4. Why use Knip to find and fix unused code

    Knip is a static analysis tool that finds and fixes unused dependencies, exports, and files in your project. It provides accurate results by performing deep analysis based on fine-grained entry points and understanding the specific frameworks and tooling in your (mono)repo.

    Key benefits of using Knip:

    • Less is more: Removing dead code improves maintenance, performance (startup time, build time, bundle size), and onboarding. It prevents regressions similar to how TypeScript or ESLint work, and keeps code readable by eliminating misleading dead code.
    • Automation: Knip automates the tedious task of finding clutter using various techniques and heuristics. It can also automatically remove unused code.
    • Comprehensive: It supports custom module resolution, configuration file parsers, an advanced shell script parser, built-in and custom compilers, and auto-fix capabilities.
    • Works on any project: Suitable for both greenfield and legacy projects.
    • Unobtrusive: Can be used alongside other linters like ESLint or Biome to catch issues that other tools miss (e.g., unused exports after removing unused variables).
  5. Understand Knip's workspace and configuration file orchestration

    Knip uses a multi-component system to accurately assign configuration files to specific workspaces and reduce false positives. This is essential for monorepos where scripts or workflows reference config files in subdirectories.

    The orchestration process involves:

    1. Plugin Parsing: Plugins (e.g., Vitest) parse specific config files (e.g., vitest.components.config.ts).
    2. CLI Argument Parsing: Knip understands patterns like yarn --cwd [dir] and vitest --config [file] to determine the target workspace.
    3. Workspace Graph: Knip identifies the relationship between workspaces (e.g., packages/frontend is a descendant of the root).
    4. Dependency Deputy: Referenced dependencies are stored to determine unused or missing dependencies per workspace.
    5. Module Graph: Configuration and entry files are used to build the module graph for source files.

    This system applies to package.json scripts and CI/CD workflows (e.g., GitHub Actions) where working-directory or config flags are used.

    // Example: package.json script with workspace-specific config
    {
      "scripts": {
        "test": "yarn --cwd packages/frontend vitest -c vitest.components.config.ts"
      }
    }
  6. Understand the Knip Language Server and module graph capabilities

    The Knip VS Code Extension and MCP Server are powered by a custom Language Server. This server builds the full module graph of your project and provides a session with a graph explorer for advanced queries.

    The Language Server enables:

    • Navigation: Fly through codebases by connecting the dots during development and refactors.
    • Dependency Analysis: Query relationships such as "where is an export imported" or "is this import part of a circular dependency".
    • Session Management: Maintain a session with the graph explorer to request various types of module information dynamically.

    This underlying technology powers the navigation features and linting capabilities available in the editor.

  7. Distinguish between workspaces and TypeScript projects in Knip

    In Knip, a 'workspace' is a directory containing a package.json file, configured via package.json#workspaces or pnpm-workspaces.yml. A 'project' in the TypeScript sense is a directory with a tsconfig.json file, but this is not a concept in Knip. Knip analyzes all workspaces using a single module graph with a shared module resolver, regardless of how many TypeScript projects exist within them. If a directory has a package.json but is not a workspace from a package manager perspective, it can be explicitly added as a workspace in the Knip configuration.
  8. Knip features and CLI options overview

    Knip provides a comprehensive set of features for detecting unused code, dependencies, and configuration issues. Key capabilities include auto-fixing issues with --fix, caching results for faster consecutive runs, and using --debug or --trace for troubleshooting. For monorepos, Knip supports workspaces as first-class citizens with --workspace filtering. Production code can be linted separately using --production or --strict mode. Performance and memory usage can be monitored with --performance and --memory flags. The tool supports various compilers (Astro, MDX, Svelte, Vue), plugins, custom reporters, and source mapping. Shell scripts and package.json files are parsed for entry paths and dependencies. JSDoc tags allow excluding specific exports from reports. Watch mode (--watch) enables live updates for unused files and exports.
    # Common CLI usage examples
    knip --fix                    # Auto-fix issues
    knip --cache                  # Speed up consecutive runs
    knip --debug                  # Troubleshoot issues
    knip --production             # Lint only production code
    knip --strict                 # Lint only production dependencies
    knip --watch                  # Live updates for unused files
    knip --workspace my-workspace # Filter workspaces in monorepo
    knip --performance            # Detailed timing insights
    knip --memory                 # Detailed memory usage insights
  9. Use Knip plugin input functions to report findings

    Knip plugins use specific input functions to communicate what they find in a codebase and how Knip should handle those findings. Using the correct input type improves result accuracy and performance. The available input functions include toEntry, toProductionEntry, toProject, toDependency, toProductionDependency, toDeferResolve, toDeferResolveEntry, toConfig, toBinary, and toAlias.
  10. Key community insights and use cases for Knip

    Community feedback highlights several key capabilities and use cases for Knip:

    • Dead Code Detection: Effective at finding unused files, exports, and dependencies in large codebases, including monorepos (e.g., TanStack, Vercel).
    • AI Code Cleanup: Particularly useful for removing leftover code generated by AI tools.
    • VSCode/Cursor Integration: A dedicated extension exists for Knip, and it supports MCP (Model Context Protocol) for configuration generation.
    • Plugin Development: The contribution experience is well-documented with helper scripts to generate new plugins.
    • Framework Support: Works with Svelte and other frameworks.

    Notable external resources include guides on keeping package.json under control, detecting dead code in high-traffic repos, and automated cleanup strategies.

  11. Knip v4 performance optimizations and memory management

    Knip v4 addresses long-standing performance bottlenecks by changing how it handles projects and shared workspaces. In previous versions (v2 and v3), Knip kept all program data in memory for the duration of the process, which was necessary to maintain connections across workspaces in monorepos. v4 shifts to a serialization approach that allows data to be written to disk rather than held entirely in memory, significantly reducing the memory footprint and speeding up execution.
  12. Understand Knip v4 Performance and Memory Optimizations

    Knip v4 significantly improves performance by decoupling the linting process from the TypeScript Language Service's findReferences method. Key changes include:

    1. Serialization: Imports and exports are serialized to disk or memory, allowing for caching and isolation of workspaces.
    2. Memory Reduction: Workspaces are read and disposed of in isolation, reducing peak memory usage by approximately 50%.
    3. Speed: Eliminating findReferences speeds up the export/import matching process, resulting in up to 60% faster total runtime on large codebases.
    4. Parallelization: Decoupled steps enable parallel processing of module resolution and AST traversal.

    Trade-off: Unused class members are no longer reported by default in v4. This feature may be reintroduced behind a flag in the future.