@knip/mcp 0.0.19 → 0.0.21

package/package.json

@@ -1,34 +1,34 @@
 {
   "name": "@knip/mcp",
-  "version": "0.0.19",
+  "version": "0.0.21",
   "description": "Knip MCP Server",
-  "type": "module",
-  "bin": {
-    "knip-mcp": "./src/cli.js"
-  },
-  "exports": {
-    ".": "./src/server.js",
-    "./tools": "./src/tools.js"
-  },
-  "files": [
-    "src"
-  ],
   "keywords": [
     "knip",
     "mcp",
     "model-context-protocol"
   ],
+  "license": "ISC",
+  "author": "Lars Kappert <lars@webpro.nl>",
   "repository": {
     "type": "git",
     "url": "git+https://github.com/webpro-nl/knip.git",
     "directory": "packages/mcp-server"
   },
-  "author": "Lars Kappert <lars@webpro.nl>",
-  "license": "ISC",
+  "bin": {
+    "knip-mcp": "./src/cli.js"
+  },
+  "files": [
+    "src"
+  ],
+  "type": "module",
+  "exports": {
+    ".": "./src/server.js",
+    "./tools": "./src/tools.js"
+  },
   "dependencies": {
-    "@modelcontextprotocol/sdk": "^1.25.3",
+    "@modelcontextprotocol/sdk": "^1.27.1",
     "zod": "^4.1.11",
-    "knip": "^5.84.0"
+    "knip": "^5.87.0"
   },
   "engines": {
     "node": ">=18.18.0"

package/src/docs/blog/knip-v3.mdx

@@ -82,7 +82,7 @@ Remember, Knip it before you ship it! Have a great day ☀️
 [3]: https://github.com/webpro-nl/knip/stargazers
 [4]: https://github.com/webpro-nl/knip/network/dependents
 [5]: https://github.com/marketplace/actions/knip-reporter
-[6]: ../reference/cli.md#exit-code
+[6]: ../reference/cli.md#--no-exit-code
 [7]: ../features/production-mode.md
 [8]: ../reference/jsdoc-tsdoc-tags.md#internal
 [9]: ../features/reporters.md#json

package/src/docs/blog/knip-v4.mdx

@@ -146,4 +146,4 @@ Remember, Knip it before you ship it! Have a great day ☀️
 [2]: ../features/compilers.md
 [3]: ../guides/issue-reproduction.md
 [4]: https://github.com/sponsors/webpro
-[5]: ../reference/cli.md#--experimental-tags
+[5]: ../reference/cli.md#--tags

package/src/docs/docs/blog/knip-v3.mdx

@@ -82,7 +82,7 @@ Remember, Knip it before you ship it! Have a great day ☀️
 [3]: https://github.com/webpro-nl/knip/stargazers
 [4]: https://github.com/webpro-nl/knip/network/dependents
 [5]: https://github.com/marketplace/actions/knip-reporter
-[6]: ../reference/cli.md#exit-code
+[6]: ../reference/cli.md#--no-exit-code
 [7]: ../features/production-mode.md
 [8]: ../reference/jsdoc-tsdoc-tags.md#internal
 [9]: ../features/reporters.md#json

package/src/docs/docs/blog/knip-v4.mdx

@@ -146,4 +146,4 @@ Remember, Knip it before you ship it! Have a great day ☀️
 [2]: ../features/compilers.md
 [3]: ../guides/issue-reproduction.md
 [4]: https://github.com/sponsors/webpro
-[5]: ../reference/cli.md#--experimental-tags
+[5]: ../reference/cli.md#--tags

package/src/docs/docs/explanations/plugins.md

@@ -100,8 +100,8 @@ dependencies.
 For example, if `next` is listed as a dependency in `package.json`, the Next.js
 plugin will automatically add multiple patterns as entry files, such as
 `pages/**/*.{js,jsx,ts,tsx}`. If `vitest` is listed, the Vitest plugin adds
-`**/*.{test,test-d,spec}.ts` as entry file patterns. Most plugins have entry
-files configured, so you don't have to.
+`**/*.{test,test-d,spec,spec-d}.ts` as entry file patterns. Most plugins have
+entry files configured, so you don't have to.
 
 It's mostly plugins for meta frameworks and test runners that have `entry` files
 configured.

package/src/docs/docs/guides/handling-issues.mdx

@@ -689,7 +689,7 @@ issue on GitHub. It'll make Knip better for everyone!
 [32]: #dependencies-named-after-nodejs-builtins
 [33]: #unlisted-binaries
 [34]: https://github.com/webpro-nl/knip/blob/e031018e676c47d84873cc2403251c0111ef318d/packages/knip/src/constants.ts#L39-L148
-[35]: ../features/monorepos-and-workspaces.md#lint-a-single-workspace
+[35]: ../features/monorepos-and-workspaces.md#filter-workspaces
 [36]: #template-strings
 [37]: #unrecognized-path-aliases
 [38]: #external-aliased-imports

package/src/docs/docs/guides/performance.md

@@ -105,4 +105,4 @@ individual workspaces][6].
 [3]: ../guides/handling-issues.mdx#external-libraries
 [4]: ../reference/cli.md#--performance
 [5]: ../reference/configuration.md#ignoreexportsusedinfile
-[6]: ../features/monorepos-and-workspaces.md#lint-a-single-workspace
+[6]: ../features/monorepos-and-workspaces.md#filter-workspaces

package/src/docs/docs/overview/features.md

@@ -63,4 +63,4 @@ Also see [related tooling][2].
 [23]: ../features/production-mode.md#strict-mode
 [24]: ../guides/troubleshooting.md#trace
 [25]: ../reference/cli.md#--watch
-[26]: ../features/monorepos-and-workspaces.md#lint-a-single-workspace
+[26]: ../features/monorepos-and-workspaces.md#filter-workspaces

package/src/docs/docs/reference/faq.md

@@ -22,6 +22,65 @@ This FAQ is an attempt to provide some perspective on a few design decisions and
 why certain things work the way they do. Here and there it's intentionally a bit
 more in-depth than the rest of the docs.
 
+## Why should I even bother to do all this?
+
+Because the payoff is huge. While it might take a bit of effort to configure
+Knip correctly initially, a clean module graph gives you absolute confidence in
+your codebase. You can delete dead code, remove unused dependencies, and
+refactor with certainty. It prevents the slow accumulation of technical debt and
+keeps your project lean and fast. Once configured, Knip runs quickly in CI and
+keeps your codebase pristine automatically.
+
+:::tip
+
+Try the [Knip MCP Server][1] or the [Knip Editor Extension][2]. Let your coding
+agent use the built-in MCP Server and create a custom `knip.json` for you, so
+you don't have to.
+
+:::
+
+## Common Pitfalls
+
+### Why shouldn't I ignore or disable configuration hints?
+
+Configuration hints are critical for building a healthy and accurate module
+graph. They usually indicate that Knip cannot resolve a dependency, plugin, or
+entry file. If you ignore or disable these hints, Knip's understanding of your
+project will be incomplete, which inevitably leads to false positives (reporting
+used code as unused). Always address configuration hints first before looking at
+other reported issues.
+
+### Why is it a bad idea to use `ignore` patterns like I do in ESLint?
+
+Knip is not a regular file-based linter like ESLint. It works by analyzing the
+entire interconnected module graph of your project. Using `ignore` patterns does
+not exclude files from the analysis, it only suppresses the reporting of issues
+in those files. This hides real issues and creates blind spots. Instead of
+ignoring files, ensure your entry points and plugins are configured correctly,
+and use `project` patterns to define the boundaries of your codebase. Read more:
+[Configuring Project Files][3].
+
+If you have specific exports (such as types) that are only used within the file
+they are defined, use the [ignoreExportsUsedInFile][4] configuration option
+rather than ignoring the file entirely.
+
+### How should I exclude tests and development tools from the analysis?
+
+A common mistake is trying to exclude test files, storybooks, or development
+tools using `project` or `ignore` patterns. The correct approach is to use
+[production mode][5]. This mode is specifically designed to strictly analyze
+only your production source code and `dependencies`, automatically excluding
+tests and `devDependencies` without requiring complex ignore rules.
+
+### Why shouldn't I run `knip --fix` immediately?
+
+Running `knip --fix` before your configuration is fully settled is dangerous. If
+your configuration is missing entry points or has unresolved hints, Knip might
+think perfectly valid, actively used code is unused. Auto-fixing in this state
+can lead to deleting code that your application relies on. Always verify the
+reported issues manually and ensure your configuration is solid before using the
+`--fix` flag.
+
 ## Comparison
 
 ### Why isn't Knip an ESLint plugin?
@@ -53,10 +112,10 @@ Issues reported by the linter are for you to handle and review.
 
 Besides those differences, Knip has a broader scope:
 
-- Improve DX (see [less is more][1]).
-- Unless using [production mode][2], also lint all source code like tests,
+- Improve DX (see [less is more][6]).
+- Unless using [production mode][5], also lint all source code like tests,
   scripts and Storybook stories.
-- Handle more [types of issues][3] (such as unlisted dependencies).
+- Handle more [types of issues][7] (such as unlisted dependencies).
 
 ## Synergy
 
@@ -89,13 +148,13 @@ Building up the module and dependency graphs requires non-standard module
 resolution and not only static but also dynamic analysis (i.e. actually load and
 execute modules), such as for parsers of plugins to receive the exported value
 of dynamic tooling configuration files. Additionally, [exports consumed by
-external libraries][4] require type information, as supported by the TypeScript
+external libraries][8] require type information, as supported by the TypeScript
 backend. Last but not least, shell script parsing is required to find the right
 entry files, configuration files and dependencies accurately.
 
 The rippling effect of plugins and recursively adding entry files and
 dependencies to build up the graphs is also exactly what's meant by
-["comprehensive" here][5].
+["comprehensive" here][9].
 
 ## Building the graphs
 
@@ -143,7 +202,7 @@ files (`config/vitest.config.ts` and `playwright.e2e.config.ts` in the examples
 above). They're recognized as configuration files and passed to their respective
 plugins, and may contain additional entry files.
 
-Entry files are added to the module graph. [Module resolution][6] might result
+Entry files are added to the module graph. [Module resolution][10] might result
 in additional entry files recursively until no more entry files are found.
 
 ### What does Knip look for in source files?
@@ -156,7 +215,7 @@ all nodes of the generated AST to find:
 - Accessed properties on namespace imports and re-exports to track individual
   export usage
 - Calls to `require.resolve` and `import.meta.resolve`
-- Scripts in template strings (passed to [script parser][7])
+- Scripts in template strings (passed to [script parser][11])
 
 ### What's in the graphs?
 
@@ -194,7 +253,7 @@ there are a few issues with this approach:
 
 - It requires lockfile parsing for each lockfile format and version of each
   package manager.
-- The lockfile doesn't contain whether the package [has types included][8].
+- The lockfile doesn't contain whether the package [has types included][12].
 
 ## Module Resolution
 
@@ -215,12 +274,12 @@ seem to meet all requirements to be usable on its own by Knip:
   `module.js`
 
 A few strategies have been tried and tweaked, and Knip currently uses a
-combination of [oxc-resolver][9], the TypeScript module resolver and a few
+combination of [oxc-resolver][13], the TypeScript module resolver and a few
 customizations. This single custom module resolver function is hooked into the
 TypeScript compiler and language service hosts.
 
-Everything else is handled by `oxc-resolver` for things like [script parsing][7]
-and resolving references to files in other workspaces.
+Everything else is handled by `oxc-resolver` for things like [script
+parsing][11] and resolving references to files in other workspaces.
 
 ### How does Knip handle non-standard import syntax?
 
@@ -250,7 +309,7 @@ file. They're not a concept in Knip.
 
 A TypeScript program has a 1-to-1 relationship with workspaces if they're
 analyzed in isolation. However, by default Knip optimizes for performance and
-utilizes [workspace sharing][10]. That's why debug output contains messages like
+utilizes [workspace sharing][14]. That's why debug output contains messages like
 "Installed 2 programs for 29 workspaces".
 
 ### Why doesn't Knip match my TypeScript project structure?
@@ -282,7 +341,7 @@ Knip shares the files of multiple workspaces in a single program if their
 configuration allows it. This optimization is enabled by default, while it also
 allows the module resolver (one per program) to do some more caching.
 
-Also see [workspace sharing][10].
+Also see [workspace sharing][14].
 
 ### Why doesn't Knip just use `ts.findReferences`?
 
@@ -298,7 +357,7 @@ comprehensive graph include:
 Without sacrificing these benefits, Knip does use `ts.findReferences` to find
 references to class members (i.e. when the issue type `classMembers` is
 included). In case analysis of exports requires type information of external
-dependencies, the [`--include-libs ` flag][4] will trigger the same.
+dependencies, the [`--include-libs ` flag][8] will trigger the same.
 
 ### Why can't I use path aliases to reference other workspaces?
 
@@ -310,19 +369,19 @@ The recommendation and best practice is to list such workspaces/dependencies in
 `package.json`, and import them as such. Other tooling should not have any
 issues with this standard approach either.
 
-Also see the example in [TypeScript path aliases in monorepos][11].
+Also see the example in [TypeScript path aliases in monorepos][15].
 
 ### What's up with that configurable `tsconfig.json` location?
 
 There's a difference between `--tsConfig [file]` as a CLI argument and the
 `typescript.config` option in Knip configuration.
 
-The [`--tsConfig [file]` option][12] is used to provide an alternative location
+The [`--tsConfig [file]` option][16] is used to provide an alternative location
 for the default root `tsconfig.json` file. Relevant `compilerOptions` include
 `paths` and `moduleResolution`. This setting is only available at the root
 level.
 
-On the other hand, the [`config` option of the plugin][13] can be set per
+On the other hand, the [`config` option of the plugin][17] can be set per
 workspace. The TypeScript plugin extracts referenced external dependencies such
 as those in `extends`, `compilerOptions.types` and JSX settings:
 
@@ -346,7 +405,7 @@ From this example, Knip can determine whether the `@tsconfig/node20` and
   for `tsconfig.json` can be set per workspace.
 - In case path aliases from `compilerOptions.paths` aren't picked up by Knip,
   either use `--tsConfig [file]` to target a different `tsconfig.json`, or
-  manually add [paths][14] to the Knip configuration. The latter can be done per
+  manually add [paths][18] to the Knip configuration. The latter can be done per
   workspace.
 
 ## Compilers
@@ -369,7 +428,7 @@ other file types.
 Knip comes with basic "compilers" for a few common non-standard file types.
 They're not actual compilers, they're regular expressions only to extract import
 statements. Override the built-in Vue "compiler" with the real one in your
-project. Also see the answer to the previous question and [Compilers][15].
+project. Also see the answer to the previous question and [Compilers][19].
 
 ## Miscellaneous
 
@@ -389,7 +448,7 @@ Which mode should've been the default? They both have their merits:
   tooling, including most issues found in production mode. This mode has the
   most impact on DX, for the same reason.
 
-Also see [production mode][2].
+Also see [production mode][5].
 
 ### Why doesn't Knip have...?
 
@@ -410,21 +469,25 @@ Examples of features that have been requested include:
 
 These are all interesting ideas, but most increase the API surface area, and all
 require more development efforts and maintenance. Time is limited and
-[sponsorships][16] currently don't cover - this can change though!
-
-[1]: ../explanations/why-use-knip.md#less-is-more
-[2]: ../features/production-mode.md
-[3]: ./issue-types.md
-[4]: ../guides/handling-issues.mdx#external-libraries
-[5]: ../explanations/why-use-knip.md#comprehensive
-[6]: #module-resolution
-[7]: ../features/script-parser.md
-[8]: ../guides/handling-issues.mdx#type-definition-packages
-[9]: https://oxc.rs/docs/guide/usage/resolver.html
-[10]: ../guides/performance.md#workspace-sharing
-[11]: ../guides/handling-issues.mdx#typescript-path-aliases-in-monorepos
-[12]: ../reference/cli.md#--tsconfig-file
-[13]: ../explanations/plugins.md#configuration-files
-[14]: ../reference/configuration.md#paths
-[15]: ../features/compilers.md
-[16]: /sponsors
+[sponsorships][20] currently don't cover - this can change though!
+
+[1]: ../reference/integrations.md#mcp-server
+[2]: ../reference/integrations.md#vs-code-extension
+[3]: ../guides/configuring-project-files.md
+[4]: ../reference/configuration.md#ignoreexportsusedinfile
+[5]: ../features/production-mode.md
+[6]: ../explanations/why-use-knip.md#less-is-more
+[7]: ./issue-types.md
+[8]: ../guides/handling-issues.mdx#external-libraries
+[9]: ../explanations/why-use-knip.md#comprehensive
+[10]: #module-resolution
+[11]: ../features/script-parser.md
+[12]: ../guides/handling-issues.mdx#type-definition-packages
+[13]: https://oxc.rs/docs/guide/usage/resolver.html
+[14]: ../guides/performance.md#workspace-sharing
+[15]: ../guides/handling-issues.mdx#typescript-path-aliases-in-monorepos
+[16]: ../reference/cli.md#--tsconfig-file
+[17]: ../explanations/plugins.md#configuration-files
+[18]: ../reference/configuration.md#paths
+[19]: ../features/compilers.md
+[20]: /sponsors

package/src/docs/docs/reference/issue-types.md

@@ -5,23 +5,23 @@ tableOfContents: false
 
 Knip reports the following types of issues:
 
-| Title                                | Description                                                |       | Key            |
-| :----------------------------------- | :--------------------------------------------------------- | ----- | :------------- |
-| Unused files                         | Unable to find a reference to this file                    | 🔧    | `files`        |
-| Unused dependencies                  | Unable to find a reference to this dependency              | 🔧    | `dependencies` |
-| Unused devDependencies               | Unable to find a reference to this devDependency           | 🔧    | `dependencies` |
-| Referenced optional peerDependencies | Optional peer dependency is referenced                     |       | `dependencies` |
-| Unlisted dependencies                | Used dependencies not listed in package.json               |       | `unlisted`     |
-| Unlisted binaries                    | Binaries from dependencies not listed in package.json      |       | `binaries`     |
-| Unused catalog entries               | Unable to find a reference to this catalog entry           | 🔧    | `catalog`      |
-| Unresolved imports                   | Unable to resolve this (import) specifier                  |       | `unresolved`   |
-| Unused exports                       | Unable to find a reference to this export                  | 🔧    | `exports`      |
-| Unused exported types                | Unable to find a reference to this exported type           | 🔧    | `types`        |
-| Exports in used namespace            | Namespace with export is referenced, but not export itself | 🔧 🟠 | `nsExports`    |
-| Exported types in used namespace     | Namespace with type is referenced, but not type itself     | 🔧 🟠 | `nsTypes`      |
-| Unused exported enum members         | Unable to find a reference to this enum member             | 🔧    | `enumMembers`  |
-| Unused exported class members        | Unable to find a reference to this class member            | 🔧 🟠 | `classMembers` |
-| Duplicate exports                    | This is exported more than once                            |       | `duplicates`   |
+| Title                                | Description                                           |       | Key                        |
+| :----------------------------------- | :---------------------------------------------------- | ----- | :------------------------- |
+| Unused files                         | Unable to find a reference to this file               | 🔧    | `files`                    |
+| Unused dependencies                  | Unable to find a reference to this dependency         | 🔧    | `dependencies`             |
+| Unused devDependencies               | Unable to find a reference to this devDependency      | 🔧    | `devDependencies`          |
+| Referenced optional peerDependencies | Optional peer dependency is used                      |       | `optionalPeerDependencies` |
+| Unlisted dependencies                | Used dependencies not listed in package.json          |       | `unlisted`                 |
+| Unlisted binaries                    | Binaries from dependencies not listed in package.json |       | `binaries`                 |
+| Unused catalog entries               | Unable to find a reference to this catalog entry      | 🔧    | `catalog`                  |
+| Unresolved imports                   | Unable to resolve this (import) specifier             |       | `unresolved`               |
+| Unused exports                       | Unable to find a reference to this export             | 🔧    | `exports`                  |
+| Unused exported types                | Unable to find a reference to this exported type      | 🔧    | `types`                    |
+| Exports in used namespace            | Namespace with export is used, but not export itself  | 🔧 🟠 | `nsExports`                |
+| Exported types in used namespace     | Namespace with type is used, but not type itself      | 🔧 🟠 | `nsTypes`                  |
+| Unused exported enum members         | Unable to find a reference to this enum member        | 🔧    | `enumMembers`              |
+| Unused exported class members        | Unable to find a reference to this class member       | 🔧 🟠 | `classMembers`             |
+| Duplicate exports                    | This is exported more than once                       |       | `duplicates`               |
 
 ## Legend
 
@@ -33,11 +33,13 @@ Knip reports the following types of issues:
 ## Notes
 
 - When an issue type has zero issues, it is not shown.
-- The `devDependencies` and `optionalPeerDependencies` are covered in a single
-  key for all `dependencies`. In [strict production mode][3], `devDependencies`
-  are not included.
+- Including or excluding `dependencies` (via CLI or configuration) automatically
+  includes or excludes `devDependencies` and `optionalPeerDependencies`. In
+  [rules][3], each key can be set individually.
+- In [strict production mode][4], `devDependencies` are not included.
 - The `types` issue type includes `enum`, `interface` and `type` exports.
 
 [1]: ../features/auto-fix.mdx
 [2]: ../features/rules-and-filters.md#filters
-[3]: ../features/production-mode.md#strict-mode
+[3]: ../features/rules-and-filters.md#rules
+[4]: ../features/production-mode.md#strict-mode

package/src/docs/docs/reference/jsdoc-tsdoc-tags.md

@@ -30,7 +30,7 @@ Example:
 export const myUnusedExport = 1;
 
 /** @lintignore */
-import Unresolved from './generated/lib.js';
+import Unresolved from "./generated/lib.js";
 ```
 
 And then include (`+`) or exclude (`-`) these tagged exports from the report
@@ -42,6 +42,17 @@ knip --tags=-lintignore,-internal
 
 Tags can also be [configured in `knip.json`][2].
 
+When an excluded tag is no longer necessary because the export is actually used,
+Knip reports a **tag hint**:
+
+```sh
+Tag hints (1)
+ignored  unimported.ts  Unused tag in unimported.ts: ignored → @custom
+```
+
+This helps you clean up tags that were added to suppress issues that have since
+been resolved.
+
 ## `@public`
 
 By default, Knip reports unused exports in non-entry files.

package/src/docs/docs/reference/plugins.md

@@ -1,5 +1,5 @@
 ---
-title: Plugins (131)
+title: Plugins (137)
 tableOfContents: false
 ---
 
@@ -32,6 +32,7 @@ tableOfContents: false
 - [Drizzle](/reference/plugins/drizzle "Drizzle")
 - [Eleventy](/reference/plugins/eleventy "Eleventy")
 - [ESLint](/reference/plugins/eslint "ESLint")
+- [execa](/reference/plugins/execa "execa")
 - [Expo](/reference/plugins/expo "Expo")
 - [Expressive Code](/reference/plugins/expressive-code "Expressive Code")
 - [Gatsby](/reference/plugins/gatsby "Gatsby")
@@ -75,16 +76,20 @@ tableOfContents: false
 - [oclif](/reference/plugins/oclif "oclif")
 - [Oxlint](/reference/plugins/oxlint "Oxlint")
 - [Parcel](/reference/plugins/parcel "Parcel")
+- [Payload CMS](/reference/plugins/payload "Payload CMS")
 - [Playwright](/reference/plugins/playwright "Playwright")
 - [Playwright for components](/reference/plugins/playwright-ct "Playwright for components")
 - [playwright-test](/reference/plugins/playwright-test "playwright-test")
 - [Plop](/reference/plugins/plop "Plop")
+- [pm2](/reference/plugins/pm2 "pm2")
 - [pnpm](/reference/plugins/pnpm "pnpm")
 - [PostCSS](/reference/plugins/postcss "PostCSS")
 - [Preconstruct](/reference/plugins/preconstruct "Preconstruct")
 - [Prettier](/reference/plugins/prettier "Prettier")
 - [Prisma](/reference/plugins/prisma "Prisma")
+- [Qwik](/reference/plugins/qwik "Qwik")
 - [React Cosmos](/reference/plugins/react-cosmos "React Cosmos")
+- [React Native](/reference/plugins/react-native "React Native")
 - [React Router](/reference/plugins/react-router "React Router")
 - [Relay](/reference/plugins/relay "Relay")
 - [Release It!](/reference/plugins/release-it "Release It!")
@@ -135,6 +140,7 @@ tableOfContents: false
 - [xo](/reference/plugins/xo "xo")
 - [Yarn](/reference/plugins/yarn "Yarn")
 - [yorkie](/reference/plugins/yorkie "yorkie")
+- [zx](/reference/plugins/zx "zx")
 
 
 :::

package/src/docs/docs/writing-a-plugin/index.md

@@ -365,7 +365,7 @@ The script adds the plugin to the JSON Schema and type definitions.
 Run the test for your new plugin using one of the following commands:
 
 ```sh
-pnpm tsx --test test/plugins/tool.test.ts
+node --test test/plugins/tool.test.ts
 bun test test/plugins/tool.test.ts
 ```
 

package/src/docs/explanations/comparison-and-migration.md

@@ -36,6 +36,8 @@ depcheck
 knip --dependencies
 ```
 
+**Project status**: The project is archived and recommends Knip.
+
 ### unimported
 
 > Find and fix dangling files and unused dependencies in your JavaScript

package/src/docs/explanations/plugins.md

@@ -86,8 +86,8 @@ plugins contain `package.json` in the list of `config` files.
 
 :::tip[Summary]
 
-Plugins parse `config` files to find external dependencies. Knip uses this to
-determine unused and unlisted dependencies.
+Plugins load configuration files to find referenced dependencies, and determine
+unused and unlisted dependencies.
 
 :::
 
@@ -100,8 +100,8 @@ dependencies.
 For example, if `next` is listed as a dependency in `package.json`, the Next.js
 plugin will automatically add multiple patterns as entry files, such as
 `pages/**/*.{js,jsx,ts,tsx}`. If `vitest` is listed, the Vitest plugin adds
-`**/*.{test,test-d,spec}.ts` as entry file patterns. Most plugins have entry
-files configured, so you don't have to.
+`**/*.{test,test-d,spec,spec-d}.ts` as entry file patterns. Most plugins have
+entry files configured, so you don't have to.
 
 It's mostly plugins for meta frameworks and test runners that have `entry` files
 configured.
@@ -304,6 +304,23 @@ playwright test -c playwright.web.config.ts
 
 Please see [script parser][10] for more details.
 
+## Config File Location
+
+If configuration files aren't in their default location and they are not
+referenced through some script like `vite -c ./dir/vite.config.ts`, then make
+sure to tell Knip about it. Two examples:
+
+```json title="knip.jsonc"
+{
+  "playwright": { "config": ["e2e/playwright.config.ts"] },
+  "vite": "packages/*/vite.config.ts" // shorthand without `config` and array notation
+}
+```
+
+This is common in projects where a directory like `packages/lib` is not an
+actual workspace with a `package.json` file. Also see [integrated monorepos][11]
+for similar cases.
+
 ## Summary
 
 :::tip[Summary]
@@ -327,3 +344,4 @@ Plugins are configured with two distinct types of files:
 [8]: ../reference/plugins/vitest.md
 [9]: ../guides/handling-issues.mdx#conditional-or-dynamic-dependencies
 [10]: ../features/script-parser.md
+[11]: ../features/integrated-monorepos.md

package/src/docs/features/auto-fix.mdx

@@ -42,10 +42,10 @@ knip --fix --allow-remove-files
 
 Use `--fix-type` to fix only specific issue types:
 
-- `files`
+- `dependencies`
 - `exports`
 - `types`
-- `dependencies`
+- `files`
 - `catalog`
 
 Example:

package/src/docs/guides/handling-issues.mdx

@@ -689,7 +689,7 @@ issue on GitHub. It'll make Knip better for everyone!
 [32]: #dependencies-named-after-nodejs-builtins
 [33]: #unlisted-binaries
 [34]: https://github.com/webpro-nl/knip/blob/e031018e676c47d84873cc2403251c0111ef318d/packages/knip/src/constants.ts#L39-L148
-[35]: ../features/monorepos-and-workspaces.md#lint-a-single-workspace
+[35]: ../features/monorepos-and-workspaces.md#filter-workspaces
 [36]: #template-strings
 [37]: #unrecognized-path-aliases
 [38]: #external-aliased-imports

package/src/docs/guides/issue-reproduction.md

@@ -73,17 +73,17 @@ Other solutions to share a minimal and reproducible case may work well too,
 including:
 
 - A public repository on e.g. GitHub or GitLab.
-- A new [fixtures folder in the Knip repository][9].
+- A pull request with a new [test][9] and/or [fixture folder][10].
 
 The goal is to have an easy and common understanding and reproduction. If you're
 unable to create a reproduction using one of the methods described then please
-clearly explain this in the issue or [contact me][10].
+clearly explain this in the issue or [contact me][11].
 
 ## Pull Request
 
 The optimal way is to add fixtures and failing tests to the Knip repository, and
 open a pull request to discuss the issue! Also see [instructions for
-development][11].
+development][12].
 
 [1]: https://github.com/webpro-nl/knip/issues?q=is%3Aissue
 [2]: https://knip.dev/reference/known-issues
@@ -97,6 +97,7 @@ development][11].
   https://stackblitz.com/github/webpro-nl/knip/tree/main/templates/issue-reproduction/monorepo
 [7]: https://codesandbox.io
 [8]: https://stackblitz.com
-[9]: https://github.com/webpro-nl/knip/tree/main/packages/knip/fixtures
-[10]: https://github.com/webpro
-[11]: https://github.com/webpro-nl/knip/blob/main/.github/DEVELOPMENT.md
+[9]: https://github.com/webpro-nl/knip/blob/main/.github/DEVELOPMENT.md#tests
+[10]: https://github.com/webpro-nl/knip/tree/main/packages/knip/fixtures
+[11]: https://github.com/webpro
+[12]: https://github.com/webpro-nl/knip/blob/main/.github/DEVELOPMENT.md

package/src/docs/guides/performance.md

@@ -105,4 +105,4 @@ individual workspaces][6].
 [3]: ../guides/handling-issues.mdx#external-libraries
 [4]: ../reference/cli.md#--performance
 [5]: ../reference/configuration.md#ignoreexportsusedinfile
-[6]: ../features/monorepos-and-workspaces.md#lint-a-single-workspace
+[6]: ../features/monorepos-and-workspaces.md#filter-workspaces

package/src/docs/overview/features.md

@@ -63,4 +63,4 @@ Also see [related tooling][2].
 [23]: ../features/production-mode.md#strict-mode
 [24]: ../guides/troubleshooting.md#trace
 [25]: ../reference/cli.md#--watch
-[26]: ../features/monorepos-and-workspaces.md#lint-a-single-workspace
+[26]: ../features/monorepos-and-workspaces.md#filter-workspaces

package/src/docs/reference/faq.md

@@ -22,6 +22,65 @@ This FAQ is an attempt to provide some perspective on a few design decisions and
 why certain things work the way they do. Here and there it's intentionally a bit
 more in-depth than the rest of the docs.
 
+## Why should I even bother to do all this?
+
+Because the payoff is huge. While it might take a bit of effort to configure
+Knip correctly initially, a clean module graph gives you absolute confidence in
+your codebase. You can delete dead code, remove unused dependencies, and
+refactor with certainty. It prevents the slow accumulation of technical debt and
+keeps your project lean and fast. Once configured, Knip runs quickly in CI and
+keeps your codebase pristine automatically.
+
+:::tip
+
+Try the [Knip MCP Server][1] or the [Knip Editor Extension][2]. Let your coding
+agent use the built-in MCP Server and create a custom `knip.json` for you, so
+you don't have to.
+
+:::
+
+## Common Pitfalls
+
+### Why shouldn't I ignore or disable configuration hints?
+
+Configuration hints are critical for building a healthy and accurate module
+graph. They usually indicate that Knip cannot resolve a dependency, plugin, or
+entry file. If you ignore or disable these hints, Knip's understanding of your
+project will be incomplete, which inevitably leads to false positives (reporting
+used code as unused). Always address configuration hints first before looking at
+other reported issues.
+
+### Why is it a bad idea to use `ignore` patterns like I do in ESLint?
+
+Knip is not a regular file-based linter like ESLint. It works by analyzing the
+entire interconnected module graph of your project. Using `ignore` patterns does
+not exclude files from the analysis, it only suppresses the reporting of issues
+in those files. This hides real issues and creates blind spots. Instead of
+ignoring files, ensure your entry points and plugins are configured correctly,
+and use `project` patterns to define the boundaries of your codebase. Read more:
+[Configuring Project Files][3].
+
+If you have specific exports (such as types) that are only used within the file
+they are defined, use the [ignoreExportsUsedInFile][4] configuration option
+rather than ignoring the file entirely.
+
+### How should I exclude tests and development tools from the analysis?
+
+A common mistake is trying to exclude test files, storybooks, or development
+tools using `project` or `ignore` patterns. The correct approach is to use
+[production mode][5]. This mode is specifically designed to strictly analyze
+only your production source code and `dependencies`, automatically excluding
+tests and `devDependencies` without requiring complex ignore rules.
+
+### Why shouldn't I run `knip --fix` immediately?
+
+Running `knip --fix` before your configuration is fully settled is dangerous. If
+your configuration is missing entry points or has unresolved hints, Knip might
+think perfectly valid, actively used code is unused. Auto-fixing in this state
+can lead to deleting code that your application relies on. Always verify the
+reported issues manually and ensure your configuration is solid before using the
+`--fix` flag.
+
 ## Comparison
 
 ### Why isn't Knip an ESLint plugin?
@@ -53,10 +112,10 @@ Issues reported by the linter are for you to handle and review.
 
 Besides those differences, Knip has a broader scope:
 
-- Improve DX (see [less is more][1]).
-- Unless using [production mode][2], also lint all source code like tests,
+- Improve DX (see [less is more][6]).
+- Unless using [production mode][5], also lint all source code like tests,
   scripts and Storybook stories.
-- Handle more [types of issues][3] (such as unlisted dependencies).
+- Handle more [types of issues][7] (such as unlisted dependencies).
 
 ## Synergy
 
@@ -89,13 +148,13 @@ Building up the module and dependency graphs requires non-standard module
 resolution and not only static but also dynamic analysis (i.e. actually load and
 execute modules), such as for parsers of plugins to receive the exported value
 of dynamic tooling configuration files. Additionally, [exports consumed by
-external libraries][4] require type information, as supported by the TypeScript
+external libraries][8] require type information, as supported by the TypeScript
 backend. Last but not least, shell script parsing is required to find the right
 entry files, configuration files and dependencies accurately.
 
 The rippling effect of plugins and recursively adding entry files and
 dependencies to build up the graphs is also exactly what's meant by
-["comprehensive" here][5].
+["comprehensive" here][9].
 
 ## Building the graphs
 
@@ -143,7 +202,7 @@ files (`config/vitest.config.ts` and `playwright.e2e.config.ts` in the examples
 above). They're recognized as configuration files and passed to their respective
 plugins, and may contain additional entry files.
 
-Entry files are added to the module graph. [Module resolution][6] might result
+Entry files are added to the module graph. [Module resolution][10] might result
 in additional entry files recursively until no more entry files are found.
 
 ### What does Knip look for in source files?
@@ -156,7 +215,7 @@ all nodes of the generated AST to find:
 - Accessed properties on namespace imports and re-exports to track individual
   export usage
 - Calls to `require.resolve` and `import.meta.resolve`
-- Scripts in template strings (passed to [script parser][7])
+- Scripts in template strings (passed to [script parser][11])
 
 ### What's in the graphs?
 
@@ -194,7 +253,7 @@ there are a few issues with this approach:
 
 - It requires lockfile parsing for each lockfile format and version of each
   package manager.
-- The lockfile doesn't contain whether the package [has types included][8].
+- The lockfile doesn't contain whether the package [has types included][12].
 
 ## Module Resolution
 
@@ -215,12 +274,12 @@ seem to meet all requirements to be usable on its own by Knip:
   `module.js`
 
 A few strategies have been tried and tweaked, and Knip currently uses a
-combination of [oxc-resolver][9], the TypeScript module resolver and a few
+combination of [oxc-resolver][13], the TypeScript module resolver and a few
 customizations. This single custom module resolver function is hooked into the
 TypeScript compiler and language service hosts.
 
-Everything else is handled by `oxc-resolver` for things like [script parsing][7]
-and resolving references to files in other workspaces.
+Everything else is handled by `oxc-resolver` for things like [script
+parsing][11] and resolving references to files in other workspaces.
 
 ### How does Knip handle non-standard import syntax?
 
@@ -250,7 +309,7 @@ file. They're not a concept in Knip.
 
 A TypeScript program has a 1-to-1 relationship with workspaces if they're
 analyzed in isolation. However, by default Knip optimizes for performance and
-utilizes [workspace sharing][10]. That's why debug output contains messages like
+utilizes [workspace sharing][14]. That's why debug output contains messages like
 "Installed 2 programs for 29 workspaces".
 
 ### Why doesn't Knip match my TypeScript project structure?
@@ -282,7 +341,7 @@ Knip shares the files of multiple workspaces in a single program if their
 configuration allows it. This optimization is enabled by default, while it also
 allows the module resolver (one per program) to do some more caching.
 
-Also see [workspace sharing][10].
+Also see [workspace sharing][14].
 
 ### Why doesn't Knip just use `ts.findReferences`?
 
@@ -298,7 +357,7 @@ comprehensive graph include:
 Without sacrificing these benefits, Knip does use `ts.findReferences` to find
 references to class members (i.e. when the issue type `classMembers` is
 included). In case analysis of exports requires type information of external
-dependencies, the [`--include-libs ` flag][4] will trigger the same.
+dependencies, the [`--include-libs ` flag][8] will trigger the same.
 
 ### Why can't I use path aliases to reference other workspaces?
 
@@ -310,19 +369,19 @@ The recommendation and best practice is to list such workspaces/dependencies in
 `package.json`, and import them as such. Other tooling should not have any
 issues with this standard approach either.
 
-Also see the example in [TypeScript path aliases in monorepos][11].
+Also see the example in [TypeScript path aliases in monorepos][15].
 
 ### What's up with that configurable `tsconfig.json` location?
 
 There's a difference between `--tsConfig [file]` as a CLI argument and the
 `typescript.config` option in Knip configuration.
 
-The [`--tsConfig [file]` option][12] is used to provide an alternative location
+The [`--tsConfig [file]` option][16] is used to provide an alternative location
 for the default root `tsconfig.json` file. Relevant `compilerOptions` include
 `paths` and `moduleResolution`. This setting is only available at the root
 level.
 
-On the other hand, the [`config` option of the plugin][13] can be set per
+On the other hand, the [`config` option of the plugin][17] can be set per
 workspace. The TypeScript plugin extracts referenced external dependencies such
 as those in `extends`, `compilerOptions.types` and JSX settings:
 
@@ -346,7 +405,7 @@ From this example, Knip can determine whether the `@tsconfig/node20` and
   for `tsconfig.json` can be set per workspace.
 - In case path aliases from `compilerOptions.paths` aren't picked up by Knip,
   either use `--tsConfig [file]` to target a different `tsconfig.json`, or
-  manually add [paths][14] to the Knip configuration. The latter can be done per
+  manually add [paths][18] to the Knip configuration. The latter can be done per
   workspace.
 
 ## Compilers
@@ -369,7 +428,7 @@ other file types.
 Knip comes with basic "compilers" for a few common non-standard file types.
 They're not actual compilers, they're regular expressions only to extract import
 statements. Override the built-in Vue "compiler" with the real one in your
-project. Also see the answer to the previous question and [Compilers][15].
+project. Also see the answer to the previous question and [Compilers][19].
 
 ## Miscellaneous
 
@@ -389,7 +448,7 @@ Which mode should've been the default? They both have their merits:
   tooling, including most issues found in production mode. This mode has the
   most impact on DX, for the same reason.
 
-Also see [production mode][2].
+Also see [production mode][5].
 
 ### Why doesn't Knip have...?
 
@@ -410,21 +469,25 @@ Examples of features that have been requested include:
 
 These are all interesting ideas, but most increase the API surface area, and all
 require more development efforts and maintenance. Time is limited and
-[sponsorships][16] currently don't cover - this can change though!
-
-[1]: ../explanations/why-use-knip.md#less-is-more
-[2]: ../features/production-mode.md
-[3]: ./issue-types.md
-[4]: ../guides/handling-issues.mdx#external-libraries
-[5]: ../explanations/why-use-knip.md#comprehensive
-[6]: #module-resolution
-[7]: ../features/script-parser.md
-[8]: ../guides/handling-issues.mdx#type-definition-packages
-[9]: https://oxc.rs/docs/guide/usage/resolver.html
-[10]: ../guides/performance.md#workspace-sharing
-[11]: ../guides/handling-issues.mdx#typescript-path-aliases-in-monorepos
-[12]: ../reference/cli.md#--tsconfig-file
-[13]: ../explanations/plugins.md#configuration-files
-[14]: ../reference/configuration.md#paths
-[15]: ../features/compilers.md
-[16]: /sponsors
+[sponsorships][20] currently don't cover - this can change though!
+
+[1]: ../reference/integrations.md#mcp-server
+[2]: ../reference/integrations.md#vs-code-extension
+[3]: ../guides/configuring-project-files.md
+[4]: ../reference/configuration.md#ignoreexportsusedinfile
+[5]: ../features/production-mode.md
+[6]: ../explanations/why-use-knip.md#less-is-more
+[7]: ./issue-types.md
+[8]: ../guides/handling-issues.mdx#external-libraries
+[9]: ../explanations/why-use-knip.md#comprehensive
+[10]: #module-resolution
+[11]: ../features/script-parser.md
+[12]: ../guides/handling-issues.mdx#type-definition-packages
+[13]: https://oxc.rs/docs/guide/usage/resolver.html
+[14]: ../guides/performance.md#workspace-sharing
+[15]: ../guides/handling-issues.mdx#typescript-path-aliases-in-monorepos
+[16]: ../reference/cli.md#--tsconfig-file
+[17]: ../explanations/plugins.md#configuration-files
+[18]: ../reference/configuration.md#paths
+[19]: ../features/compilers.md
+[20]: /sponsors

package/src/docs/reference/jsdoc-tsdoc-tags.md

@@ -30,7 +30,7 @@ Example:
 export const myUnusedExport = 1;
 
 /** @lintignore */
-import Unresolved from './generated/lib.js';
+import Unresolved from "./generated/lib.js";
 ```
 
 And then include (`+`) or exclude (`-`) these tagged exports from the report
@@ -42,6 +42,17 @@ knip --tags=-lintignore,-internal
 
 Tags can also be [configured in `knip.json`][2].
 
+When an excluded tag is no longer necessary because the export is actually used,
+Knip reports a **tag hint**:
+
+```sh
+Tag hints (1)
+ignored  unimported.ts  Unused tag in unimported.ts: ignored → @custom
+```
+
+This helps you clean up tags that were added to suppress issues that have since
+been resolved.
+
 ## `@public`
 
 By default, Knip reports unused exports in non-entry files.

package/src/docs/reference/plugins.md

@@ -1,5 +1,5 @@
 ---
-title: Plugins (131)
+title: Plugins (137)
 tableOfContents: false
 ---
 
@@ -32,6 +32,7 @@ tableOfContents: false
 - [Drizzle](/reference/plugins/drizzle "Drizzle")
 - [Eleventy](/reference/plugins/eleventy "Eleventy")
 - [ESLint](/reference/plugins/eslint "ESLint")
+- [execa](/reference/plugins/execa "execa")
 - [Expo](/reference/plugins/expo "Expo")
 - [Expressive Code](/reference/plugins/expressive-code "Expressive Code")
 - [Gatsby](/reference/plugins/gatsby "Gatsby")
@@ -75,16 +76,20 @@ tableOfContents: false
 - [oclif](/reference/plugins/oclif "oclif")
 - [Oxlint](/reference/plugins/oxlint "Oxlint")
 - [Parcel](/reference/plugins/parcel "Parcel")
+- [Payload CMS](/reference/plugins/payload "Payload CMS")
 - [Playwright](/reference/plugins/playwright "Playwright")
 - [Playwright for components](/reference/plugins/playwright-ct "Playwright for components")
 - [playwright-test](/reference/plugins/playwright-test "playwright-test")
 - [Plop](/reference/plugins/plop "Plop")
+- [pm2](/reference/plugins/pm2 "pm2")
 - [pnpm](/reference/plugins/pnpm "pnpm")
 - [PostCSS](/reference/plugins/postcss "PostCSS")
 - [Preconstruct](/reference/plugins/preconstruct "Preconstruct")
 - [Prettier](/reference/plugins/prettier "Prettier")
 - [Prisma](/reference/plugins/prisma "Prisma")
+- [Qwik](/reference/plugins/qwik "Qwik")
 - [React Cosmos](/reference/plugins/react-cosmos "React Cosmos")
+- [React Native](/reference/plugins/react-native "React Native")
 - [React Router](/reference/plugins/react-router "React Router")
 - [Relay](/reference/plugins/relay "Relay")
 - [Release It!](/reference/plugins/release-it "Release It!")
@@ -135,6 +140,7 @@ tableOfContents: false
 - [xo](/reference/plugins/xo "xo")
 - [Yarn](/reference/plugins/yarn "Yarn")
 - [yorkie](/reference/plugins/yorkie "yorkie")
+- [zx](/reference/plugins/zx "zx")
 
 
 :::

package/src/docs/writing-a-plugin/index.md

@@ -365,7 +365,7 @@ The script adds the plugin to the JSON Schema and type definitions.
 Run the test for your new plugin using one of the following commands:
 
 ```sh
-pnpm tsx --test test/plugins/tool.test.ts
+node --test test/plugins/tool.test.ts
 bun test test/plugins/tool.test.ts
 ```