@knip/mcp 0.0.2 → 0.0.3

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

@@ -0,0 +1,191 @@
+---
+title: The State of Knip
+date: 2025-02-28
+sidebar:
+  order: 2
+---
+
+_Published: 2025-02-28_
+
+Honestly, Knip was a bit of a "cursed" project from the get-go. Getting anywhere
+near a level of being broadly-ish valuable requires a good amount of
+~~foolishness~~ determination, and it has always been clear it would stay far
+from perfect. It's telling that most of [similar projects][1] have been
+abandoned.
+
+And even though Knip is in its infancy, this update is meant as a sign we feel
+we're still on to something. External indicators include increased usage looking
+at numbers such as dependent repositories on GitHub and weekly downloads on npm,
+and bug reports about increasingly less rudimentary issues.
+
+## Two Cases
+
+For those interested, let's take a look at two cases that hopefully give an
+impression of how Knip works under the hood and the level of issues we're
+currently dealing with. It's assumed you already have a basic understanding of
+Knip (otherwise please consider to read at least [entry files][2] and
+[plugins][3] first).
+
+### Case 1: Next.js
+
+Let's say this default configuration represents, greatly simplified, [the
+default `entry` patterns][4] for projects using Next.js:
+
+```json
+{
+  "next": {
+    "entry": ["next.config.ts", "src/pages/**/*.tsx"]
+  }
+}
+```
+
+Those files will be searched for and then statically analyzed to collect
+`import` statements and find other local files and external dependencies. This
+is the generic way Knip handles all source files.
+
+However, the game changes if the project uses the following Next.js
+configuration:
+
+```ts title="next.config.ts"
+const nextConfig = {
+  pageExtensions: ['page.tsx'],
+};
+
+export default nextConfig;
+```
+
+Next.js will now look for files matching `src/pages/**/*.page.tsx` instead (note
+the subtle change of the glob pattern). Knip should respect this to find used
+and unused files properly.
+
+Moving the burden to users for them to either not notice at all and get
+incorrect results, or having to override the `next.entry` patterns and include
+`src/pages/**/*.page.tsx` isn't good DX. Knip should take care of it.
+
+To get the configuration object and the value of `pageExtensions`, Knip has to
+actually load and execute `next.config.ts` ¹... and trouble is right around the
+corner:
+
+```ts title="next.config.ts"
+const nextConfig = {
+  pageExtensions: ['page.tsx'],
+  env: {
+    BASE_URL: process.env.BASE_URL.toLowerCase(),
+  },
+};
+
+export default nextConfig;
+```
+
+```shell
+$ knip
+💥 LoaderError: Error loading next.config.ts
+💥 Reason: Cannot read properties of undefined (reading 'toLowerCase')
+```
+
+Obviously a contrived example, but the gist is that lots of tooling
+configuration expects environment variables to be defined. But when running Knip
+there might not be a mechanism to set those. Clearly a breaking change when Knip
+starts doing this, only for Next.js projects with a configuration file that
+doesn't read environment variables safely (or has other contextual
+dependencies).
+
+By the way, [the ESLint v9 plugin][5] has a similar issue.
+
+¹ Another approach could be to statically analyze the `next.config.ts`
+configuration file. That would require some additional efforts and get us only
+so far, but is definitely useful in some cases and on the radar.
+
+**EDIT:** This has been solved in the Next.js plugin in v5.48.0.
+
+### Case 2: Knip does that?!
+
+To further bring down user configuration and the number of false positives, the
+system required more components. New components have been introduced to keep
+improving and nail it for an increasing number of projects. This case is an
+illustration of some of those components.
+
+Let's just dive into this example and find out what's happening:
+
+```json title="package.json"
+{
+  "scripts": {
+    "test": "yarn --cwd packages/frontend vitest -c vitest.components.config.ts"
+  }
+}
+```
+
+Orchestration is necessary between various components within Knip, such as:
+
+- Plugins, the Vitest plugin parses `vitest.components.config.ts`
+- Custom CLI argument parsing for executables, e.g. `yarn --cwd [dir]` and
+  `vitest --config [file]`
+- The workspace graph, to see `packages/frontend` is a descendant workspace of
+  the root workspace
+
+Patterns like in the script above do not occur only in `package.json` files, but
+could be anywhere. Here's a similar example in a GitHub Actions workflow:
+
+```yaml title=".github/workflows/test.yml"
+jobs:
+  integration:
+    runs-on: ubuntu-latest
+    steps:
+      - run: playwright test -c playwright.e2e.config.ts
+        working-directory: e2e
+```
+
+The pattern is very similar, because Knip needs to assign a configuration file
+to a specific workspace (assuming there's one in `./e2e`) and apply the Vitest
+configuration to that particular workspace with its own set of directory and
+entry file patterns.
+
+An essential part of Knip is to build up the module graph for source files. With
+the configuration files still in mind, this is the pattern Knip follows towards
+this goal:
+
+- Find configuration files at default and custom locations
+- Assign them to the right workspace
+- Run plugins in their own workspace to take entry file patterns from the
+  configuration objects
+- Load and parse configuration files to get referenced dependencies
+
+The referenced dependencies are stored in the `DependencyDeputy` class to
+eventually determine what dependencies are unused or missing in `package.json`
+in each workspace.
+
+Both the configuration and entry files are then used to start building up the
+module graph.
+
+## Comprehensive
+
+Discussing the two cases briefly covers only part of the whole process. This
+might give a sense of the reason why Knip is pretty comprehensive. After all,
+building the module graph for internal source files to find unused files and
+exports requires the list of external dependencies including internal
+workspaces. And on the other hand, a complete module graph is required to find
+unused or missing external dependencies.
+
+The comprehensiveness also requires a range of components in the system, such as
+the aforementioned ones, [compilers for popular frameworks][6] and a [script
+parser][7], and other affordances such as [auto-fix][8].
+
+That said, code organization could be improved to make it more accessible for
+contributions and, for instance, expose programmatic APIs to use the generated
+module graph outside of Knip. Additionally, existing plugins can better take
+advantage of existing components in the system, and new plugins can be developed
+to further reduce user configuration and false positives.
+
+## The End
+
+That's all for today, thanks for reading! Have a great one, and don't forget:
+Knip it before you ship it! ✂️
+
+[1]: ../explanations/comparison-and-migration.md
+[2]: ../explanations/entry-files.md
+[3]: ../explanations/plugins.md
+[4]: ../reference/plugins/next.md#default-configuration
+[5]: ../reference/plugins/eslint.md#eslint-v9
+[6]: ../features/compilers.md
+[7]: ../features/script-parser.md
+[8]: ../features/auto-fix.mdx

package/docs/docs/blog/two-years.mdx

@@ -0,0 +1,107 @@
+---
+title: Two Years
+date: 2024-10-04
+sidebar:
+  order: 3
+---
+
+_Published: 2024-10-04_
+
+import EmojiBlastButton from '../../../components/EmojiBlastButton.astro';
+import Projects from '../../../components/Projects.astro';
+import Sponsors from '../../../components/Sponsors.astro';
+
+Exactly two years ago the first commit was pushed to GitHub and the first
+version of Knip was published to the npm registry. The name was initially
+[Exportman][1]! We've come a loooong way... The JavaScript ecosystem is highly
+dynamic and I've been crazy enough to even start, try and keep up with it! But
+here we are.
+
+October 4th is World Animal Day, so there was really no choice but bring in the
+crazy mascot that early adopters may remember:
+
+![Crazy cow with orange scissors in Van Gogh style][2]
+
+Today we celebrate an unknown but CRAZY amount of clutter removed from so many
+codebases with Knip's help. Every single day I see many of those little red
+blocks for thousands of lines of deleted code and dependencies. Call me crazy,
+but to me this is pure joy and never gets old!    🟩 🟥 🟥 🟥 🟥
+
+<EmojiBlastButton />
+
+## Smiling faces
+
+The actual amount of code and dependencies removed and the number of smiling
+faces this brings is what matters most, but also remain a good mystery. Clearly
+more and more projects add Knip to their projects and CI workflows to keep
+ever-growing codebases tidy. It's wonderful to see if Knip plays its part in
+today's ecosystem to help with that. Thanks for bearing with me, here's to a lot
+more little red blocks in your PRs!    🟩 🟥 🟥 🟥 🟥
+
+## Updates
+
+Why not throw in some freshly cooked updates in [v5.31.0][3] for you while we're
+at it:
+
+- [The auto-fix feature][4] has been completely revamped, it's much better and a
+  lot more comprehensive! You have to see it to believe it.
+- Knip has upgraded to [Jiti v2][5], resolving a bunch of known issues when
+  loading configuration files authored in TypeScript and ESM, such as:
+
+```
+Cannot use 'import.meta' outside a module
+await is only valid in async functions and the top level bodies of modules
+Unexpected identifier 'Promise'
+Reflect.metadata is not a function
+```
+
+And that pesky "CJS build of Vite's Node API is deprecated" warning is finally
+gone!
+
+Thanks to everyone involved in making this happen, it's truly much appreciated.
+
+## Stable
+
+If you haven't tried Knip recently, it's worth taking another look! Version 5
+was released 8 months ago, and even though there were no breaking changes, it
+includes many enhancements. In fact, Knip has been largely stable since version
+3, which came out a year ago. Many releases have a compound effect, as Knip has
+kept the pace for two years now.
+
+## Projects using Knip
+
+This list of projects using Knip to keep their codebases tidy is something I
+couldn't be more proud of:
+
+:::section{.columns.min200}
+
+<Projects />
+
+:::
+
+And so many more on and off the radar. Very, very cool!
+
+## Sponsors
+
+Last but not least, eternal gratitude for all the sponsors that have been
+supporting me along the way. THANK YOU, THANK YOU, THANK YOU!
+
+And eh.. gotta take my chances: how about [joining this awesome club][6]?
+
+:::section{.columns.min300.mt}
+
+<Sponsors />
+
+:::
+
+## Acknowledgements
+
+Thanks to Joshua Goldberg for [emoji-blast][7]! 🎉
+
+[1]: https://www.npmjs.com/package/exportman/v/0.0.1
+[2]: /cow-with-orange-scissors-van-gogh-style.webp
+[3]: https://github.com/webpro-nl/knip/releases/tag/5.31.0
+[4]: ../features/auto-fix.md
+[5]: https://github.com/unjs/jiti
+[6]: /sponsors
+[7]: https://www.emojiblast.dev

package/docs/docs/explanations/comparison-and-migration.md

@@ -0,0 +1,129 @@
+---
+title: Comparison & Migration
+---
+
+First of all, Knip owes a lot to the projects on this page and they've all been
+inspirational in their own way. For best results, Knip has [a vision embracing
+comprehensiveness][1] which is larger in scope than any of the alternatives. So
+if any of those tools has the right scope for your requirements, then by all
+means, use what suits you best. Note that most projects are no longer
+maintained.
+
+All tools have in common that they have less features and don't support the
+concept of [monorepos/workspaces][2]. Feel free to send in projects that Knip
+does not handle better, Knip loves to be challenged!
+
+## Migration
+
+A migration consists of deleting the dependency and its configuration file and
+[getting started with Knip][3]. You should end up with less configuration.
+
+## Comparison
+
+### depcheck
+
+> [Depcheck][4] is a tool for analyzing the dependencies in a project to see:
+> how each dependency is used, which dependencies are useless, and which
+> dependencies are missing from package.json.
+
+The project has plugins (specials), yet not as many as Knip has and they're not
+as advanced. It also supports compilers (parsers) for non-standard files.
+
+The following commands are similar:
+
+```sh
+depcheck
+knip --dependencies
+```
+
+### unimported
+
+> Find and fix dangling files and unused dependencies in your JavaScript
+> projects.
+
+[unimported][5] is fast and works well. It works in what Knip calls "production
+mode" exclusively. If you're fine with a little bit of configuration and don't
+want or need to deal with non-production items (such as `devDependencies` and
+test files), then this might work well for you.
+
+The following commands are similar:
+
+```sh
+unimported
+knip --production --dependencies --files
+```
+
+**Project status**: The project is archived and recommends Knip.
+
+### ts-prune
+
+> Find unused exports in a typescript project. 🛀
+
+[ts-prune][6] aims to find potentially unused exports in your TypeScript project
+with zero configuration.
+
+The following commands are similar:
+
+```sh
+ts-prune
+knip --include exports,types,nsExports,nsTypes
+```
+
+Use `knip --exports` to also include class and enum members.
+
+**Project status**: The project is archived and recommends Knip.
+
+### ts-unused-exports
+
+> [ts-unused-exports][7] finds unused exported symbols in your Typescript
+> project
+
+The following commands are similar:
+
+```sh
+ts-unused-exports
+knip --include exports,types,nsExports,nsTypes
+```
+
+Use `knip --exports` to also include class and enum members.
+
+### tsr
+
+> Remove unused code from your TypeScript Project
+
+[tsr][8] (previously `ts-remove-unused`) removes unused exports, and works based
+on a single `tsconfig.json` file (`includes` and `excludes`) and requires no
+configuration. It removes the `export` keyword or the whole export declaration.
+
+## Related projects
+
+Additional alternative and related projects include:
+
+- [deadfile][9]
+- [DepClean][10]
+- [dependency-check][11]
+- [find-unused-exports][12]
+- [next-unused][13]
+- [npm-check][14]
+- [renoma][15]
+
+In general, the [e18e.dev][16] website and in particular the [Cleanup][17]
+section is a great resource when dealing with technical debt.
+
+[1]: ./why-use-knip.md#comprehensive
+[2]: ../features/monorepos-and-workspaces.md
+[3]: ../overview/getting-started.mdx
+[4]: https://github.com/depcheck/depcheck
+[5]: https://github.com/smeijer/unimported
+[6]: https://github.com/nadeesha/ts-prune
+[7]: https://github.com/pzavolinsky/ts-unused-exports
+[8]: https://github.com/line/tsr
+[9]: https://github.com/M-Izadmehr/deadfile
+[10]: https://github.com/mysteryven/depclean
+[11]: https://github.com/dependency-check-team/dependency-check
+[12]: https://github.com/jaydenseric/find-unused-exports
+[13]: https://github.com/pacocoursey/next-unused
+[14]: https://github.com/dylang/npm-check
+[15]: https://github.com/bluwy/renoma
+[16]: https://e18e.dev
+[17]: https://e18e.dev/guide/cleanup.html

package/docs/docs/explanations/entry-files.md

@@ -0,0 +1,70 @@
+---
+title: Entry Files
+sidebar:
+  order: 1
+---
+
+Entry files are the starting point for Knip to determine what files are used in
+the codebase. More entry files lead to increased coverage of the codebase. This
+also leads to more dependencies to be discovered. This page explains how Knip
+and its plugins try to find entry files so you don't need to configure them
+yourself.
+
+## Default entry file patterns
+
+For brevity, the [default configuration][1] on the previous page mentions only
+`index.js` and `index.ts`, but the default set of file names and extensions is
+actually a bit larger:
+
+- `index`, `main` and `cli`
+- `js`, `mjs`, `cjs`, `jsx`, `ts`, `mts`, `cts` and `tsx`
+
+This means files like `main.cjs` and `src/cli.ts` are automatically added as
+entry files. Here's the default configuration in full:
+
+```json
+{
+  "entry": [
+    "{index,cli,main}.{js,cjs,mjs,jsx,ts,cts,mts,tsx}",
+    "src/{index,cli,main}.{js,cjs,mjs,jsx,ts,cts,mts,tsx}"
+  ],
+  "project": ["**/*.{js,cjs,mjs,jsx,ts,cts,mts,tsx}!"]
+}
+```
+
+Next to the default locations, Knip looks for `entry` files in other places. In
+a monorepo, this is done for each workspace separately.
+
+The values you set override the default values, they are not merged.
+
+Also see [FAQ: Where does Knip look for entry files?][2]
+
+## Plugins
+
+Plugins often add entry files. For instance, if the Remix, Storybook and Vitest
+plugins are enabled in your project, they'll add additional entry files. See
+[the next page about plugins][3] for more details about this.
+
+## Scripts in package.json
+
+The `package.json` is scanned for entry files. The `main`, `bin`, and `exports`
+fields may contain entry files. The `scripts` are also parsed to find entry
+files and dependencies. See [Script Parser][4] for more details.
+
+## Ignored files
+
+Knip respects `.gitignore` files. By default, ignored files are not added as
+entry files. This behavior can be disabled by using the [`--no-gitignore`][5]
+flag on the CLI.
+
+## Configuring project files
+
+See [configuring project files][6] for guidance on tuning `entry` and `project`
+and when to use `ignore`.
+
+[1]: ../overview/configuration.md#defaults
+[2]: ../reference/faq.md#where-does-knip-look-for-entry-files
+[3]: ./plugins.md
+[4]: ../features/script-parser.md
+[5]: ../reference/cli.md#--no-gitignore
+[6]: ../guides/configuring-project-files.md