@knip/mcp 0.0.18 → 0.0.20

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

@@ -6,22 +6,24 @@ sidebar:
 
 import { Tabs, TabItem } from '@astrojs/starlight/components';
 
-A long report can be frustrating. The list may contain false positives, but also
-tons of useful information. To get the most value out of Knip, it may require
-some initial configuration.
+Issues reported by Knip may contain false positives, but also tons of useful
+information. Getting the most out of Knip may require some configuration.
 
-This guide helps you deal with false positives to find solutions and create the
-perfect report, with minimal configuration that will keep your project tidy.
-
-If you start out using Knip in a large project and have a long report, it makes
-sense to go over the issue types one by one. For instance, reducing the number
-of unused files will also reduce the number of unused dependencies.
+Go over the issue types one by one. For instance, reducing the number of unused
+files will also reduce the number of unused dependencies.
 
 1. [Unused files][1]
 2. [Unused dependencies][2]
 3. [Unresolved imports][3]
 4. [Unused exports][4]
 
+:::tip
+
+Try the [Knip Editor Extension][5]! Let your coding agent use the built-in
+MCP Server and create a custom `knip.json` for you.
+
+:::
+
 ## Unused files
 
 Getting the list of unused files right trickles down into the other issue types
@@ -32,22 +34,29 @@ of `project` files, but not in the set of files resolved from the `entry` files:
 unused files = project files - (entry files + resolved files)
 ```
 
-Let's go over common causes for unused files:
+:::tip
+
+Addressing reported [Configuration Hints][6] first might help significantly,
+especially when handling unused files.
+
+:::
 
-- [Missing generated files][5]
-- [Dynamic import specifiers][6]
-- [Unsupported arguments in scripts][7]
-- [Unsupported file formats][8]
-- [Missing plugin][9]
-- [Incomplete plugin][10]
-- [TypeScript path aliases in monorepos][11]
-- [Relative paths across workspaces][12]
-- [Integrated monorepos][13]
-- [Auto-mocking or auto-imports][14]
+Common causes for unused files include:
+
+- [Missing generated files][7]
+- [Dynamic import specifiers][8]
+- [Unsupported arguments in scripts][9]
+- [Unsupported file formats][10]
+- [Missing plugin][11]
+- [Incomplete plugin][12]
+- [TypeScript path aliases in monorepos][13]
+- [Relative paths across workspaces][14]
+- [Integrated monorepos][15]
+- [Auto-mocking or auto-imports][16]
 
 In most cases you can add `entry` patterns manually.
 
-Use `--files` to [filter the report][15] and focus only on unused files:
+Use `--files` to [filter the report][17] and focus only on unused files:
 
 ```sh
 knip --files
@@ -60,15 +69,15 @@ exports.
 :::caution
 
 Don't add unused files to the `ignore` option before reading [configuring
-project files][16]. Learn why and when to use `entry`, `project`, production
-mode and `ignore` patterns for better results and performance.
+project files][18]. Learn why and when to use `entry`, `project`, production
+mode and `ignore*` patterns for better results and performance.
 
 :::
 
 ### Missing generated files
 
 For certain features, Knip needs to run after relevant files are generated. For
-instance, [source mapping][17] in a monorepo may require files to be built into
+instance, [source mapping][19] in a monorepo may require files to be built into
 `dist` folders first. And generated files in the `src` directory may import
 other files. For instance, the `src/routeTree.gen.ts` file generated by
 `@tanstack/router` must exist so Knip can find the imported route files.
@@ -106,7 +115,7 @@ Some tooling command arguments aren't recognized:
 **Solution**: add `production.ts` to `entry` patterns.
 
 This works the same for any script, also those in GitHub Actions workflows or
-Git hooks. See [script parser][18] for more details about Knip's script parser.
+Git hooks. See [script parser][20] for more details about Knip's script parser.
 
 ### Unsupported file formats
 
@@ -123,9 +132,9 @@ Entry files referenced in HTML files (e.g. `<script src="production.js">`).
 **Solution**: add `production.js` to `entry` patterns. Or add an `.html`
 compiler to extract and resolve the value of `<script src>` elements.
 
-Knip has support for some popular framework formats through [compilers][19], and
-additional compilers can be added for for any file type. The recommended
-solution is usually to add the file as shown in each example as an `entry` file.
+Knip has support for some popular framework formats through [compilers][21], and
+additional compilers can be added for any file type. The recommended solution is
+usually to add the file as shown in each example as an `entry` file.
 
 ### Missing plugin
 
@@ -139,16 +148,16 @@ examples:
 - A framework automatically imports all files matching `src/models/*.ts` → those
   files are reported as unused.
 
-**Solution**: [create a new plugin][20] for the tool or framework that's not [in
-the list][21] yet. Or work around it and add `entry` patterns and maybe ignore a
-dependency or two (using [`ignoreDependencies`][22]).
+**Solution**: [create a new plugin][22] for the tool or framework that's not [in
+the list][23] yet. Or work around it and add `entry` patterns and maybe ignore a
+dependency or two (using [`ignoreDependencies`][24]).
 
 ### Incomplete plugin
 
 Files may be reported as unused if existing plugins do not include that entry
-file pattern yet. See the [plugins section of entry files][23] for more details.
+file pattern yet. See the [plugins section of entry files][25] for more details.
 
-**Solution**: [override plugin configuration][24] to customize default patterns
+**Solution**: [override plugin configuration][26] to customize default patterns
 for existing plugins. Or even better: send a pull request to improve the plugin.
 
 ### TypeScript path aliases in monorepos
@@ -184,7 +193,7 @@ Knip, it's better to be explicit and list other workspaces as dependencies in
 An additional benefit is that Knip will report unused and unlisted dependencies
 from now on.
 
-Also see [FAQ: Why can't I use path aliases to reference other workspaces?][25]
+Also see [FAQ: Why can't I use path aliases to reference other workspaces?][27]
 
 ### Relative paths across workspaces
 
@@ -207,7 +216,7 @@ import { something } from '@org/common';
 An additional benefit is that Knip will report unused and unlisted dependencies
 from now on.
 
-Also see [TypeScript path aliases in monorepos][11].
+Also see [TypeScript path aliases in monorepos][13].
 
 ### Integrated monorepos
 
@@ -215,7 +224,7 @@ Multiple instances of configuration files like `.eslintrc` and
 `jest.config.json` across the repository may be reported as unused when working
 in a (mono)repo with a single `package.json`.
 
-**Solution**: see [integrated monorepos][26] for more details and how to
+**Solution**: see [integrated monorepos][28] for more details and how to
 configure plugins to target those configuration files.
 
 ### Auto-mocking or auto-imports
@@ -250,11 +259,12 @@ unused dependencies.
 
 The most common causes for unused dependencies include:
 
-- [Missing or incomplete plugins][27]
-- [Unrecognized references][28]
-- [Type Definition Packages][29]
+- [Missing or incomplete plugins][29]
+- [Unrecognized references][30]
+- [Type Definition Packages][31]
+- [Dependencies named after Node.js builtins][32]
 
-Use `--dependencies` to [filter the report][15] and focus only on issues related
+Use `--dependencies` to [filter the report][17] and focus only on issues related
 to dependencies:
 
 ```sh
@@ -264,8 +274,8 @@ knip --dependencies
 :::caution[Monorepo]
 
 In a monorepo, a dependency is unused in the root workspace's `package.json` if
-it's also listed in an descendent workspace, and referenced only in the
-descendent workspace.
+it's also listed in a descendant workspace, and referenced only in the
+descendant workspace.
 
 :::
 
@@ -285,10 +295,57 @@ Sometimes a reference to a dependency is unrecognizable or unreachable to Knip,
 so it's a false positive and incorrectly reported as unused.
 
 **Solution**: add a new plugin or improve an existing one. If you don't feel
-like a plugin could solve it, a last resort is to use [ignoreDependencies][22].
+like a plugin could solve it, a last resort is to use [ignoreDependencies][24].
 
 If a binary (or "executable") is referenced you'll want to use `ignoreBinaries`
-instead. See [unlisted binaries][30].
+instead. See [unlisted binaries][33].
+
+### Dependencies named after Node.js builtins
+
+Some packages have the same name as a Node.js builtin (for instance `buffer` or
+`process`).
+
+**Solution**: if Knip reports such a dependency as unused, add it to
+[ignoreDependencies][24].
+
+### Conditional or dynamic dependencies
+
+Dependencies added conditionally in configuration files may not be detected by
+Knip. This happens because Knip loads and executes config files, and conditional
+logic may evaluate differently during analysis.
+
+For example, this Playwright configuration conditionally adds a reporter:
+
+```ts title="playwright.config.ts"
+import { defineConfig } from '@playwright/test';
+
+const reporters: any[] = [['list']];
+if (process.env.REPORT_PORTAL_ENABLED) {
+  reporters.push(['@reportportal/agent-js-playwright', config]);
+}
+
+export default defineConfig({
+  reporter: reporters,
+});
+```
+
+If `process.env.REPORT_PORTAL_ENABLED` evaluates to `false` when Knip runs, the
+`@reportportal/agent-js-playwright` dependency won't be detected and may be
+reported as unused.
+
+This limitation exists because Knip executes configuration files to parse their
+exported value. While Knip can parse configuration files statically using AST
+(Abstract Syntax Tree) analysis, this approach becomes complex very quickly and
+most of the time it is easier to use the [`ignoreDependencies`][24]
+configuration option for conditionals.
+
+```json title="knip.json"
+{
+  "ignoreDependencies": ["@reportportal/agent-js-playwright"]
+}
+```
+
+This pattern can be applied to any plugin that loads configuration files.
 
 ### Type Definition Packages
 
@@ -317,7 +374,7 @@ In strict production mode, even when re-exported and part of the package's
 public API, Knip does not try to figure out what exactly are "production types"
 and expects those in `devDependencies`.
 
-**Solution**: list exceptions in [ignoreDependencies][22].
+**Solution**: list exceptions in [ignoreDependencies][24].
 
 ### Unlisted dependencies
 
@@ -349,7 +406,7 @@ reported as an unlisted binary as there is no package that contains it.
 
 Binaries that are installed on the OS already and thus likely not meant to be
 installed from npm are not reported as unlisted (details: [list of ignored
-binaries in source][31]).
+binaries in source][34]).
 
 #### Missing binaries
 
@@ -359,7 +416,7 @@ either the way your package manager installs dependencies and binaries, or by
 not running Knip from the root of the repository.
 
 **Solution**: run Knip from the project root. If needed, [lint workspaces
-individually][32].
+individually][35].
 
 Sometimes binaries and how they're reported can be a bit confusing. See this
 example:
@@ -377,9 +434,9 @@ example:
 ```
 
 This example works fine without anything reported, as the `@commitlint/cli`
-package includes the `commitlint` binary. However, some script may contain
-`npx commitlint` and here Knip assumes `commitlint` is the name of the package.
-This technically works, as `commitlint` is a transitive dependency of
+package includes the `commitlint` binary. However, some script may contain `npx
+commitlint` and here Knip assumes `commitlint` is the name of the package. This
+technically works, as `commitlint` is a transitive dependency of
 `@commitlint/cli`.
 
 **Solution**: use `npx @commitlint/cli`
@@ -395,10 +452,10 @@ or consider the binary and package(s) referenced, respectively.
 Knip may ignore or be unable to resolve an import specifier or dependency
 references. The most common causes for unresolved imports:
 
-- [Template strings][33]
-- [Extensionless imports][28]
-- [Unrecognized path aliases][34]
-- [External aliased imports][35]
+- [Template strings][36]
+- [Extensionless imports][30]
+- [Unrecognized path aliases][37]
+- [External aliased imports][38]
 
 ### Template strings
 
@@ -430,24 +487,24 @@ The first import is resolved properly, because `.vue` is a known extension if
 the Vue plugin is enabled. The second import might not be resolved, because
 `.svg` is not a known extension.
 
-The recommendation is to always add the extension when importing such files,
-similar to how standard ES Modules specifies file extensions are necessary.
+**Solution**: include the extension. Hosts supporting ES Modules (e.g. Node.js,
+browsers) require a file extension for import specifiers.
 
 ### Unrecognized path aliases
 
-Knip considers TS config path aliases and [paths configured in knip.json][36],
+Knip considers TS config path aliases and [paths configured in knip.json][39],
 but not those in e.g. Webpack or Vite configurations.
 
-**Solution**: configure [paths][36] or try relative imports. Otherwise, use
-[`ignoreUnresolved`][37] as a last resort.
+**Solution**: configure [paths][39] or try relative imports. Otherwise, use
+[`ignoreUnresolved`][40] as a last resort.
 
 ### External aliased imports
 
 External libraries may use aliased imports that aren't resolved by Knip.
 
-For instance, [unplugin-icons][10] does this to import icons from icon sets as
+For instance, [unplugin-icons][41] does this to import icons from icon sets as
 components. Such imports are reported as unused. Use the [`paths` configuration
-option][13] to tell Knip where to find the icon types:
+option][39] to tell Knip where to find the icon types:
 
 ```json title="knip.json"
 {
@@ -458,9 +515,9 @@ option][13] to tell Knip where to find the icon types:
 ```
 
 Where `[framework]` is the name of the framework you're using (see [available
-types][38]).
+types][42]).
 
-**Solution**: try [--include-libs][39] or configure [paths][36].
+**Solution**: try [--include-libs][43] or configure [paths][39].
 
 ## Unused exports
 
@@ -468,17 +525,17 @@ By default, Knip does not report unused exports of `entry` files.
 
 The most common causes for unused exports include:
 
-- [Namespace enumerations][40]
-- [External libraries][39]
+- [Namespace enumerations][44]
+- [External libraries][45]
 
-Use the `--exports` flag to [filter][15] and focus only on issues related to
+Use the `--exports` flag to [filter][17] and focus only on issues related to
 exports:
 
 ```sh
 knip --exports
 ```
 
-Use [includeEntryExports][41] to report unused exports of entry files as well.
+Use [includeEntryExports][46] to report unused exports of entry files as well.
 This can be set per workspace.
 
 ### Namespace enumerations
@@ -490,7 +547,7 @@ are then **not** reported.
 **Solution**: if all exports on imported namespaces should be considered
 individually, include the `nsExports` issue type to disable the heuristic.
 
-See [namespace imports][42] to see all related patterns.
+See [namespace imports][47] to see all related patterns.
 
 ### External libraries
 
@@ -533,16 +590,17 @@ knip --include-libs
 ```
 
 This comes at a performance and memory penalty, but should give better results
-if you need it. This flag is implied when [classMembers][44] are included (that
+if you need it. This flag is implied when [classMembers][48] are included (that
 feature comes with roughly the same performance penalty).
 
 ### Exclude exports from the report
 
 To exclude false positives from the report, there are a few options:
 
-- [Ignore exports used in file][45] for exports used internally.
-- Individual exports can be [tagged using JSDoc syntax][46].
+- [Ignore exports used in file][49] for exports used internally.
+- Individual exports can be [tagged using JSDoc syntax][50].
 - Have the export in an entry file:
+
   - Add the file to the `entry` file patterns array in the configuration.
   - Move the export(s) to an entry file.
   - Add the file to the `exports` field of `package.json`
@@ -551,11 +609,11 @@ To exclude false positives from the report, there are a few options:
 ### Missing unused exports?
 
 Did you expect certain exports in the report, but are they missing? They might
-be exported from an entry file. In that case, use [--include-entry-exports][41]
+be exported from an entry file. In that case, use [--include-entry-exports][46]
 to make Knip also report unused exports in entry files.
 
 The exports of non-standard extensions like `.astro`, `.mdx`, `.vue` or
-`.svelte` are not available by default. See [compilers][19] for more details on
+`.svelte` are not available by default. See [compilers][21] for more details on
 how to include them.
 
 ### Class members
@@ -570,10 +628,10 @@ knip --include classMembers
 This option is also available in the Knip configuration file. Note that this
 feature comes at a cost: linting will take more time and more memory.
 
-Individual class members can be [tagged using JSDoc syntax][46].
+Individual class members can be [tagged using JSDoc syntax][50].
 
 Classes exported from entry files are ignored, and so are their members. Use
-[--include-entry-exports][41] to make Knip also report members of unused exports
+[--include-entry-exports][46] to make Knip also report members of unused exports
 in entry files.
 
 ### Enum members
@@ -585,62 +643,66 @@ Reporting such members can be disabled:
 knip --exclude enumMembers
 ```
 
-Individual enum members can be [tagged using JSDoc syntax][46].
+Individual enum members can be [tagged using JSDoc syntax][50].
 
 Enums exported from entry files are ignored, and so are their members. Use
-[--include-entry-exports][41] to make Knip also report members of unused exports
+[--include-entry-exports][46] to make Knip also report members of unused exports
 in entry files.
 
 ## Feedback or false positives?
 
 If you believe Knip incorrectly reports something as unused (i.e. there's a
-false positive), feel free to create a [minimal reproduction][47] and open an
+false positive), feel free to create a [minimal reproduction][51] and open an
 issue on GitHub. It'll make Knip better for everyone!
 
 [1]: #unused-files
 [2]: #unused-dependencies
 [3]: #unresolved-imports
 [4]: #unused-exports
-[5]: #missing-generated-files
-[6]: #dynamic-import-specifiers
-[7]: #unsupported-arguments-in-scripts
-[8]: #unsupported-file-formats
-[9]: #missing-plugin
-[10]: #incomplete-plugin
-[11]: #typescript-path-aliases-in-monorepos
-[12]: #relative-paths-across-workspaces
-[13]: #integrated-monorepos
-[14]: #auto-mocking-or-auto-imports
-[15]: ../features/rules-and-filters.md#filters
-[16]: ./configuring-project-files.md
-[17]: ../features/source-mapping.md
-[18]: ../features/script-parser.md
-[19]: ../features/compilers.md
-[20]: ./writing-a-plugin.md
-[21]: ../reference/plugins.md
-[22]: ../reference/configuration.md#ignoredependencies
-[23]: ../explanations/plugins.md#entry-files
-[24]: ../explanations/entry-files.md#plugins
-[25]: ../reference/faq.md#why-cant-i-use-path-aliases-to-reference-other-workspaces
-[26]: ../features/integrated-monorepos.md
-[27]: #missing-or-incomplete-plugin
-[28]: #unrecognized-reference
-[29]: #type-definition-packages
-[30]: #unlisted-binaries
-[31]: https://github.com/webpro-nl/knip/blob/b70958a58ea255ee7a7831e404786da807ca93d7/packages/knip/src/constants.ts#L37-L139
-[32]: ../features/monorepos-and-workspaces.md#lint-a-single-workspace
-[33]: #template-strings
-[34]: #unrecognized-path-aliases
-[35]: #external-aliased-imports
-[36]: ../reference/configuration.md#paths
-[37]: ../reference/configuration.md#ignoreunresolved
-[38]: #build-artifacts-and-ignored-files
-[39]: #external-libraries
-[40]: #namespace-enumerations
-[41]: ../reference/configuration.md#includeentryexports
-[42]: ../guides/namespace-imports.md
-[43]: ../reference/cli#--include-libs
-[44]: #class-members
-[45]: ../reference/configuration.md#ignoreexportsusedinfile
-[46]: ../reference/jsdoc-tsdoc-tags.md
-[47]: ../guides/issue-reproduction
+[5]: ../reference/integrations.md
+[6]: ../reference/configuration-hints.md
+[7]: #missing-generated-files
+[8]: #dynamic-import-specifiers
+[9]: #unsupported-arguments-in-scripts
+[10]: #unsupported-file-formats
+[11]: #missing-plugin
+[12]: #incomplete-plugin
+[13]: #typescript-path-aliases-in-monorepos
+[14]: #relative-paths-across-workspaces
+[15]: #integrated-monorepos
+[16]: #auto-mocking-or-auto-imports
+[17]: ../features/rules-and-filters.md#filters
+[18]: ./configuring-project-files.md
+[19]: ../features/source-mapping.md
+[20]: ../features/script-parser.md
+[21]: ../features/compilers.md
+[22]: ../writing-a-plugin/index.md
+[23]: ../reference/plugins.md
+[24]: ../reference/configuration.md#ignoredependencies
+[25]: ../explanations/plugins.md#entry-files
+[26]: ../explanations/entry-files.md#plugins
+[27]: ../reference/faq.md#why-cant-i-use-path-aliases-to-reference-other-workspaces
+[28]: ../features/integrated-monorepos.md
+[29]: #missing-or-incomplete-plugin
+[30]: #unrecognized-reference
+[31]: #type-definition-packages
+[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#filter-workspaces
+[36]: #template-strings
+[37]: #unrecognized-path-aliases
+[38]: #external-aliased-imports
+[39]: ../reference/configuration.md#paths
+[40]: ../reference/configuration.md#ignoreunresolved
+[41]: https://www.npmjs.com/package/unplugin-icons
+[42]: https://github.com/unplugin/unplugin-icons/tree/main/types
+[43]: ../reference/cli.md#--include-libs
+[44]: #namespace-enumerations
+[45]: #external-libraries
+[46]: ../reference/configuration.md#includeentryexports
+[47]: ../guides/namespace-imports.md
+[48]: #class-members
+[49]: ../reference/configuration.md#ignoreexportsusedinfile
+[50]: ../reference/jsdoc-tsdoc-tags.md
+[51]: ../guides/issue-reproduction.md

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

@@ -19,6 +19,8 @@ influence the issue at hand, such as:
 - Dependent or depending workspaces in a monorepo
 - Knip configuration in `knip.json`
 
+## Keep it minimal
+
 Create the minimum of source code and configuration with a few files to
 reproduce and demonstrate the issue. Having this as a basis has many benefits:
 
@@ -30,6 +32,12 @@ reproduce and demonstrate the issue. Having this as a basis has many benefits:
 Providing this with an issue description will help us help you and improve the
 chances the issue can be looked into efficiently and in a timely manner.
 
+Useful **complements** to a minimal reproduction might include:
+
+- Screenshots, videos, code snippets or log output
+- Links to an existing project repository
+- Applications scaffolded by tools like Angular or Svelte CLI
+
 ## Before opening an issue
 
 Before opening an issue, please make sure you:
@@ -42,6 +50,10 @@ Before opening an issue, please make sure you:
 Please file only a single issue at a time, so each of them can be labeled and
 tracked separately.
 
+There is no need to open an issue if you're going to submit a pull request to
+close it right away anyway. In that case it's preferred to keep things central
+in either an issue or pull request.
+
 ## Templates
 
 A convenient way to create a minimal reproduction is by starting with one of
@@ -61,21 +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].
-
-The goal is to have an easy and common understanding and reproduction. A link to
-your existing project repository will likely not be considered "minimal". Issues
-containing just a screenshot, or snippets of output or source code don't provide
-the full picture and aren't complete nor actionable.
+- A pull request with a new [test][9] and/or [fixture folder][10].
 
-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].
+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][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
@@ -89,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

@@ -59,9 +59,9 @@ on large monorepos.
 
 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.
+`findReferences` function. Even more so for multiple projects/workspaces.
 
-There are two cases that enforce Knip to install the LS.
+There are two cases that enforce Knip to install the LS:
 
 ### 1. Class members
 
@@ -70,10 +70,11 @@ The `findReferences` function is used to find unused members of imported classes
 
 ### 2. Include external type definitions
 
-When [`--include-libs`][3] is enabled, Knip enables loading 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 weren't referenced to during default procedure go through this.
+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
 
@@ -85,13 +86,23 @@ those functions. Example usage:
 knip --include classMembers --performance
 ```
 
+## ignoreExportsUsedInFile
+
+The [ignoreExportsUsedInFile][5] option slows down the process slightly.
+Typically, anywhere between 0.25% and 10% of total running time. To find out:
+
+```sh
+knip --performance-fn hasRefsInFile
+```
+
 ## A last resort
 
 In case Knip is unbearably slow (or even crashes), you could resort to [lint
-individual workspaces][5].
+individual workspaces][6].
 
 [1]: ./configuring-project-files.md
 [2]: ../reference/cli.md#--isolate-workspaces
 [3]: ../guides/handling-issues.mdx#external-libraries
 [4]: ../reference/cli.md#--performance
-[5]: ../features/monorepos-and-workspaces.md#lint-a-single-workspace
+[5]: ../reference/configuration.md#ignoreexportsusedinfile
+[6]: ../features/monorepos-and-workspaces.md#filter-workspaces