@knip/mcp 0.0.18 → 0.0.20

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

@@ -1,86 +0,0 @@
----
-title: Unused dependencies
-description: Find and remove unused dependencies with Knip
-prev: false
-next: false
----
-
-One of Knip's core features is finding unused dependencies in your JavaScript
-and TypeScript projects. And it comes with many more features to remove clutter
-and keep your projects in great shape.
-
-## Why are unused dependencies a problem?
-
-Having unused dependencies in your `package.json` is an issue for various
-reasons:
-
-- They might end up in the final production bundle, increasing size and load
-  times for end users.
-- They waste space in `node_modules` and add to the installation time of the
-  project.
-- They slow down tooling such as linters and bundlers that analyze dependencies.
-- They are confusing and noisy in `package.json`.
-- They cause unnecessary extra work when managing and upgrading dependencies.
-- They can cause version conflicts with other dependencies in use.
-- They can cause false security alerts.
-- They might have restrictive licenses and make your project subject to theirs.
-- They usually come with transitive dependencies that have the same issues.
-
-## How do I find unused dependencies?
-
-Use Knip to find and remove unused dependencies. It also finds dependencies that
-are missing in `package.json` and has a lot more features to keep your
-JavaScript and TypeScript projects tidy.
-
-It's easy to [get started][1] and make package management easier and more fun!
-
-<div style="display: flex; justify-content: center; margin: 4rem auto;">
-  <img src="/logo.svg" alt="Logo of Knip, to find unused dependencies, exports and files" class="logo-border" />
-</div>
-
-## How does Knip identify unused dependencies?
-
-Knip works by analyzing `package.json` files, source code and configuration
-files for other tooling in the project to find unused and missing dependencies.
-Knip has many heuristics, [plugins][2] and [compilers][3] to fully automate the
-process.
-
-## Can Knip remove unused dependencies?
-
-Yes, Knip can automatically remove unused dependencies installed by a package
-manager like npm or pnpm for you. Add the `--fix` argument to [auto-fix][4] and
-remove unused dependencies from `package.json`.
-
-## Can Knip detect missing dependencies?
-
-Yes, Knip detects missing dependencies. It analyzes `package.json` files, and
-reports packages that are missing. They should be added to `package.json` to
-avoid relying on transitive dependencies that can cause version mismatches and
-breakage.
-
-## Does Knip work with monorepos?
-
-Yes, Knip has first-class support for [monorepos and workspaces][5]. It analyzes
-all workspaces in the project and understands their relationship.
-
-For instance, if a dependency is listed in the root `package.json` it does not
-need to be listed in other workspaces. Except if you enable `--strict` checking.
-
-## Does Knip separate dependencies and devDependencies?
-
-Yes, Knip understands the difference between dependencies and devDependencies.
-It has a [production mode][6] to focus on production code only and find dead
-code and dependencies that would otherwise only be referenced by tests and other
-tooling. This allows you to remove both unused exported code and their tests.
-
-## Does Knip work with my package manager?
-
-Yes, Knip works with any package manager: npm, pnpm, Bun and Yarn are all
-supported. It's easy to [get started][1] with any package manager.
-
-[1]: ../overview/getting-started.mdx
-[2]: ../reference/plugins.md
-[3]: ../features/compilers.md
-[4]: ../features/auto-fix.mdx
-[5]: ../features/monorepos-and-workspaces.md
-[6]: ../features/production-mode.md

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

@@ -1,87 +0,0 @@
----
-title: Unused exports
-description: Find and remove unused exports with Knip
-prev: false
-next: false
----
-
-Finding unused exports in your JavaScript and TypeScript projects is one of
-Knip's core features. And it comes with even more features to identify and
-remove clutter to keep your projects in great shape.
-
-## Why are unused exports a problem?
-
-Having unused exports in your codebase is problematic for several reasons:
-
-- They increase bundle sizes if not properly eliminated by tree-shaking.
-- They clutter the codebase and make it harder to navigate and understand.
-- They mislead developers into thinking certain code is used when it's not.
-- They make refactoring and maintaining the codebase more difficult.
-- They slow down tooling that analyze the codebase, such as bundlers, linters
-  and type checkers.
-- They may represent dead code that is no longer needed but hasn't been cleaned
-  up.
-
-## How do I find unused exports?
-
-Knip is a powerful tool that can help you find and remove unused exports in your
-JavaScript and TypeScript projects. It analyzes the codebase, identifies exports
-that are not imported anywhere, and reports them.
-
-[Get started and install Knip][1] to run it on your project. Knip will scan your
-files and provide a detailed report of unused exports, and much more.
-
-<div style="display: flex; justify-content: center; margin: 4rem auto;">
-  <img src="/logo.svg" alt="Logo of Knip, to find unused dependencies, exports and files" class="logo-border" />
-</div>
-
-## How does Knip identify unused exports?
-
-Knip performs both static and dynamic analysis to determine which exports are
-actually being used in your codebase. It looks at import statements, export
-usage, and [a lot more code patterns][2] to identify unused exports.
-
-Knip supports JavaScript and TypeScript projects, and handles both [CommonJS][3]
-and ES Modules syntax.
-
-## Can Knip remove unused exports?
-
-Yes, Knip not only finds unused exports but can also remove them for you. Run
-Knip with the `--fix` flag to enable [the auto-fix feature][4], and it will
-modify your source code and remove the unused exports.
-
-It's always recommended to review the changes made by Knip before committing
-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.
-
-## Does Knip work with my favorite editor or IDE?
-
-Knip is a command-line tool that runs independently of your editor or IDE.
-However, if you run Knip inside an integrated IDE terminal, the report contains
-file names and positions in a format IDEs like VS Code and WebStorm understand
-to easily navigate around.
-
-## How is Knip different from ESLint for finding unused exports?
-
-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
-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]
-
-[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

package/src/docs/docs/writing-a-plugin/argument-parsing.md

@@ -1,202 +0,0 @@
----
-title: Argument Parsing
-sidebar:
-  order: 3
----
-
-Some plugins have an `arg` object in their implementation. It's a way for
-plugins to customize how command-line arguments are parsed for their tool's
-executables. Argument parsing in plugins help Knip identify dependencies and
-entry files from scripts.
-
-Knip uses [minimist][1] for argument parsing and some options are identical
-([alias][2], [boolean][3], [string][4]).
-
-Also see [type definitions][5] and [examples in existing plugins][6].
-
-- [alias][2]
-- [args][7]
-- [binaries][8]
-- [boolean][3]
-- [config][9]
-- [fromArgs][10]
-- [nodeImportArgs][11]
-- [positional][12]
-- [resolve][13]
-- [resolveInputs][14]
-- [string][4]
-
-## alias
-
-Define aliases.
-
-Example:
-
-```ts
-{
-  require: ['r'];
-}
-```
-
-Also see [nodeImportArgs][11].
-
-## args
-
-Modify or filter arguments before parsing. For edge cases preprocessing is
-useful, e.g. if minimist has trouble parsing or to modify/discard arguments.
-
-Example:
-
-```ts
-{
-  args: (args: string[]) => args.filter(arg => arg !== 'omit');
-}
-```
-
-## binaries
-
-Executables for the dependency.
-
-Example:
-
-```ts
-{
-  binaries: ['tsc'];
-}
-```
-
-Default: plugin name, e.g. for the ESLint plugin the value is `["eslint"]`
-
-## boolean
-
-Mark arguments as boolean. By default, arguments are expected to have string
-values.
-
-## config
-
-Define arguments that contain the configuration file path. Usually you'll want
-to set aliases too. Use `true` for shorthand to set `alias` + `string` +
-`config`.
-
-Example:
-
-```ts
-{
-  config: true;
-}
-```
-
-The `tsup` plugin has this. Now `tsup --config tsup.client.json` will have
-`tsup.client.json` go through `resolveConfig` (also `-c` alias).
-
-Example:
-
-```ts
-{
-  config: ['p'];
-}
-```
-
-This will mark e.g. `tsc -p tsconfig.lib.json` as a configuration file and it
-will be handled by `resolveConfig` of the (typescript) plugin.
-
-## fromArgs
-
-Parse return value as a new script. Can be a an array of strings, or function
-that returns an array of strings and those values will be parsed separately.
-
-Example:
-
-```ts
-{
-  fromArgs: ['exec'];
-}
-```
-
-Then this script:
-
-```sh
-nodemon --exec "node index.js"
-```
-
-Will have `"node index.js"` being parsed as a new script.
-
-## nodeImportArgs
-
-Set to `true` as a shorthand for this [alias][2]:
-
-```ts
-{
-  import: ['r', 'experimental-loader', 'require', 'loader']
-}
-```
-
-Example:
-
-```ts
-{
-  nodeImportArgs: true;
-}
-```
-
-## positional
-
-Set to `true` to use the first positional argument as an entry point.
-
-Example:
-
-```ts
-{
-  positional: true;
-}
-```
-
-The `tsx` plugin has this and `"tsx script.ts"` as a script will result in the
-`script.ts` file being an entry point.
-
-## resolve
-
-List of arguments to resolve to a dependency or entry file path.
-
-Example:
-
-```ts
-{
-  resolve: ['plugin'];
-}
-```
-
-Now for a script like `"program --plugin package"` this will result in
-`"package"` being resolved as a dependency.
-
-## resolveInputs
-
-Return inputs from parsed arguments
-
-```ts
-{
-  resolveInputs: (parsed: ParsedArgs) =>
-    parsed['flag'] ? [toDependency('package')] : [];
-}
-```
-
-## string
-
-Mark arguments as string. This is the default, but number-looking arguments are
-returned as numbers by minimist.
-
-[1]: https://www.npmjs.com/package/minimist
-[2]: #alias
-[3]: #boolean
-[4]: #string
-[5]: https://github.com/webpro-nl/knip/blob/main/packages/knip/src/types/args.ts
-[6]:
-  https://github.com/search?q=repo%3Awebpro-nl%2Fknip++path%3Apackages%2Fknip%2Fsrc%2Fplugins+%22const+args+%3D%22&type=code
-[7]: #args
-[8]: #binaries
-[9]: #config
-[10]: #fromargs
-[11]: #nodeimportargs
-[12]: #positional
-[13]: #resolve
-[14]: #resolveinputs