@knip/mcp 0.0.1 → 0.0.2

package/docs/blog/brief-history.md

@@ -2,7 +2,7 @@
 title: A Brief History Of Knip
 date: 2023-10-15
 sidebar:
-  order: 6
+  order: 7
 ---
 
 _Published: 2023-10-15_

package/docs/blog/knip-v3.mdx

@@ -2,7 +2,7 @@
 title: Announcing Knip v3
 date: 2023-10-15
 sidebar:
-  order: 7
+  order: 8
 ---
 
 import { Tabs, TabItem } from '@astrojs/starlight/components';

package/docs/blog/knip-v4.mdx

@@ -2,7 +2,7 @@
 title: Announcing Knip v4
 date: 2024-01-16
 sidebar:
-  order: 4
+  order: 5
 ---
 
 import { Tabs, TabItem } from '@astrojs/starlight/components';

package/docs/blog/knip-v5.mdx

@@ -2,7 +2,7 @@
 title: Announcing Knip v5
 date: 2024-02-10
 sidebar:
-  order: 3
+  order: 4
 ---
 
 import { Tabs, TabItem } from '@astrojs/starlight/components';

package/docs/blog/release-notes-v2.md

@@ -1,7 +1,7 @@
 ---
 title: Release Notes v2
 sidebar:
-  order: 8
+  order: 9
 ---
 
 _2023-03-22_

package/docs/blog/slim-down-to-speed-up.md

@@ -2,7 +2,7 @@
 title: Slim down to speed up
 date: 2023-12-14
 sidebar:
-  order: 5
+  order: 6
 ---
 
 _Published: 2023-12-14_

package/docs/blog/state-of-knip.md

@@ -2,7 +2,7 @@
 title: The State of Knip
 date: 2025-02-28
 sidebar:
-  order: 1
+  order: 2
 ---
 
 _Published: 2025-02-28_

package/docs/blog/two-years.mdx

@@ -2,7 +2,7 @@
 title: Two Years
 date: 2024-10-04
 sidebar:
-  order: 2
+  order: 3
 ---
 
 _Published: 2024-10-04_

package/docs/index.mdx

@@ -12,6 +12,10 @@ hero:
       link: ./overview/getting-started
       icon: right-arrow
       variant: primary
+    - text: 'NEW: Knip for Editors & Agents'
+      link: /blog/for-editors-and-agents
+      icon: rocket
+      variant: secondary
     - text: View on GitHub
       link: https://github.com/webpro-nl/knip
       icon: external

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@knip/mcp",
-  "version": "0.0.1",
+  "version": "0.0.2",
   "description": "Knip MCP Server",
   "type": "module",
   "bin": {
@@ -29,7 +29,7 @@
   "dependencies": {
     "@modelcontextprotocol/sdk": "^1.24.3",
     "zod": "^4.1.11",
-    "knip": "5.75.0"
+    "knip": "5.75.1"
   },
   "engines": {
     "node": ">=18.18.0"

package/docs/docs/blog/brief-history.md

@@ -1,30 +0,0 @@
----
-title: A Brief History Of Knip
-date: 2023-10-15
-sidebar:
-  order: 7
----
-
-_Published: 2023-10-15_
-
-If you are fond of short lists and brief histories, then this page was written
-just for you!
-
-- 2022-10-04: The [initial commit][1]. Still so tiny at that point, but the seed
-  was planted. Starting out with finding unused files and exports, the name was
-  Exportman! 🦸
-- 2022-10-09: Big plans and a rename 5 days later, the first published version
-  of Knip was [v0.1.2][2].
-- 2022-11-22: Unused dependencies and support for workspaces and plugins in the
-  [first alpha of v1][3].
-- 2023-01-10: Lots of testing and fixes led to [Knip v1][4].
-- 2023-03-22: [Knip v2][5] saw a full rewrite of the TypeScript backend.
-- 2023-10-15: [Introduction of Knip v3][6].
-
-[1]:
-  https://github.com/webpro-nl/knip/commit/9589dfe22608da7d89f2613383da6db5826226d2
-[2]: https://github.com/webpro-nl/knip/tree/0.1.2
-[3]: https://github.com/webpro-nl/knip/releases/tag/1.0.0-alpha.0
-[4]: https://github.com/webpro-nl/knip/tree/1.0.0
-[5]: https://github.com/webpro-nl/knip/issues/73
-[6]: ./knip-v3.mdx

package/docs/docs/blog/knip-v3.mdx

@@ -1,88 +0,0 @@
----
-title: Announcing Knip v3
-date: 2023-10-15
-sidebar:
-  order: 8
----
-
-import { Tabs, TabItem } from '@astrojs/starlight/components';
-
-_Published: 2023-10-15_
-
-Lots of new users got introduced to Knip, coming with clear bug reports, helpful
-insights, superb reproductions and great suggestions this year. You're all a
-friendly and helpful bunch! Recently I've opened a Discord channel where more
-communication, collaboration, ideas and updates are happening: feel free to join
-[The Knip Barn][1]!
-
-Today, Knip has [over 140k weekly downloads on npm][2], [almost 4000 stars on
-GitHub][3], and [over 500 repositories][4] using it. While numbers are just
-numbers, they do add to the positive feedback I'm receiving daily. Everything
-combined makes me think I'm on the right track which is very motivating to keep
-working on Knip.
-
-## So... What's Been Cooking Lately?
-
-- Migration to a monorepo setup
-- This very website built with Starlight 🌟
-- Extended documentation for just about everything
-- Improved JSON reporter for external integrations (e.g. [GitHub Action][5])
-- Some breaking changes, but you probably don't need to make any changes
-
-## Breaking Changes
-
-A major bump comes with breaking changes, but most likely no changes necessary
-on your end:
-
-- Removed support for Node.js v16, Knip v3 requires at least Node.js v18.6
-- Simplified [exit codes][6]
-- [Production mode][7] now includes types by default (add `--exclude types` for
-  previous behavior)
-- Removed `--ignore-internal` flag; [`@internal`][8] exports ignored in
-  production mode now
-- The `--debug-file-filter` flag is removed
-- The `jsonExt` reporter is now the default [JSON reporter][9] (the previous one
-  is gone)
-- Moved `typescript` to `peerDependencies` (requires `>=5.0.4`)
-
-## Installation
-
-Try out the latest Knip v3 release today!
-
-<Tabs syncKey="pm">
-  <TabItem label="npm">
-    ```shell
-    npm install -D knip
-    ```
-  </TabItem>
-
-  <TabItem label="pnpm">
-    ```shell
-    pnpm add -D knip
-    ```
-  </TabItem>
-
-  <TabItem label="bun">
-    ```shell
-    bun add -D knip
-    ```
-  </TabItem>
-
-  <TabItem label="yarn">
-    ```shell
-    yarn add -D knip
-    ```
-  </TabItem>
-</Tabs>
-
-Remember, Knip it before you ship it! Have a great day ☀️
-
-[1]: https://discord.gg/r5uXTtbTpc
-[2]: https://www.npmjs.com/package/knip
-[3]: https://github.com/webpro-nl/knip/stargazers
-[4]: https://github.com/webpro-nl/knip/network/dependents
-[5]: https://github.com/marketplace/actions/knip-reporter
-[6]: ../reference/cli.md#exit-code
-[7]: ../features/production-mode.md
-[8]: ../reference/jsdoc-tsdoc-tags.md#internal
-[9]: ../features/reporters.md#json

package/docs/docs/blog/knip-v4.mdx

@@ -1,149 +0,0 @@
----
-title: Announcing Knip v4
-date: 2024-01-16
-sidebar:
-  order: 5
----
-
-import { Tabs, TabItem } from '@astrojs/starlight/components';
-
-_Published: 2024-01-16_
-
-I'm happy to announce that Knip v4 is available!
-
-The work took over a month and the process of [slimming down to speed up][1]
-ended up really well: significant faster runs and reduced memory usage. In the
-meantime, v3 continued to receive more contributions, plugins and bug fixes.
-
-## Highlights
-
-Compared to v3, here are the highlights:
-
-- Performance: significant speed bump (up to 80%!)
-- Performance: globbing in combo with `.gitignore` is a lot more efficient
-- Configuration: [built-in compilers][2] (for Astro, MDX, Svelte & Vue)
-- The `ignore` option has been improved
-- Internal refactoring to serialize data for future improvements like caching.
-
-The actual performance win in your projects depends on various factors like size
-and complexity.
-
-## Major Changes
-
-The changes have been tested against various repositories, but it's possible
-that you will encounter false positives caused by the major refactoring that has
-been done. If you do, [please report][3]!
-
-### Unused Class Members
-
-Finding unused class members is no longer enabled by default. Here's why it's
-now opt-in:
-
-- When using Knip for the first time on a large repository it can crash after a
-  while with an out of memory error. This is a terrible experience.
-- Plenty of codebases don't use classes at all, keeping TS programs in memory is
-  a waste of resources.
-- Many configurations already exclude `classMembers` from the output.
-
-Enable unused class members by using the CLI argument or the configuration
-option:
-
-```shell
-knip --include classMembers
-```
-
-```json
-{
-  "include": ["classMembers"]
-}
-```
-
-Now that unused class members is opt-in and better organized within Knip, it
-might be interesting to start looking at opt-ins for other unused members, such
-as those of types and interfaces.
-
-By the way, enum members are "cheap" with the v4 refactor, so those are still
-included by default.
-
-### Compilers
-
-You can remove the `compilers` option from your configuration. Since you can
-override them, your custom compilers can stay where they are. This also means
-that you can go back from `knip.ts` to `knip.json` if you prefer.
-
-### Ignore Files
-
-The `ignore` option accepted patterns like `examples/`, but if you want to
-ignore the files inside this folder you should update to globs like
-`examples/**`.
-
-## What's Next?
-
-The refactoring for this release opens the door to more optimizations, such as
-caching. I'm also very excited to see how deeper integrations such as in GitHub
-Actions or IDEs like VS Code or WebStorm may further develop.
-
-Remember, if you are you using Knip at work your company can [sponsor me][4]!
-
-## One More Thing...
-
-An idea I've been toying with is "tagged exports". The idea is that you can tag
-exports in a JSDoc comment. The tag does not need to be part of the JSDoc or
-TSDoc spec. For example:
-
-```ts
-/** @custom */
-export const myExport = 1;
-```
-
-Then, include or exclude such tagged exports from the report like so:
-
-```shell
-knip --experimental-tags=+custom
-knip --experimental-tags=-custom,-internal
-```
-
-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.
-
-Once this feature is intuitive and stable, the `experimental` flag will be
-removed and option(s) added to the Knip configuration file. The docs are in the
-[CLI reference][5].
-
-## Let's Go!
-
-What are you waiting for? Start using Knip v4 today!
-
-<Tabs syncKey="pm">
-  <TabItem label="npm">
-    ```shell
-    npm install -D knip
-    ```
-  </TabItem>
-
-  <TabItem label="pnpm">
-    ```shell
-    pnpm add -D knip
-    ```
-  </TabItem>
-
-  <TabItem label="bun">
-    ```shell
-    bun add -D knip
-    ```
-  </TabItem>
-
-  <TabItem label="yarn">
-    ```shell
-    yarn add -D knip
-    ```
-  </TabItem>
-</Tabs>
-
-Remember, Knip it before you ship it! Have a great day ☀️
-
-[1]: ./slim-down-to-speed-up.md
-[2]: ../features/compilers.md
-[3]: ../guides/issue-reproduction
-[4]: https://github.com/sponsors/webpro
-[5]: ../reference/cli#--experimental-tags

package/docs/docs/blog/knip-v5.mdx

@@ -1,190 +0,0 @@
----
-title: Announcing Knip v5
-date: 2024-02-10
-sidebar:
-  order: 4
----
-
-import { Tabs, TabItem } from '@astrojs/starlight/components';
-
-_Published: 2024-02-10_
-
-Today brings the smallest major release so far. Tiny yet mighty!
-
-Below are two cases to demonstrate the change in how unused exports are
-reported.
-
-## Case 1
-
-The first case shows two exports with a namespaced import that references one of
-those exports explicitly:
-
-```ts title="knip.js"
-export const version = 'v5';
-export const getRocket = () => '🚀';
-```
-
-```ts title="index.js"
-import * as NS from './knip.js';
-
-console.log(NS.version);
-```
-
-In this case we see that `getRocket` is an unused export.
-
-Previously it would go into the "Unused exports in namespaces" category
-(`nsExports`). This issue has been moved to the "Unused exports" category
-(`exports`).
-
-## Case 2
-
-The second case is similar, but only the imported namespace itself is
-referenced. None of the individual exports is referenced:
-
-```ts title="index.js"
-import * as NS from './knip.js';
-import send from 'stats';
-
-send(NS);
-```
-
-Are the `version` and `getRocket` exports used? We can't know. The same is true
-for the spread object pattern:
-
-```ts title="index.js"
-import * as NS from './knip.js';
-
-const Spread = { ...NS };
-```
-
-Previously those exports would go into the "Unused exports in namespaces"
-category. This is still the case, but this category is no longer enabled by
-default.
-
-## Include unused exports in namespaces
-
-To enable this type of issues in Knip v5, add this argument to the command:
-
-```shell
-knip --include nsExports
-```
-
-Or in your configuration file:
-
-```json title="knip.json"
-{
-  "include": ["nsExports", "nsTypes"]
-}
-```
-
-Now `version` and `getRocket` will be reported as "Unused exports in
-namespaces".
-
-Note that `nsExports` and `nsTypes` are split for more granular control.
-
-## Handling exports in namespaced imports
-
-You have a few options to handle namespaced imports when it comes to unused
-exports.
-
-### 1. Use named imports
-
-Regardless of whether `nsExports` is enabled or not, it's often good practice to
-replace the namespaced imports with named imports:
-
-```ts title="index.js"
-import { version, getRocket } from './knip.js';
-
-send({ version, getRocket });
-```
-
-Whenever possible, explicit over implicit is often the better choice.
-
-### 2. Standardized JSDoc tags
-
-Using one of the available JSDoc tags like `@public` or `@internal`:
-
-```ts title="knip.js"
-export const version = 'v5';
-/** @public */
-export const getRocket = () => '🚀';
-```
-
-Assuming only imported using a namespace (like in the example cases above), this
-will exclude the `getRocket` export from the report, even though it isn't
-explicitly referenced.
-
-### 3. Arbitrary JSDoc tags
-
-Another solution is to tag individual exports arbitrarily:
-
-```ts title="knip.js"
-export const version = 'v5';
-/** @launch */
-export const getRocket = () => '🚀';
-```
-
-And then exclude the tag like so:
-
-```shell
-$ knip --experimental-tags=-launch
-Exports in used namespace (1)
-version  NS  unknown  knip.js:1:1
-```
-
-Assuming only imported using a namespace (like in the example cases above), this
-will exclude the `getRocket` export from the report, even though it isn't
-explicitly referenced.
-
-## A better default
-
-I believe this behavior in v5 is the better default: have all exports you want
-to know about in a single category, and those you probably want to ignore in
-another that's disabled by default.
-
-Before the [v4 refactoring][1], this would be a lot harder to implement. That
-refactoring turns out to be a better investment than expected. Combined with a
-better understanding of how people write code and use Knip, this change is a
-natural iteration.
-
-Why the major bump? It's not breaking for the large majority of users, but for
-some it may be breaking. For instance when relying on the [JSON reporter][2],
-other reporter output, or custom [preprocessing][3]. It's not a bug fix, it's
-not a new feature, but since semver is all about setting expectations I feel the
-change is large enough to warrant a major bump.
-
-## Let's Go!
-
-What are you waiting for? Start using Knip v5 today!
-
-<Tabs syncKey="pm">
-  <TabItem label="npm">
-    ```shell
-    npm install -D knip
-    ```
-  </TabItem>
-
-  <TabItem label="pnpm">
-    ```shell
-    pnpm add -D knip
-    ```
-  </TabItem>
-
-  <TabItem label="bun">
-    ```shell
-    bun add -D knip
-    ```
-  </TabItem>
-
-  <TabItem label="yarn">
-    ```shell
-    yarn add -D knip
-    ```
-  </TabItem>
-</Tabs>
-
-Remember, Knip it before you ship it! Have a great day ☀️
-
-[1]: ../blog/slim-down-to-speed-up.md
-[2]: ../features/reporters.md#json
-[3]: ../features/reporters.md#preprocessors

package/docs/docs/blog/migration-to-v1.md

@@ -1,65 +0,0 @@
----
-title: Migration to v1
----
-
-_2023-01-04_
-
-When coming from version v0.13.3 or before, there are some breaking changes:
-
-- The `entryFiles` and `projectFiles` options have been renamed to `entry` and
-  `project`.
-- The `--dev` argument and `dev: true` option are gone, this is now the default
-  mode (see [production mode][1]).
-- Workspaces have been moved from the root of the config to the `workspaces` key
-  (see [workspaces][2]).
-- The `--dir` argument has been renamed to `--workspace`.
-
-## Example
-
-A configuration like this in v0.13.3 or before...
-
-```json
-{
-  "entryFiles": ["src/index.ts"],
-  "projectFiles": ["src/**/*.ts", "!**/*.spec.ts"],
-  "dev": {
-    "entryFiles": ["src/index.ts", "src/**/*.spec.ts", "src/**/*.e2e.ts"],
-    "projectFiles": ["src/**/*.ts"]
-  }
-}
-```
-
-...should become this for v1...
-
-```json
-{
-  "entry": ["src/index.ts!"],
-  "project": ["src/**/*.ts!"]
-}
-```
-
-Much cleaner, right? For some more details:
-
-- The `dev` property for the `--dev` flag is now the default mode.
-- Use `--production` to analyze only the `entry` and `project` files suffixed
-  with `!`.
-- The glob patterns for both types of test files (`*.spec.ts` and `*.e2e.ts`)
-  are no longer needed:
-  - Regular test files like `*.test.js` and `*.spec.ts` etc. are automatically
-    handled by Knip.
-  - The `*.e2e.ts` files is configured with the Cypress or other plugin. Note
-    that Cypress uses `*.cy.ts` for spec files, but this could be overridden
-    like so:
-
-```json
-{
-  "entry": "src/index.ts!",
-  "project": "src/**/*.ts!",
-  "cypress": {
-    "entry": "src/**/*.e2e.ts"
-  }
-}
-```
-
-[1]: ../features/production-mode.md
-[2]: ../features/monorepos-and-workspaces.md

package/docs/docs/blog/release-notes-v2.md

@@ -1,46 +0,0 @@
----
-title: Release Notes v2
-sidebar:
-  order: 9
----
-
-_2023-03-22_
-
-## Breaking changes
-
-When coming from v1, there are no breaking changes in terms of configuration.
-
-## Changes
-
-There are some changes regarding CLI arguments and output:
-
-- Knip now runs on every \[workspace]\[1] automatically (except for the ones in
-  `ignoreWorkspaces: []`).
-- The "Unlisted or unresolved dependencies" is split in "Unlisted dependencies"
-  and "Unresolved imports".
-- Bug fixes and increased correctness impact output (potentially causing CI to
-  now succeed or fail).
-
-## New features
-
-Rewriting a major part of Knip's core from scratch allows for some new exciting
-features:
-
-- **Performance**. Files are read only once, and their ASTs are traversed only
-  once. Projects of any size will notice the difference. Total running time for
-  some projects decreases with 90%.
-- **Compilers**. You can now include other file types such as `.mdx`, `.vue` and
-  `.svelte` in the analysis.
-
-Internally, the `ts-morph` dependency is replaced by `typescript` itself.
-
-## Other improvements
-
-- Improved support for workspaces.
-- Improved module resolutions, self-referencing imports, and other things you
-  don't want to worry about.
-- Configure `ignoreDependencies` and `ignoreBinaries` at the workspace level.
-- Simplified plugins model: plugin dependency finder may now return any type of
-  dependency in a single array: npm packages, local workspace packages, local
-  files, etc. (module and path resolution are handled outside the plugin).
-- Many bugfixes.