@knip/mcp 0.0.22 → 0.0.23

package/src/docs/docs/overview/getting-started.mdx

@@ -8,7 +8,7 @@ import { Tabs, TabItem } from '@astrojs/starlight/components';
 
 ## Requirements
 
-Knip v5 requires at least Node.js v18.18.0. Or Bun.
+Knip v6 requires at least Node.js v20.19.0. Or Bun.
 
 Want to try Knip without installation? Visit [the playground][1].
 

package/src/docs/docs/reference/cli.md

@@ -99,24 +99,6 @@ knip --include-entry-exports
 
 Also see [includeEntryExports][5].
 
-### `--include-libs`
-
-Getting false positives for exports consumed by external libraries? Try the
-`--include-libs` flag:
-
-```sh
-knip --include-libs
-```
-
-Also see [external libs][6].
-
-### `--isolate-workspaces`
-
-By default, Knip optimizes performance using [workspace sharing][7] to existing
-TypeScript programs, based on the compatibility of their `compilerOptions`. This
-flag disables this behavior and creates one program per workspace, which is
-slower but memory usage is spread more evenly over time.
-
 ### `--no-gitignore`
 
 Ignore `.gitignore` files.
@@ -131,14 +113,14 @@ Lint only production source files. This excludes:
   - Storybook stories
 - `devDependencies` from `package.json`
 
-Read more at [Production Mode][8].
+Read more at [Production Mode][6].
 
 ### `--strict`
 
 Isolate workspaces and consider only direct dependencies. Implies [production
-mode][9].
+mode][7].
 
-Read more at [Production Mode][8].
+Read more at [Production Mode][6].
 
 ### `--watch`
 
@@ -157,7 +139,7 @@ workspaces). The default behavior is to lint all configured workspaces.
 
 Shortcut: `-W`
 
-See [filter workspaces][10] for more details and examples.
+See [filter workspaces][8] for more details and examples.
 
 ### `--directory [dir]`
 
@@ -172,8 +154,7 @@ Exclude provided issue types from report. Can be comma-separated or repeated.
 Example:
 
 ```sh
-knip --exclude classMembers,enumMembers
-knip --exclude classMembers --exclude enumMembers
+knip --exclude enumMembers
 ```
 
 ### `--include`
@@ -187,7 +168,7 @@ knip --include files,dependencies
 knip --include files --include dependencies
 ```
 
-Available [issue types][11] when filtering output using `--include` or
+Available [issue types][9] when filtering output using `--include` or
 `--exclude`:
 
 - `files`
@@ -196,10 +177,10 @@ Available [issue types][11] when filtering output using `--include` or
 - `unresolved`
 - `exports`
 - `nsExports`
-- `classMembers`
 - `types`
 - `nsTypes`
 - `enumMembers`
+- `namespaceMembers`
 - `duplicates`
 - `catalog`
 
@@ -216,7 +197,7 @@ Shortcut to include all types of dependency issues:
 Shortcut to include all types of export issues:
 
 ```sh
---include exports,nsExports,classMembers,types,nsTypes,enumMembers,duplicates
+--include exports,nsExports,types,nsTypes,enumMembers,namespaceMembers,duplicates
 ```
 
 ### `--files`
@@ -251,7 +232,7 @@ knip --tags=+custom
 ```
 
 This way, you can either focus on or ignore specific tagged exports with tags
-you define yourself. This also works for individual class or enum members.
+you define yourself. This also works for individual enum and namespace members.
 
 The default directive is `+` (include) and the `@` prefix is ignored, so the
 notation below is valid and will report only exports tagged `@lintignore` or
@@ -265,13 +246,13 @@ knip --tags @lintignore --tags @internal
 
 ### `--fix`
 
-Read more at [auto-fix][12].
+Read more at [auto-fix][10].
 
 ### `--fix-type`
 
 Fix only issues of type, can be comma-separated or repeated.
 
-More info about fixable types at [issue types][11]
+More info about fixable types at [issue types][9]
 
 ### `--allow-remove-files`
 
@@ -285,7 +266,7 @@ Format modified files after `--fix` using the local formatter.
 
 ### `--preprocessor [preprocessor]`
 
-Preprocess the results before providing it to the [reporter(s)][13].
+Preprocess the results before providing it to the [reporter(s)][11].
 
 Can be repeated. Examples:
 
@@ -297,7 +278,7 @@ knip --preprocessor ./my-preprocessor.ts
 knip --preprocessor preprocessor-package
 ```
 
-Also see [Reporters & Preprocessors][14].
+Also see [Reporters & Preprocessors][12].
 
 ### `--preprocessor-options [json]`
 
@@ -326,7 +307,7 @@ Can be repeated. Example:
 knip --reporter compact
 ```
 
-Also see [Reporters & Preprocessors][14].
+Also see [Reporters & Preprocessors][12].
 
 ### `--reporter-options [json]`
 
@@ -372,7 +353,7 @@ The default exit codes:
 
 Shortcut: `-d`
 
-Show [debug output][15].
+Show [debug output][13].
 
 ### `--memory`
 
@@ -402,9 +383,6 @@ knip --memory
 Total running time: 4.3s
 ```
 
-Can be used with [--isolate-workspaces][16] to see the difference in garbage
-collection during the process.
-
 ### `--memory-realtime`
 
 Use this if Knip crashes to still see memory usage info over time:
@@ -452,7 +430,7 @@ Total running time: 5s
 - `sum` the accumulated time of all invocations
 
 This is not yet available in Bun, since it does not support
-`performance.timerify` ([GitHub issue][17]).
+`performance.timerify` ([GitHub issue][14]).
 
 ### `--performance-fn`
 
@@ -475,37 +453,34 @@ Total running time: 12.9s
 
 Trace exports to see where they are imported.
 
-Also see [Trace][18].
+Also see [Trace][15].
 
 ### `--trace-dependency [name]`
 
 Trace package or binary name to see where it's referenced. Implies
-[--trace][19].
+[--trace][16].
 
 ### `--trace-export [name]`
 
-Trace export name to see where it's imported. Implies [--trace][19].
+Trace export name to see where it's imported. Implies [--trace][16].
 
 ### `--trace-file [path]`
 
-Trace file to see where its exports are imported. Implies [--trace][19].
+Trace file to see where its exports are imported. Implies [--trace][16].
 
 [1]: https://bun.sh
 [2]: ../reference/known-issues.md
 [3]: https://no-color.org/
 [4]: https://www.npmjs.com/package/picocolors
 [5]: ./configuration.md#includeentryexports
-[6]: ../guides/handling-issues.mdx#external-libraries
-[7]: ../guides/performance.md#workspace-sharing
-[8]: ../features/production-mode.md
-[9]: #--production
-[10]: ../features/monorepos-and-workspaces.md#filter-workspaces
-[11]: ./issue-types.md
-[12]: ../features/auto-fix.mdx
-[13]: #--reporter-reporter
-[14]: ../features/reporters.md
-[15]: ../guides/troubleshooting.md#debug
-[16]: #--isolate-workspaces
-[17]: https://github.com/oven-sh/bun/issues/9271
-[18]: ../guides/troubleshooting.md#trace
-[19]: #--trace
+[6]: ../features/production-mode.md
+[7]: #--production
+[8]: ../features/monorepos-and-workspaces.md#filter-workspaces
+[9]: ./issue-types.md
+[10]: ../features/auto-fix.mdx
+[11]: #--reporter-reporter
+[12]: ../features/reporters.md
+[13]: ../guides/troubleshooting.md#debug
+[14]: https://github.com/oven-sh/bun/issues/9271
+[15]: ../guides/troubleshooting.md#trace
+[16]: #--trace

package/src/docs/docs/reference/configuration.md

@@ -16,7 +16,7 @@ In JSON, use the provided JSON schema:
 
 ```json title="knip.json"
 {
-  "$schema": "https://unpkg.com/knip@5/schema.json"
+  "$schema": "https://unpkg.com/knip@6/schema.json"
 }
 ```
 
@@ -26,7 +26,7 @@ In JSONC, use the provided JSONC schema:
 
 ```json title="knip.jsonc"
 {
-  "$schema": "https://unpkg.com/knip@5/schema-jsonc.json"
+  "$schema": "https://unpkg.com/knip@6/schema-jsonc.json"
 }
 ```
 
@@ -168,7 +168,7 @@ like so:
 ```
 
 This way, you can either focus on or ignore specific tagged exports with tags
-you define yourself. This also works for individual class or enum members.
+you define yourself. This also works for individual enum and namespace members.
 
 The default directive is `+` (include) and the `@` prefix is ignored, so the
 notation below is valid and will report only exports tagged `@lintignore` or
@@ -288,8 +288,8 @@ Also see [Unused dependencies][11].
 
 ### `ignoreMembers`
 
-Array of class and enum members to exclude from the report. Regular expressions
-allowed. Example:
+Array of enum and namespace members to exclude from the report. Regular
+expressions allowed. Example:
 
 ```json title="knip.json"
 {
@@ -347,7 +347,7 @@ reporting other issues in those same files.
 {
   "ignoreIssues": {
     "src/generated/**": ["exports", "types"],
-    "**/*.generated.ts": ["exports", "classMembers"]
+    "**/*.generated.ts": ["exports", "enumMembers", "namespaceMembers"]
   }
 }
 ```
@@ -394,7 +394,7 @@ If enabled, Knip will report unused exports in entry source files. But not in
 entry and configuration files as configured by plugins, such as `next.config.js`
 or `src/routes/+page.svelte`.
 
-This will also enable reporting unused members of exported classes and enums.
+This will also enable reporting unused members of exported enums and namespaces.
 
 Set this option at root level to enable this globally, or within workspace
 configurations individually.

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

@@ -144,13 +144,13 @@ imports of internal modules or external dependencies, and so on.
 Even though a modular approach has its merits, for Knip it makes sense to have
 all the pieces in a single tool.
 
-Building up the module and dependency graphs requires non-standard module
+Building up the module and dependency graphs requires more than 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][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.
+external libraries][8] require type information. 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
@@ -171,7 +171,7 @@ dependencies to build up the graphs is also exactly what's meant by
 - Through scripts inside template strings in source files such as:
 
 ```ts
-await $({ stdio: 'inherit' })`c8 node hydrate.js`; // execa
+await $({ stdio: "inherit" })`c8 node hydrate.js`; // execa
 await $`node scripts/parse.js`; // bun/zx
 ```
 
@@ -207,14 +207,14 @@ in additional entry files recursively until no more entry files are found.
 
 ### What does Knip look for in source files?
 
-The TypeScript source file parser is powerful and fault-tolerant. Knip visits
-all nodes of the generated AST to find:
+oxc-parser is powerful and fault-tolerant. Knip visits all nodes of the
+generated AST to find:
 
 - Imports and dynamic imports of internal modules and external dependencies
 - Exports
 - Accessed properties on namespace imports and re-exports to track individual
   export usage
-- Calls to `require.resolve` and `import.meta.resolve`
+- Calls to `require.resolve`, `import.meta.resolve` and more.
 - Scripts in template strings (passed to [script parser][11])
 
 ### What's in the graphs?
@@ -232,10 +232,11 @@ required to create the report including all issue types:
 - Unused exports
 - Unused exported types
 - Unused exported enum members
+- Unused exported namespace members
 - Duplicate exports
 
 And optionally more issue types like individual exports and exported types in
-namespace imports, and unused class members.
+namespace imports.
 
 The graphs allows to report more interesting details, such as:
 
@@ -249,11 +250,14 @@ The graphs allows to report more interesting details, such as:
 
 Knip reads the `package.json` file of each dependency. Most of the information
 required is in the lockfile as well, which would be more efficient. However,
-there are a few issues with this approach:
+lockfiles lack some data, including:
 
 - 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][12].
+- The lockfile doesn't contain entry point fields (`main`, `module`, `exports`)
+  needed to resolve what a dependency actually exposes.
+- The lockfile doesn't contain `bin` entries to determine installed binaries.
 
 ## Module Resolution
 
@@ -273,13 +277,10 @@ seem to meet all requirements to be usable on its own by Knip:
 - Don't resolve to type definition paths like `module.d.ts` but source code at
   `module.js`
 
-A few strategies have been tried and tweaked, and Knip currently uses a
-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][11] and resolving references to files in other workspaces.
+A few strategies have been tried and tweaked, and Knip currently uses
+[oxc-resolver][13] with customizations for extension aliases, path aliases and
+TypeScript-style resolution. This covers module resolution across all
+workspaces, [script parsing][11] and references to files in other workspaces.
 
 ### How does Knip handle non-standard import syntax?
 
@@ -288,8 +289,8 @@ webpack loaders or Vite asset imports. Knip strips off the prefixes and suffixes
 in import specifiers like this:
 
 ```ts title="component.ts"
-import Icon from './icon.svg?raw';
-import Styles from '-!style-loader!css-loader?modules!./styles.css';
+import Icon from "./icon.svg?raw";
+import Styles from "-!style-loader!css-loader?modules!./styles.css";
 ```
 
 In this example, the `style-loader` and `css-loader` dependencies should be
@@ -307,10 +308,8 @@ perspective), it can be added as a workspace to the Knip configuration.
 Projects - in the context of TypeScript - are directories with a `tsconfig.json`
 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][14]. That's why debug output contains messages like
-"Installed 2 programs for 29 workspaces".
+Knip analyzes all workspaces using a single module graph with a shared module
+resolver.
 
 ### Why doesn't Knip match my TypeScript project structure?
 
@@ -332,32 +331,22 @@ Note that any directory with a `package.json` not listed in the root
 `package.json#workspaces` can be added to the Knip configuration manually to
 have it handled as a separate workspace.
 
-### Why doesn't Knip analyze workspaces in isolation by default?
-
-Knip creates TypeScript programs to create a module graph and traverse file
-ASTs. In a monorepo, it would make a lot of sense to create one program per
-workspace. However, this slows down the whole process considerably. That's why
-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][14].
-
 ### Why doesn't Knip just use `ts.findReferences`?
 
 TypeScript has a very good "Find references" feature, that you might be using in
-your IDE as well. Yet at scale this becomes too slow. That's why Knip builds up
-its own module graph to look up export usages. Additional benefits for this
-comprehensive graph include:
+your IDE as well. There are a few reasons Knip doesn't use it:
 
-- serializable and cacheable
-- enables more features
-- usable for other tools to build upon as well
+- It requires the full TypeScript language service, which is heavy to
+  initialize.
+- It must be called per symbol. A project with thousands of exports would need
+  thousands of calls, each scanning potentially all files. Knip parses each file
+  once and resolves all export usages from the resulting graph.
+- It operates within a single TypeScript program. Monorepos with multiple
+  `tsconfig.json` files would need separate language service instances.
+- It cannot see into non-standard files like `.vue`, `.svelte` and `.astro`.
 
-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][8] will trigger the same.
+Knip's module graph is also serializable and cacheable, and usable for other
+tools to build upon.
 
 ### Why can't I use path aliases to reference other workspaces?
 
@@ -369,19 +358,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][15].
+Also see the example in [TypeScript path aliases in monorepos][14].
 
 ### 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][16] is used to provide an alternative location
+The [`--tsConfig [file]` option][15] 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][17] can be set per
+On the other hand, the [`config` option of the plugin][16] can be set per
 workspace. The TypeScript plugin extracts referenced external dependencies such
 as those in `extends`, `compilerOptions.types` and JSX settings:
 
@@ -405,7 +394,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][18] to the Knip configuration. The latter can be done per
+  manually add [paths][17] to the Knip configuration. The latter can be done per
   workspace.
 
 ## Compilers
@@ -418,17 +407,16 @@ than JavaScript and TypeScript modules should be included as well. For instance,
 dependencies.
 
 Knip includes basic "compilers" for a few common file types (Astro, MDX, Svelte,
-Vue). Knip does not include actual compilers for reasons of potential
-incompatibility with the existing compiler, and dependency size. Knip allows to
-override them with the compilers in your project, and add additional ones for
-other file types.
+Vue). These are lightweight regex-based extractors, not actual compilers. You
+can override the built-in compilers with your project's actual compiler, and add
+additional ones for other file types.
 
 ### Why are the exports of my `.vue` files not used?
 
 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][19].
+project. Also see the answer to the previous question and [Compilers][18].
 
 ## Miscellaneous
 
@@ -464,12 +452,10 @@ Examples of features that have been requested include:
 - Analyze workspaces in parallel
 - Support Deno
 - Improve internal code structures and accessibility to support contributions
-- Replace dependencies for better performance and correctness, such as for shell
-  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][20] currently don't cover - this can change though!
+[sponsorships][19] currently don't cover - this can change though!
 
 [1]: ../reference/integrations.md#mcp-server
 [2]: ../reference/integrations.md#vs-code-extension
@@ -484,10 +470,9 @@ require more development efforts and maintenance. Time is limited and
 [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
+[14]: ../guides/handling-issues.mdx#typescript-path-aliases-in-monorepos
+[15]: ../reference/cli.md#--tsconfig-file
+[16]: ../explanations/plugins.md#configuration-files
+[17]: ../reference/configuration.md#paths
+[18]: ../features/compilers.md
+[19]: /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      | 🔧    | `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`               |
+| 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 namespace members    | Unable to find a reference to this namespace member        | 🔧    | `namespaceMembers` |
+| Duplicate exports                    | This is exported more than once                            |       | `duplicates`       |
 
 ## Legend
 

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

@@ -55,9 +55,9 @@ them to ensure no unintended modifications were made.
 
 ## Can Knip handle large codebases?
 
-Absolutely. Knip supports [monorepos with workspaces][5] and utilizes [workspace
-sharing][6] to efficiently analyze large monorepos. This makes it easier and
-more fun to manage and optimize large multi-package projects.
+Absolutely. Knip supports [monorepos with workspaces][5] to efficiently analyze
+large monorepos. This makes it easier and more fun to manage and optimize large
+multi-package projects.
 
 ## Does Knip work with my favorite editor or IDE?
 
@@ -70,18 +70,17 @@ to easily navigate around.
 
 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
+are actually unused. By building [a comprehensive module graph][6], Knip
 identifies exports that are not imported or used anywhere in the codebase. This
 allows Knip to catch unused exports and dead code that ESLint and other linters
 would miss.
 
-Also see [Why isn't Knip an ESLint plugin?][8]
+Also see [Why isn't Knip an ESLint plugin?][7]
 
 [1]: ../overview/getting-started.mdx
 [2]: ../reference/faq.md#what-does-knip-look-for-in-source-files
 [3]: ../guides/working-with-commonjs.md
 [4]: ../features/auto-fix.mdx
 [5]: ../features/monorepos-and-workspaces.md
-[6]: ../guides/performance.md#workspace-sharing
-[7]: ../reference/faq.md#whats-in-the-graphs
-[8]: ../reference/faq.md#why-isnt-knip-an-eslint-plugin
+[6]: ../reference/faq.md#whats-in-the-graphs
+[7]: ../reference/faq.md#why-isnt-knip-an-eslint-plugin