@knip/mcp 0.0.21 → 0.0.23

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

@@ -23,72 +23,19 @@ exclude files from the analysis.
 Read [configuring project files][1] for details and examples. Improving
 configuration may have a significant impact on performance.
 
-## Workspace sharing
-
-Knip shares files from separate workspaces if the configuration in
-`tsconfig.json` allows this. This aims to reduce memory consumption and run
-duration. Relevant compiler options include `baseUrl`, `paths` and
-`moduleResolution`.
-
-With the `--debug` flag you can see how many programs Knip uses. Look for
-messages like this:
-
-```sh
-...
-[*] Installed 2 programs for 29 workspaces
-...
-[*] Analyzing used resolved files [P1/1] (123)
-...
-[*] Analyzing used resolved files [P1/2] (8)
-...
-[*] Analyzing used resolved files [P2/1] (41)
-...
-```
-
-The first number in `P1/1` is the number of the programs, the second number
-indicates additional entry files were found so it does another round of analysis
-on those files.
-
-Use [--isolate-workspaces][2] to disable this behavior. This is usually not
-necessary, but more of an escape hatch in cases with memory usage issues or
-incompatible `compilerOptions` across workspaces. Workspaces are analyzed
-sequentially to spread out memory usage more evenly, which may prevent crashes
-on large monorepos.
-
-## Language Service
-
-Knip does not install the TypeScript Language Service (LS) by default. This is
-expensive, as TypeScript needs to set up symbols and caching for the rather slow
-`findReferences` function. Even more so for multiple projects/workspaces.
-
-There are two cases that enforce Knip to install the LS:
-
-### 1. Class members
-
-The `findReferences` function is used to find unused members of imported classes
-(i.e. when the issue type `classMembers` is included).
-
-### 2. Include external type definitions
-
-When [`--include-libs`][3] is enabled, Knip loads type definitions of external
-dependencies. This will also install the LS to access its `findReferences`
-function. It acts as an extra line of defense: only exports that Knip thinks
-aren't referenced (during the default/fast procedure), will now receive a second
-opinion from `findReferences`.
-
 ## Metrics
 
-Use [the `--performance` flag][4] to see how many times potentially expensive
+Use [the `--performance` flag][2] to see how many times potentially expensive
 functions (e.g. `findReferences`) are invoked and how much time is spent in
 those functions. Example usage:
 
 ```sh
-knip --include classMembers --performance
+knip --performance
 ```
 
 ## ignoreExportsUsedInFile
 
-The [ignoreExportsUsedInFile][5] option slows down the process slightly.
+The [ignoreExportsUsedInFile][3] option slows down the process slightly.
 Typically, anywhere between 0.25% and 10% of total running time. To find out:
 
 ```sh
@@ -98,11 +45,9 @@ knip --performance-fn hasRefsInFile
 ## A last resort
 
 In case Knip is unbearably slow (or even crashes), you could resort to [lint
-individual workspaces][6].
+individual workspaces][4].
 
 [1]: ./configuring-project-files.md
-[2]: ../reference/cli.md#--isolate-workspaces
-[3]: ../guides/handling-issues.mdx#external-libraries
-[4]: ../reference/cli.md#--performance
-[5]: ../reference/configuration.md#ignoreexportsusedinfile
-[6]: ../features/monorepos-and-workspaces.md#filter-workspaces
+[2]: ../reference/cli.md#--performance
+[3]: ../reference/configuration.md#ignoreexportsusedinfile
+[4]: ../features/monorepos-and-workspaces.md#filter-workspaces

package/src/docs/docs/guides/using-knip-in-ci.md

@@ -23,8 +23,8 @@ jobs:
     runs-on: ubuntu-latest
     name: Ubuntu/Node v24
     steps:
-      - uses: actions/checkout@v4
-      - uses: actions/setup-node@v4
+      - uses: actions/checkout@v6
+      - uses: actions/setup-node@v6
         with:
           node-version: 24
       - name: Install dependencies

package/src/docs/docs/index.mdx

@@ -3,7 +3,7 @@ title: Declutter your JavaScript & TypeScript projects
 description: Project linter to find unused dependencies, exports and files
 template: splash
 hero:
-  title: Knip
+  title: Knip v6
   tagline: Declutter your JavaScript & TypeScript projects
   image:
     file: ../../assets/logo.svg
@@ -12,8 +12,8 @@ hero:
       link: ./overview/getting-started
       icon: right-arrow
       variant: primary
-    - text: 'NEW: Knip for Editors & Agents'
-      link: /blog/for-editors-and-agents
+    - text: 'NEW: Knip v6'
+      link: /blog/knip-v6
       icon: rocket
       variant: secondary
     - text: View on GitHub

package/src/docs/docs/overview/configuration.md

@@ -46,7 +46,7 @@ folder:
 
 ```json title="knip.json"
 {
-  "$schema": "https://unpkg.com/knip@5/schema.json",
+  "$schema": "https://unpkg.com/knip@6/schema.json",
   "entry": ["src/index.ts", "scripts/{build,create}.js"],
   "project": ["src/**/*.ts", "scripts/**/*.js"]
 }

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/integrations.md

@@ -95,8 +95,7 @@ dependencies.
 [7]: #vs-code-extension-screenshots
 [8]: https://plugins.jetbrains.com/plugin/29765-knip
 [9]: https://www.npmjs.com/package/@knip/mcp
-[10]:
-  https://github.com/webpro-nl/knip/blob/main/packages/language-server/README.md
+[10]: https://github.com/webpro-nl/knip/blob/main/packages/language-server/README.md
 [11]: /screenshots/editors-and-agents/diagnostics.webp
 [12]: /screenshots/editors-and-agents/imports-exports.webp
 [13]: /screenshots/editors-and-agents/circular-dependency.webp