@knip/mcp 0.0.18 → 0.0.20

package/src/docs/reference/configuration.md

@@ -180,6 +180,13 @@ notation below is valid and will report only exports tagged `@lintignore` or
 }
 ```
 
+:::caution
+
+Tags must not contain hyphens or plus symbols, so it is recommended to stick to
+letters and avoid snake-case.
+
+:::
+
 Also see [JSDoc & TSDoc Tags][8].
 
 ### `treatConfigHintsAsErrors`
@@ -198,17 +205,23 @@ Exit with non-zero code (1) if there are any configuration hints.
 
 :::tip
 
-Please read [configuring project files][9] before using the `ignore` option,
-because in most cases you'll want to fine‑tune `entry` and `project` (or use
-production mode) instead.
+Please read [configuring project files][9] before using the `ignore` option.
 
 :::
 
-Array of glob patterns to ignore issues from matching files. Example:
+Avoid `ignore` patterns. There is almost always a better solution:
+
+- Follow up on configuration hints (if there are any).
+- Fine-tune `entry` and `project` patterns.
+- Use [production mode][10].
+- Other `ignore*` options.
+
+**NOTE**: An exception to the rule: to _temporarily_ report only issues in files
+that match the negated `ignore` pattern:
 
 ```json title="knip.json"
 {
-  "ignore": ["src/generated.ts", "fixtures/**"]
+  "ignore": ["!src/dir/**"]
 }
 ```
 
@@ -271,6 +284,8 @@ export default {
 
 Suffix an item with `!` to enable it only in production mode.
 
+Also see [Unused dependencies][11].
+
 ### `ignoreMembers`
 
 Array of class and enum members to exclude from the report. Regular expressions
@@ -399,7 +414,7 @@ files (`.js` or `.ts`), not in JSON configuration files.
 
 Override built-in compilers or add custom compilers for additional file types.
 
-Also see [Compilers][10].
+Also see [Compilers][12].
 
 [1]: ../reference/dynamic-configuration.mdx
 [2]: ../overview/configuration.md
@@ -410,4 +425,6 @@ Also see [Compilers][10].
 [7]: ../features/rules-and-filters.md#filters
 [8]: ./jsdoc-tsdoc-tags.md
 [9]: ../guides/configuring-project-files.md
-[10]: ../features/compilers.md
+[10]: ../features/production-mode.md
+[11]: ../guides/handling-issues.mdx#unused-dependencies
+[12]: ../features/compilers.md

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?
@@ -38,27 +97,25 @@ File-oriented linters like ESLint are complementary to Knip.
 ### Isn't tree-shaking enough?
 
 In short: no. They share an important goal: improve UX by removing unused code.
-The main takeaway here is that tree-shaking and Knip are different and
-complementary tools.
+But tree-shaking and Knip are different and complementary tools.
 
 Tree-shaking is a build or compile-time activity to reduce production bundle
 size. It typically operates on bundled production code, which might include
-external/third-party code. An optimization in the build process, "out of your
-hands".
+external/third-party code. A build time optimization and "out of your hands".
 
-On the other hand, Knip is a project linter that should be part of the QA phase.
-It lints, reports and fixes only your own source code. Moreover, in contrast
-with other linters, focuses on inter-file dependencies, so dead code within a
-file may not be caught by Knip.
+On the other hand, Knip is a project linter that should be part of the
+development and QA phase. It lints, reports and fixes only your own source code.
+Moreover, in contrast with other linters, focuses on inter-file dependencies, so
+dead code within a file may not be caught by Knip.
 
-Issues reported by the linter are then for you to handle (except for everything
-that Knip [auto-fixes][1] for you).
+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][2]).
-- Include non-production code and dependencies in the process by default.
-- Handle more [types of issues][3] (such as unlisted dependencies).
+- 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][7] (such as unlisted dependencies).
 
 ## Synergy
 
@@ -91,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
 
@@ -145,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?
@@ -158,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?
 
@@ -196,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
 
@@ -217,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?
 
@@ -252,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?
@@ -284,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`?
 
@@ -300,34 +357,31 @@ 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?
 
 Projects can use `compilerOptions.paths` to alias paths in other workspaces in
 the same monorepo. Knip doesn't understand those paths might represent internal
-workspaces and might report false positives. How we ended up here is a bit
-complicated, but a major reason is that Knip does it's job based on the
-workspace graph, while [workspaces are different from TypeScript programs][11]
-and [the workspace graph doesn't match TypeScript project structure][12].
+workspaces and might report false positives.
 
 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][13].
+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][14] 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][15] 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:
 
@@ -351,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][16] 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
@@ -374,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][17].
+project. Also see the answer to the previous question and [Compilers][19].
 
 ## Miscellaneous
 
@@ -394,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][18].
+Also see [production mode][5].
 
 ### Why doesn't Knip have...?
 
@@ -408,34 +462,32 @@ Examples of features that have been requested include:
   - Unused object members (and e.g. React component props)
   - Unused object props in function return values
 - Analyze workspaces in parallel
-- Plugins for editors like VS Code and WebStorm (LSP-based?)
 - Support Deno
 - Improve internal code structures and accessibility to support contributions
-- One-shot dead code removal (more comprehensive removal of unused variables,
-  duplicate exports, dead code, etc).
 - Replace dependencies for better performance and correctness, such as for shell
-  script parsing, module resolution and globbing with "unignores".
+  script parsing and globbing with "unignores".
 
 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][19] currently don't cover - this can change though!
-
-[1]: ../features/auto-fix.mdx
-[2]: ../explanations/why-use-knip.md#less-is-more
-[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#types-packages
-[9]: https://oxc.rs/docs/guide/usage/resolver.html
-[10]: ../guides/performance.md#workspace-sharing
-[11]: #whats-the-difference-between-workspaces-projects-and-programs
-[12]: #why-doesnt-knip-match-my-typescript-project-structure
-[13]: ../guides/handling-issues.mdx#typescript-path-aliases-in-monorepos
-[14]: ../reference/cli.md#--tsconfig-file
-[15]: ../explanations/plugins.md#configuration-files
-[16]: ../reference/configuration.md#paths
-[17]: ../features/compilers.md
-[18]: ../features/production-mode.md
-[19]: /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/known-issues.md

@@ -2,31 +2,50 @@
 title: Known Issues
 ---
 
-This page contains a list of known issues you might run into when using Knip.
+List of known issues and workarounds for exceptions thrown during a Knip run.
+
+See [handling issues][1] to learn more about dealing with lint issues.
 
 ## Exceptions from config files
 
 An exception may be thrown when a Knip plugin loads a JavaScript or TypeScript
-configuration file such as `webpack.config.js` or `vite.config.ts`. Knip may
-load such files differently, in a different environment, or without certain
-environment variables set.
+configuration file such as `webpack.config.js` or `vite.config.ts`:
 
-If it isn't clear what's throwing the exception, try another run with `--debug`
-to locate the cause of the issue with more details. Examples of issues when Knip
-loads configuration files:
+```sh
+$ knip
+Error loading .../vite.config.ts
+```
 
-- Missing environment variable
-- Relative path (e.g. which is sometimes not resolved from correct directory,
-  try `import.meta.dirname` or `__dirname`)
+Knip may load such files differently, in a different environment, with missing
+environment variables, missing path aliases, etcetera. Use `--debug` to locate
+the cause of the issue with more details.
 
-As a last resort, the [plugin can be disabled][1].
+Potential workarounds:
+
+- [Set path aliases][2] for "Cannot find module" errors
+- Set missing environment variable(s), potential solutions:
+  - Use a helper package like [dotenvx][3]
+  - `KEY=VAL knip`
+  - `node --env-file .env $(which knip)`
+- Disable loading the file by overriding the default `config` for that plugin.
+  - Example: `vite: { config: [] }`
+  - In a monorepo, be more specific like so:
+    `workspaces: { "packages/lib": { vite: { config: [] } } }`
+  - If this helps, add the file as an `entry` file for static analysis.
+- Disable the related plugin.
+  - Example: `eslint: false`
+  - In a monorepo, be more specific like so:
+    `workspaces: { "packages/lib": { eslint: false } }`
+  - If this helps, add the file as an `entry` file for static analysis.
+- As a last resort, ignore the workspace: `ignoreWorkspaces: ["packages/lib"]`.
 
 ## Path aliases in config files
 
 Loading the configuration file (e.g. `cypress.config.ts`) for one of Knip's
 plugins may give an error:
 
-```
+```sh
+$ knip
 Analyzing workspace ....
 Error loading .../cypress.config.ts
 Reason: Cannot find module '@alias/name'
@@ -35,15 +54,15 @@ Require stack:
 ```
 
 Some tools (such as Cypress and Jest) support using TypeScript path aliases in
-the configuration file. Jiti does support aliases, but in a different format
-compared to `tsconfig.json#compilerOptions.paths` and `knip.json#paths` (e.g.
-the target values are not arrays).
+the configuration file.
 
 Potential workarounds:
 
 - Rewrite the import in the configuration file to a relative import.
-- Use Bun with [knip-bun][2].
-- [Disable the plugin][1] (not recommended, try the other options first).
+- Inject support with a module like `tsx`: `NODE_OPTIONS="--import tsx" knip`
+- Or `tsconfig-paths`: `NODE_OPTIONS="--import tsconfig-paths/register.js" knip`
+- Use Bun with [knip-bun][4].
+- See [exceptions from config files][5] for more potential workarounds.
 
 ## Nx Daemon
 
@@ -53,12 +72,15 @@ In Nx projects you might encounter this error:
 NX   Daemon process terminated and closed the connection
 ```
 
-The solution is to [disable the Nx Daemon][3]:
+The solution is to [disable the Nx Daemon][6]:
 
 ```sh
 NX_DAEMON=false knip
 ```
 
-[1]: ./configuration.md#plugins
-[2]: ./cli.md#knip-bun
-[3]: https://nx.dev/concepts/nx-daemon#turning-it-off
+[1]: ../guides/handling-issues.mdx
+[2]: #path-aliases-in-config-files
+[3]: https://dotenvx.com/
+[4]: ./cli.md#knip-bun
+[5]: #exceptions-from-config-files
+[6]: https://nx.dev/concepts/nx-daemon#turning-it-off

package/src/docs/reference/plugins.md

@@ -1,5 +1,5 @@
 ---
-title: Plugins (123)
+title: Plugins (137)
 tableOfContents: false
 ---
 
@@ -7,6 +7,7 @@ tableOfContents: false
 - [Angular](/reference/plugins/angular "Angular")
 - [Astro](/reference/plugins/astro "Astro")
 - [Astro DB](/reference/plugins/astro-db "Astro DB")
+- [astro-og-canvas](/reference/plugins/astro-og-canvas "astro-og-canvas")
 - [Ava](/reference/plugins/ava "Ava")
 - [Babel](/reference/plugins/babel "Babel")
 - [Biome](/reference/plugins/biome "Biome")
@@ -31,7 +32,9 @@ 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")
 - [GitHub Action](/reference/plugins/github-action "GitHub Action")
 - [GitHub Actions](/reference/plugins/github-actions "GitHub Actions")
@@ -42,6 +45,7 @@ tableOfContents: false
 - [i18next Parser](/reference/plugins/i18next-parser "i18next Parser")
 - [Jest](/reference/plugins/jest "Jest")
 - [Karma](/reference/plugins/karma "Karma")
+- [Knex](/reference/plugins/knex "Knex")
 - [Ladle](/reference/plugins/ladle "Ladle")
 - [Lefthook](/reference/plugins/lefthook "Lefthook")
 - [lint-staged](/reference/plugins/lint-staged "lint-staged")
@@ -61,6 +65,7 @@ tableOfContents: false
 - [Next.js](/reference/plugins/next "Next.js")
 - [next-intl](/reference/plugins/next-intl "next-intl")
 - [Next.js MDX](/reference/plugins/next-mdx "Next.js MDX")
+- [Nitro](/reference/plugins/nitro "Nitro")
 - [Node.js](/reference/plugins/node "Node.js")
 - [node-modules-inspector](/reference/plugins/node-modules-inspector "node-modules-inspector")
 - [nodemon](/reference/plugins/nodemon "nodemon")
@@ -70,16 +75,21 @@ tableOfContents: false
 - [nyc](/reference/plugins/nyc "nyc")
 - [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!")
@@ -100,11 +110,13 @@ tableOfContents: false
 - [Stryker](/reference/plugins/stryker "Stryker")
 - [Stylelint](/reference/plugins/stylelint "Stylelint")
 - [Svelte](/reference/plugins/svelte "Svelte")
+- [SvelteKit](/reference/plugins/sveltekit "SvelteKit")
 - [SVGO](/reference/plugins/svgo "SVGO")
 - [SVGR](/reference/plugins/svgr "SVGR")
 - [SWC](/reference/plugins/swc "SWC")
 - [Syncpack](/reference/plugins/syncpack "Syncpack")
 - [Tailwind](/reference/plugins/tailwind "Tailwind")
+- [TanStack Router](/reference/plugins/tanstack-router "TanStack Router")
 - [Taskfile](/reference/plugins/taskfile "Taskfile")
 - [Travis CI](/reference/plugins/travis "Travis CI")
 - [ts-node](/reference/plugins/ts-node "ts-node")
@@ -118,6 +130,7 @@ tableOfContents: false
 - [Vercel OG](/reference/plugins/vercel-og "Vercel OG")
 - [Vike](/reference/plugins/vike "Vike")
 - [Vite](/reference/plugins/vite "Vite")
+- [VitePress](/reference/plugins/vitepress "VitePress")
 - [Vitest](/reference/plugins/vitest "Vitest")
 - [Vue](/reference/plugins/vue "Vue")
 - [WebdriverIO](/reference/plugins/webdriver-io "WebdriverIO")
@@ -127,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/reference/related-tooling.md

@@ -4,10 +4,10 @@ title: Related Tooling
 
 This is an overview of related tooling for features Knip does not support.
 
-## Unused variables
+## Unused imports & variables
 
-Knip doesn't look for unused variables within a file. The focus is on exported
-and imported values and types across files.
+Knip doesn't look for unused imports and variables within a file. The focus is
+on exported values and types across files.
 
 Use [ESLint][1], [Biome][2] or [oxlint][3] to find unused variables within
 files.

package/src/docs/sponsors.mdx

@@ -8,7 +8,6 @@ import Posts from '../../components/Posts.astro';
 import Projects from '../../components/Projects.astro';
 import SponsorsComponent from '../../components/Sponsors.astro';
 import SponsorsChart from '../../components/SponsorsChart.astro';
-import SponsorsPast from '../../components/SponsorsPast.astro';
 
 :::article{.prose}
 
@@ -40,8 +39,8 @@ one year before that.
 
 <SponsorsChart />
 
-- The monthly aggregated average over the charted period is $514.
-- The monthly recurring average without one-time payments is $339.
+- The monthly aggregated average over the charted period is $513.
+- The monthly recurring average without one-time payments is $350.
 - GitHub Sponsors is for my GitHub account. This has more repositories, but in
   practice targets mostly Knip (and perhaps some [release-it][5]).
 - [Chart generated][6] using [Venz][7].
@@ -61,5 +60,5 @@ one year before that.
 [3]: https://github.com/sponsors/webpro
 [4]: https://opencollective.com/knip
 [5]: https://github.com/release-it/release-it
-[6]: https://try.venz.dev?type=pivot&lp=tr&br=0&labelX=month&labelY=amount+\($\)&l=GitHub+Sponsors&color=%23fbfbfb&l=Open+Collective&color=%232487ff&label=2023-11&data=9,0&label=2023-12&data=74,0&label=2024-01&data=239,0&label=2024-02&data=489,0&label=2024-03&data=189,0&label=2024-04&data=204,750&label=2024-05&data=304,101&label=2024-06&data=1204,0&label=2024-07&data=204,35&label=2024-08&data=229,25&label=2024-09&data=2729,25&label=2024-10&data=410,45&label=2024-11&data=222,45&label=2024-12&data=222,145&label=2025-01&data=342,145&label=2025-02&data=244,145&label=2025-03&data=222,145&label=2025-04&data=222,145&label=2025-05&data=242,145&label=2025-06&data=247,145&label=2025-07&data=297,145&label=2025-08&data=268,145&label=2025-09&data=350,145&label=2025-10&data=375,145
+[6]: https://try.venz.dev?type=pivot&lp=tr&br=0&labelX=month&labelY=amount+\($\)&l=GitHub+Sponsors&color=%23fbfbfb&l=Open+Collective&color=%232487ff&label=2023-11&data=9,0&label=2023-12&data=74,0&label=2024-01&data=239,0&label=2024-02&data=489,0&label=2024-03&data=189,0&label=2024-04&data=204,750&label=2024-05&data=304,101&label=2024-06&data=1204,0&label=2024-07&data=204,35&label=2024-08&data=229,25&label=2024-09&data=2729,25&label=2024-10&data=410,45&label=2024-11&data=222,45&label=2024-12&data=222,145&label=2025-01&data=342,145&label=2025-02&data=244,145&label=2025-03&data=222,145&label=2025-04&data=222,145&label=2025-05&data=242,145&label=2025-06&data=247,145&label=2025-07&data=297,145&label=2025-08&data=268,145&label=2025-09&data=350,145&label=2025-10&data=375,145&label=2025-11&data=549,145&label=2025-12&data=355,145
 [7]: https://try.venz.dev

package/src/docs/typescript/unused-exports.md

@@ -68,7 +68,7 @@ to easily navigate around.
 
 ## How is Knip different from ESLint for finding unused exports?
 
-While linters like ESLint can find unused variables and imports within
+While linters like ESLint can find unused imports and variables within
 individual files, Knip analyzes the entire project to determine which exports
 are actually unused. By building [a comprehensive module graph][7], Knip
 identifies exports that are not imported or used anywhere in the codebase. This