{"id":78930,"date":"2026-03-25T18:01:15","date_gmt":"2026-03-25T12:31:15","guid":{"rendered":"https:\/\/www.tothenew.com\/blog\/?p=78930"},"modified":"2026-03-25T20:58:20","modified_gmt":"2026-03-25T15:28:20","slug":"knip-an-essential-tool-for-code-hygiene","status":"publish","type":"post","link":"https:\/\/www.tothenew.com\/blog\/knip-an-essential-tool-for-code-hygiene\/","title":{"rendered":"Knip: An Essential Tool for Code Hygiene"},"content":{"rendered":"

Modern software projects grow at a fast pace with new features, hot-fixes, refactors and migration, codebases tend to accumulate dead code, unused dependencies, and files that were forgotten but are still sitting in your source code. As a project grows, most of the time unused code starts piling up. As a result it slows down the build and makes the codebase harder to understand and work with.<\/p>\n

That’s where Knip comes in the picture. It’s a free, open-source tool that quietly goes through your project and points out all the code that isn’t being used anywhere. It tells you exactly what part of your code is unused and can be safely removed.<\/p>\n

What Knip Does<\/strong><\/h2>\n

Knip examines your project structure, starting from one or more entry files that represent your application\u2019s main execution points. It then builds a dependency graph by following import\/require statements, configuration references, and tooling setup files. From this graph, Knip determines following things:<\/p>\n

Unused files<\/strong> \u2014 source files that are not referenced anywhere reachable.<\/p>\n

Unused exports<\/strong> \u2014 exported functions, variables, types, components, or classes which are\u00a0 never used.<\/p>\n

Unused dependencies<\/strong> \u2014 Any modules listed in package.json but not imported anywhere in code.<\/p>\n

Unlisted dependencies<\/strong> \u2014 imported modules missing from package.json.<\/p>\n

Unresolved imports <\/strong>\u2014 import paths that don\u2019t resolve to valid files or packages.<\/p>\n

Unused devDependencies<\/strong> – modules listed in package.json but not used anywhere in code.<\/p>\n

Knip looks deeper into your project than the tree-shaking done by bundlers.<\/p>\n

It analyses the internal structure of your codebase to detect unused files, exports, and dependencies that bundlers might miss.<\/p>\n

While bundlers mainly focus on removing unused code during the build process, Knip inspects the entire project to identify parts of the code that are no longer being used or referenced.<\/p>\n

This helps developers keep their projects cleaner, reduce unnecessary dependencies, and maintain a more organised codebase.<\/p>\n

<\/h2>\n

Why Use Knip?<\/h2>\n

There are clear and practical benefits to adopting Knip:<\/p>\n

1. Reduce Technical Debt –<\/strong>
\nKnip helps you to find unused parts in your code base in an automated way that would otherwise remain hidden. Fixing these increases the maintainability of source code.<\/p>\n

2. Improve Performance-<\/strong>
\nUnused\/dead code contributes to longer build times and larger bundles. Trimming it reduces compilation and load times.<\/p>\n

3. Better Maintainability-<\/strong>
\nKeeping only what\u2019s essential makes refactors safer and contributes towards a well maintained code base. Eliminating unused packages can reduce vulnerabilities.<\/p>\n

4. Automation Compatibility-<\/strong>
\nKnip integrates well with CI\/CD pipelines to enforce hygiene standards before merges \u2014 preventing regressions where unused code slips back in.<\/p>\n

<\/h2>\n

Getting Started<\/h2>\n

Knip is designed to work out of the box with most JavaScript and TypeScript setups.<\/p>\n

Installation
\nDepending on your package manager:<\/p>\n

# npm\r\nnpm install -D knip typescript @types\/node\r\n\r\n# yarn\r\nyarn add -D knip typescript @types\/node\r\n\r\n# pnpm\r\npnpm add -D knip typescript @types\/node<\/span><\/pre>\n
Then add a script to your package.json:<\/p>\n
{\r\n \u00a0\"scripts\": {\r\n \u00a0\u00a0\u00a0\"knip\": \"knip\"\r\n \u00a0}\r\n}<\/span><\/pre>\n
Or run directly without installation:<\/p>\n
npx knip\r\n\r\nnpm run knip<\/span><\/pre>\n
After installation, Knip will analyse the project and generate a report listing unused files, exports, and dependencies.
\nA sample Output on CLI will look like below, all the findings separated in different categories.<\/p>\n
$ npm run knip<\/span>\r\n\r\n> my-app@1.0.0 knip<\/span>\r\n> knip<\/span>\r\n\r\nUnused files (2)<\/span>\r\nsrc\/utils\/oldFormatter.ts<\/span>\r\nsrc\/components\/DeprecatedBanner.tsx<\/span>\r\n\r\nUnused exports (5)<\/span>\r\nsrc\/utils\/helpers.ts formatDate<\/span>\r\nsrc\/utils\/helpers.ts convertToCSV<\/span>\r\nsrc\/api\/userService.ts fetchUserById<\/span>\r\nsrc\/hooks\/useWindowSize.ts useWindowSize<\/span>\r\nsrc\/constants\/config.ts DEBUG_MODE<\/span>\r\n\r\nUnused types (2)<\/span>\r\nsrc\/types\/legacy.ts LegacyUserProps<\/span>\r\nsrc\/types\/legacy.ts OldApiResponse<\/span>\r\n\r\nUnused dependencies (3)<\/span>\r\nlodash<\/span>\r\nmoment<\/span>\r\naxios<\/span>\r\n\r\nUnused devDependencies (1)<\/span>\r\n@types\/lodash<\/span>\r\n\r\nUnresolved imports (1)<\/span>\r\nsrc\/screens\/HomeScreen.tsx ..\/..\/shared\/theme \u2190 cannot resolve path<\/span>\r\n\r\n<\/pre>\n
 <\/p>\n
What If the Output is Overwhelming?<\/strong><\/p>\n
For large projects, when running knip for the first time,\u00a0 it might find many issues all at once. In such cases we can limit the number of issues shown by knip analysis and try to fix them subsequently.<\/p>\n
npm run knip -- --max-show-issues 5\r\n\r\nyarn run knip --max-show-issues 5<\/span><\/pre>\n
 <\/p>\n
Customizing Knip<\/h2>\n
Knip works well with its default settings, but larger or more complex codebases usually require some customization. To tailor its behavior, you can add a configuration file such as knip.json<\/span>, knip.jsonc<\/span>, or use a dynamic setup via knip.config.js<\/span> or knip.config.ts<\/span>.<\/p>\n
Below is an example of a basic configuration for a React native Project<\/strong>:<\/p>\n
{<\/span>\r\n\"$schema\": \"https:\/\/unpkg.com\/knip@5\/schema.json\",<\/span>\r\n\"entry\": [<\/span>\r\n\"src\/index.ts\", \/\/ main entry file (JS\/TS bootstrap)<\/span>\r\n\"src\/App.tsx\" \/\/ root React component<\/span>\r\n\/\/ add more if you have multiple entry points (e.g. storybook, dev entry)<\/span>\r\n],<\/span>\r\n\"project\": [<\/span>\r\n\"src\/**\/*.{js,ts,tsx}\"<\/span>\r\n\/\/ include other folders if needed (e.g. \"lib\/**\", \"components\/**\")<\/span>\r\n],<\/span>\r\n\"ignore\": [<\/span>\r\n\"**\/__tests__\/**\", \/\/ test directories<\/span>\r\n\"android\/**\", \/\/ native Android project files<\/span>\r\n\"ios\/**\" \/\/ native iOS project files<\/span>\r\n\/\/ optionally add: \"coverage\/**\", \"e2e\/**\"<\/span>\r\n],<\/span>\r\n\"ignoreDependencies\": [<\/span>\r\n\"@react-native\/metro-config\", \/\/ Metro bundler config<\/span>\r\n\"@react-native\/babel-preset\" \/\/ Babel preset for RN<\/span>\r\n\/\/ add more tooling deps if flagged (e.g. \"jest\", \"babel-*\")<\/span>\r\n]<\/span>\r\n}<\/span><\/pre>\n
In this setup:<\/p>\n
    \n
  • Specific entry files like src\/index.ts<\/span> and src\/App.tsx<\/span> are declared explicitly.<\/li>\n
  • The project field defines which source files Knip should scan.<\/li>\n
  • Test folders and platform-specific directories for Android and iOS are excluded from analysis.<\/li>\n
  • Certain dependencies are intentionally ignored because they\u2019re required for build tooling but aren\u2019t referenced directly at runtime.<\/li>\n<\/ul>\n
    Below is example of React web App<\/strong>:<\/p>\n
    {<\/span>\r\n\"$schema\": \"https:\/\/unpkg.com\/knip@5\/schema.json\",<\/span>\r\n\r\n\"entry\": [<\/span>\r\n\"index.html\", \/\/ main HTML entry<\/span>\r\n\"src\/main.tsx\", \/\/ Vite entry<\/span>\r\n\"src\/index.tsx\" \/\/ CRA\/Webpack entry (optional)<\/span>\r\n\/\/ add more entry points if needed (e.g. admin.tsx, dashboard.tsx)<\/span>\r\n],<\/span>\r\n\r\n\"project\": [<\/span>\r\n\"src\/**\/*.{js,jsx,ts,tsx}\"<\/span>\r\n\/\/ include other folders if needed (e.g. \"lib\/**\", \"components\/**\")<\/span>\r\n],<\/span>\r\n\r\n\"ignore\": [<\/span>\r\n\"**\/*.test.*\", \/\/ unit tests<\/span>\r\n\"**\/__tests__\/**\", \/\/ test folders<\/span>\r\n\"dist\/**\", \/\/ production build (Vite)<\/span>\r\n\"build\/**\" \/\/ production build (CRA\/Webpack)<\/span>\r\n\/\/ add more like \"coverage\/**\", \".next\/**\"<\/span>\r\n],<\/span>\r\n\r\n\"ignoreDependencies\": [<\/span>\r\n\"@types\/*\", \/\/ TypeScript types<\/span>\r\n\"eslint\", \/\/ linting<\/span>\r\n\"prettier\", \/\/ formatting<\/span>\r\n\"vite\", \/\/ bundler<\/span>\r\n\"webpack\" \/\/ bundler<\/span>\r\n\/\/ add more tooling if flagged (jest, vitest, babel, etc.)<\/span>\r\n]<\/span>\r\n}<\/span><\/pre>\n
      \n
    • Entry points such as index.html<\/span> and src\/main.tsx<\/span> (or src\/index.tsx<\/span>) are explicitly defined to represent the application bootstrap.<\/li>\n
    • The project field specifies all source files within src\/ that Knip should analyze for unused exports and dependencies.<\/li>\n
    • Test files, test directories, and build output folders like dist\/ and build\/ are excluded to avoid noise in analysis.<\/li>\n
    • Tooling-related dependencies (e.g., bundlers, linters, type definitions) are ignored because they are required for development\/build processes but not directly imported in application runtime code.<\/li>\n<\/ul>\n
      <\/h2>\n
      Conclusion<\/h2>\n
      We often spend a lot of time adding new features to our codebase, but we rarely think about the cost of keeping code that we no longer use. Unused or \u201cdead\u201d code slowly becomes technical debt. It can increase build times, make bundles larger, and make the codebase harder to understand.<\/p>\n
      If you\u2019re working on a JavaScript project that has been around for a few months, try using Knip. You might be surprised by how much unnecessary code it finds and how quickly your project can become lighter and cleaner.<\/p>\n","protected":false},"excerpt":{"rendered":"
      Modern software projects grow at a fast pace with new features, hot-fixes, refactors and migration, codebases tend to accumulate dead code, unused dependencies, and files that were forgotten but are still sitting in your source code. As a project grows, most of the time unused code starts piling up. As a result it slows down […]<\/p>\n","protected":false},"author":1271,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":27},"categories":[5881],"tags":[55,4064,5853],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/78930"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/1271"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=78930"}],"version-history":[{"count":3,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/78930\/revisions"}],"predecessor-version":[{"id":79156,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/78930\/revisions\/79156"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=78930"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=78930"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=78930"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}