@knip/mcp 0.0.4 → 0.0.6
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/docs/docs/blog/brief-history.md +30 -0
- package/docs/docs/blog/for-editors-and-agents.md +127 -0
- package/docs/docs/blog/knip-v3.mdx +88 -0
- package/docs/docs/blog/knip-v4.mdx +149 -0
- package/docs/docs/blog/knip-v5.mdx +190 -0
- package/docs/docs/blog/migration-to-v1.md +65 -0
- package/docs/docs/blog/release-notes-v2.md +46 -0
- package/docs/docs/blog/slim-down-to-speed-up.md +269 -0
- package/docs/docs/blog/state-of-knip.md +191 -0
- package/docs/docs/blog/two-years.mdx +107 -0
- package/docs/docs/explanations/comparison-and-migration.md +129 -0
- package/docs/docs/explanations/entry-files.md +70 -0
- package/docs/docs/explanations/plugins.md +319 -0
- package/docs/docs/explanations/why-use-knip.md +128 -0
- package/docs/docs/features/auto-fix.mdx +333 -0
- package/docs/docs/features/compilers.md +172 -0
- package/docs/docs/features/integrated-monorepos.md +61 -0
- package/docs/docs/features/monorepos-and-workspaces.md +134 -0
- package/docs/docs/features/production-mode.md +95 -0
- package/docs/docs/features/reporters.md +302 -0
- package/docs/docs/features/rules-and-filters.md +102 -0
- package/docs/docs/features/script-parser.md +156 -0
- package/docs/docs/features/source-mapping.md +100 -0
- package/docs/docs/guides/configuring-project-files.md +205 -0
- package/docs/docs/guides/contributing.md +24 -0
- package/docs/docs/guides/handling-issues.mdx +646 -0
- package/docs/docs/guides/issue-reproduction.md +94 -0
- package/docs/docs/guides/namespace-imports.md +125 -0
- package/docs/docs/guides/performance.md +97 -0
- package/docs/docs/guides/troubleshooting.md +136 -0
- package/docs/docs/guides/using-knip-in-ci.md +54 -0
- package/docs/docs/guides/working-with-commonjs.md +72 -0
- package/docs/docs/index.mdx +160 -0
- package/docs/docs/overview/configuration.md +104 -0
- package/docs/docs/overview/features.md +66 -0
- package/docs/docs/overview/getting-started.mdx +195 -0
- package/docs/docs/overview/screenshots-videos.md +42 -0
- package/docs/docs/playground.mdx +38 -0
- package/docs/docs/reference/cli.md +485 -0
- package/docs/docs/reference/configuration.md +413 -0
- package/docs/docs/reference/dynamic-configuration.mdx +72 -0
- package/docs/docs/reference/faq.md +441 -0
- package/docs/docs/reference/issue-types.md +43 -0
- package/docs/docs/reference/jsdoc-tsdoc-tags.md +122 -0
- package/docs/docs/reference/known-issues.md +64 -0
- package/docs/docs/reference/plugins/.gitkeep +0 -0
- package/docs/docs/reference/plugins.md +238 -0
- package/docs/docs/reference/related-tooling.md +46 -0
- package/docs/docs/sponsors.mdx +65 -0
- package/docs/docs/typescript/unused-dependencies.md +86 -0
- package/docs/docs/typescript/unused-exports.md +87 -0
- package/docs/docs/writing-a-plugin/argument-parsing.md +202 -0
- package/docs/docs/writing-a-plugin/index.md +376 -0
- package/docs/docs/writing-a-plugin/inputs.md +162 -0
- package/package.json +5 -3
|
@@ -0,0 +1,100 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Source Mapping
|
|
3
|
+
sidebar:
|
|
4
|
+
order: 4
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
Knip is mostly interested in source code. Analyzing build artifacts hurts
|
|
8
|
+
performance and often leads to false positives, as they potentially contain
|
|
9
|
+
bundled code and unresolvable imports.
|
|
10
|
+
|
|
11
|
+
That's why Knip tries to map such build artifacts back to their original source
|
|
12
|
+
files and analyze those instead. This is done based on `tsconfig.json` settings.
|
|
13
|
+
|
|
14
|
+
## Example 1: package.json
|
|
15
|
+
|
|
16
|
+
Let's look at an example case with `package.json` and `tsconfig.json` files, and
|
|
17
|
+
see how "dist" files are mapped to "src" files.
|
|
18
|
+
|
|
19
|
+
```jsonc title="package.json"
|
|
20
|
+
{
|
|
21
|
+
"name": "my-workspace",
|
|
22
|
+
"main": "index.js",
|
|
23
|
+
"exports": {
|
|
24
|
+
".": "./src/entry.js",
|
|
25
|
+
"./feat": "./lib/feat.js",
|
|
26
|
+
"./public": "./dist/app.js",
|
|
27
|
+
"./public/*": "./dist/*.js",
|
|
28
|
+
"./public/*.js": "./dist/*.js",
|
|
29
|
+
"./dist/internal/*": null,
|
|
30
|
+
},
|
|
31
|
+
}
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
With this TypeScript configuration:
|
|
35
|
+
|
|
36
|
+
```json title="tsconfig.json"
|
|
37
|
+
{
|
|
38
|
+
"compilerOptions": {
|
|
39
|
+
"baseUrl": "src",
|
|
40
|
+
"outDir": "dist"
|
|
41
|
+
}
|
|
42
|
+
}
|
|
43
|
+
```
|
|
44
|
+
|
|
45
|
+
- `./src/entry.js` is not in an `outDir` folder, so it's added as an entry file
|
|
46
|
+
- `./lib/feat.js` is not in an `outDir` folder, so it's added as an entry file
|
|
47
|
+
- `./dist/app.js` is in a `dist` folder and mapped to `./src/app.{js,ts}` (¹)
|
|
48
|
+
- `./dist/*.js` is in a `dist` folder and mapped to `./src/**/*.{js,ts}` (¹)
|
|
49
|
+
- `./dist/internal/*` is translated to `./dist/internal/**` and files in this
|
|
50
|
+
directory and deeper are ignored when globbing entry files
|
|
51
|
+
|
|
52
|
+
(¹) full extensions list is actually: `js`, `mjs`, `cjs`, `jsx`, `ts`, `tsx`,
|
|
53
|
+
`mts`, `cts`
|
|
54
|
+
|
|
55
|
+
In `--debug` mode, look for "Source mapping" to see this in action.
|
|
56
|
+
|
|
57
|
+
:::tip
|
|
58
|
+
|
|
59
|
+
Using `./dist/*.js` means that all files matching `./src/**/*.{js,ts}` are added
|
|
60
|
+
as entry files. By default, unused exports of entry files are not reported. Use
|
|
61
|
+
[includeEntryExports][1] to include them.
|
|
62
|
+
|
|
63
|
+
:::
|
|
64
|
+
|
|
65
|
+
## Example 2: monorepo
|
|
66
|
+
|
|
67
|
+
Let's say we have this module in a monorepo that imports `helper` from another
|
|
68
|
+
workspace in the same monorepo:
|
|
69
|
+
|
|
70
|
+
```ts title="index.js"
|
|
71
|
+
import { helper } from '@org/shared';
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
The target workspace `@org/shared` has this `package.json`:
|
|
75
|
+
|
|
76
|
+
```json title="package.json"
|
|
77
|
+
{
|
|
78
|
+
"name": "@org/shared",
|
|
79
|
+
"main": "dist/index.js"
|
|
80
|
+
}
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
The module resolver will resolve `@org/shared` to `dist/index.js`. That file is
|
|
84
|
+
usually compiled and git-ignored, while Knip wants the source file instead.
|
|
85
|
+
|
|
86
|
+
:::tip
|
|
87
|
+
|
|
88
|
+
You may need to compile build artifacts to `outDir` first before Knip can
|
|
89
|
+
successfully apply source mapping for internal references in a monorepo.
|
|
90
|
+
|
|
91
|
+
:::
|
|
92
|
+
|
|
93
|
+
If the target workspace has a `tsconfig.json` file with an `outDir` option, Knip
|
|
94
|
+
will try to map the "dist" file to the "src" file. Then if `src/index.ts`
|
|
95
|
+
exists, Knip will use that file instead of `dist/index.js`.
|
|
96
|
+
|
|
97
|
+
Currently this only works based on `tsconfig.json`, in the future more source
|
|
98
|
+
mappings may be added.
|
|
99
|
+
|
|
100
|
+
[1]: ../reference/configuration.md#includeentryexports
|
|
@@ -0,0 +1,205 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Configuring Project Files
|
|
3
|
+
sidebar:
|
|
4
|
+
order: 1
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
The `entry` and `project` file patterns are the first and most important
|
|
8
|
+
options. Getting those right is essential to help you delete more code and make
|
|
9
|
+
Knip faster:
|
|
10
|
+
|
|
11
|
+
- Start with defaults. Only add targeted `entry` overrides when needed.
|
|
12
|
+
- Use `project` patterns (with negations) to define the scope for Knip.
|
|
13
|
+
- Use production mode to exclude tests and other non-production files.
|
|
14
|
+
- Use `ignore` only to suppress issues in specific files. It does not exclude
|
|
15
|
+
files from analysis.
|
|
16
|
+
|
|
17
|
+
Let's dive in and expand on all of these.
|
|
18
|
+
|
|
19
|
+
## Entry files
|
|
20
|
+
|
|
21
|
+
Avoid adding too many files as `entry` files:
|
|
22
|
+
|
|
23
|
+
1. Knip does not report [unused exports][1] in entry files by default.
|
|
24
|
+
2. Proper `entry` and `project` patterns allow Knip to find unused files and
|
|
25
|
+
exports.
|
|
26
|
+
|
|
27
|
+
## Unused files
|
|
28
|
+
|
|
29
|
+
Files are reported as unused if they are in the set of `project` files, but are
|
|
30
|
+
not resolved from the `entry` files:
|
|
31
|
+
|
|
32
|
+
```
|
|
33
|
+
unused files = project files - (entry files + resolved files)
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
See [entry files][2] to see where Knip looks for entry files. Fine-tune `entry`
|
|
37
|
+
and adjust `project` to fit your codebase.
|
|
38
|
+
|
|
39
|
+
:::tip
|
|
40
|
+
|
|
41
|
+
Use negated `project` patterns to precisely include/exclude files for unused
|
|
42
|
+
files detection.
|
|
43
|
+
|
|
44
|
+
Use `ignore` to suppress issues in matching files; it does not remove those
|
|
45
|
+
files from analysis.
|
|
46
|
+
|
|
47
|
+
:::
|
|
48
|
+
|
|
49
|
+
## Negated patterns
|
|
50
|
+
|
|
51
|
+
When there are too many files in the analysis, start here.
|
|
52
|
+
|
|
53
|
+
For instance, routes are entry files except those prefixed with an underscore:
|
|
54
|
+
|
|
55
|
+
```json
|
|
56
|
+
{
|
|
57
|
+
"entry": ["src/routes/*.ts", "!src/routes/_*.ts"]
|
|
58
|
+
}
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
Some files are not part of your source and are reported as unused (false
|
|
62
|
+
positives)? Use negated `project` patterns:
|
|
63
|
+
|
|
64
|
+
```json
|
|
65
|
+
{
|
|
66
|
+
"entry": ["src/index.ts"],
|
|
67
|
+
"project": ["src/**/*.ts", "!src/exclude/**"]
|
|
68
|
+
}
|
|
69
|
+
```
|
|
70
|
+
|
|
71
|
+
❌ Don't use `ignore` for generated artifacts:
|
|
72
|
+
|
|
73
|
+
```json title="knip.json"
|
|
74
|
+
{
|
|
75
|
+
"entry": ["src/index.ts", "scripts/*.ts"],
|
|
76
|
+
"ignore": ["build/**", "dist/**", "src/generated.ts"]
|
|
77
|
+
}
|
|
78
|
+
```
|
|
79
|
+
|
|
80
|
+
✅ Do define your project boundaries:
|
|
81
|
+
|
|
82
|
+
```json title="knip.json"
|
|
83
|
+
{
|
|
84
|
+
"entry": ["src/index.ts", "scripts/*.ts"],
|
|
85
|
+
"project": ["src/**", "scripts/**"],
|
|
86
|
+
"ignore": ["src/generated.ts"]
|
|
87
|
+
}
|
|
88
|
+
```
|
|
89
|
+
|
|
90
|
+
Why is this better:
|
|
91
|
+
|
|
92
|
+
- `project` defines "what belongs to the codebase" so build outputs are not part
|
|
93
|
+
of the analysis and don't appear in unused file detection at all
|
|
94
|
+
- `ignore` is for the few files that should be analyzed but contain exceptions
|
|
95
|
+
- increases performance by analyzing only source files
|
|
96
|
+
|
|
97
|
+
## Ignore issues in specific files
|
|
98
|
+
|
|
99
|
+
Use `ignore` when a specific analyzed file is not handled properly by Knip or
|
|
100
|
+
intentionally contains unused exports (e.g. generated files exporting
|
|
101
|
+
"everything"):
|
|
102
|
+
|
|
103
|
+
```json
|
|
104
|
+
{
|
|
105
|
+
"entry": ["src/index.ts"],
|
|
106
|
+
"project": ["src/**/*.ts"],
|
|
107
|
+
"ignore": ["src/generated.ts"]
|
|
108
|
+
}
|
|
109
|
+
```
|
|
110
|
+
|
|
111
|
+
Also see [ignoreExportsUsedInFile][3] for a more targeted approach.
|
|
112
|
+
|
|
113
|
+
## Production Mode
|
|
114
|
+
|
|
115
|
+
Default mode includes tests and other non-production files in the analysis. To
|
|
116
|
+
focus on production code, use [production mode][4].
|
|
117
|
+
|
|
118
|
+
Don't try to exclude tests via `ignore` or negated `project` patterns. That's
|
|
119
|
+
inefficient and ineffective due to entries added by plugins. Use production mode
|
|
120
|
+
instead.
|
|
121
|
+
|
|
122
|
+
❌ Don't do this:
|
|
123
|
+
|
|
124
|
+
```json
|
|
125
|
+
{
|
|
126
|
+
"ignore": ["**/*.test.js"]
|
|
127
|
+
}
|
|
128
|
+
```
|
|
129
|
+
|
|
130
|
+
Why not: `ignore` only hides issues from the report; it does not exclude files
|
|
131
|
+
from analysis.
|
|
132
|
+
|
|
133
|
+
❌ Also don't do this:
|
|
134
|
+
|
|
135
|
+
```json
|
|
136
|
+
{
|
|
137
|
+
"entry": ["index.ts", "!**/*.test.js"]
|
|
138
|
+
}
|
|
139
|
+
```
|
|
140
|
+
|
|
141
|
+
Why not: plugins for test frameworks add test file as `entry` files, you can't
|
|
142
|
+
and shouldn't override that globally.
|
|
143
|
+
|
|
144
|
+
❌ Or this:
|
|
145
|
+
|
|
146
|
+
```json
|
|
147
|
+
{
|
|
148
|
+
"project": ["**/*.ts", "!**/*.spec.ts"]
|
|
149
|
+
}
|
|
150
|
+
```
|
|
151
|
+
|
|
152
|
+
Why not: `project` is used for unused file detection. Negating test files here
|
|
153
|
+
is ineffective, because they're `entry` files.
|
|
154
|
+
|
|
155
|
+
✅ Do this instead:
|
|
156
|
+
|
|
157
|
+
```shell
|
|
158
|
+
knip --production
|
|
159
|
+
```
|
|
160
|
+
|
|
161
|
+
To fine-tune the resulting production file set, for instance to exclude test
|
|
162
|
+
helper files that still show as unused, use the exclamation mark suffix on
|
|
163
|
+
production patterns:
|
|
164
|
+
|
|
165
|
+
```json
|
|
166
|
+
{
|
|
167
|
+
"entry": ["src/index.ts!"],
|
|
168
|
+
"project": ["src/**/*.ts!", "!src/test-helpers/**!"]
|
|
169
|
+
}
|
|
170
|
+
```
|
|
171
|
+
|
|
172
|
+
Remember to keep adding the exclamation mark `suffix!` for production file
|
|
173
|
+
patterns.
|
|
174
|
+
|
|
175
|
+
:::tip
|
|
176
|
+
|
|
177
|
+
Use the exclamation mark (`!`) on both ends (`!`) to exclude files in production
|
|
178
|
+
mode.
|
|
179
|
+
|
|
180
|
+
:::
|
|
181
|
+
|
|
182
|
+
## Defaults & Plugins
|
|
183
|
+
|
|
184
|
+
To reiterate, the default `entry` and `project` files for each workspace:
|
|
185
|
+
|
|
186
|
+
```json
|
|
187
|
+
{
|
|
188
|
+
"entry": [
|
|
189
|
+
"{index,cli,main}.{js,cjs,mjs,jsx,ts,cts,mts,tsx}",
|
|
190
|
+
"src/{index,cli,main}.{js,cjs,mjs,jsx,ts,cts,mts,tsx}"
|
|
191
|
+
],
|
|
192
|
+
"project": ["**/*.{js,cjs,mjs,jsx,ts,cts,mts,tsx}!"]
|
|
193
|
+
}
|
|
194
|
+
```
|
|
195
|
+
|
|
196
|
+
Next to this, there are other places where [Knip looks for entry files][2].
|
|
197
|
+
|
|
198
|
+
Additionally, [plugins have plenty of entry files configured][5] that are
|
|
199
|
+
automatically added as well.
|
|
200
|
+
|
|
201
|
+
[1]: ../typescript/unused-exports.md
|
|
202
|
+
[2]: ../explanations/entry-files.md
|
|
203
|
+
[3]: ../reference/configuration#ignoreexportsusedinfile
|
|
204
|
+
[4]: ../features/production-mode.md
|
|
205
|
+
[5]: ../explanations/plugins.md#entry-files
|
|
@@ -0,0 +1,24 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Contributing to Knip
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
Here are some ways to contribute to Knip:
|
|
6
|
+
|
|
7
|
+
- Spread the word!
|
|
8
|
+
- [Star the project][1]
|
|
9
|
+
- [File an issue with a reproduction][2]
|
|
10
|
+
- [Pull requests are welcome][3]
|
|
11
|
+
|
|
12
|
+
[Writing a plugin][4] is a great and fun way to get started.
|
|
13
|
+
|
|
14
|
+
The [CONTRIBUTING.md][3] and [DEVELOPMENT.md][5] guides should get you up and
|
|
15
|
+
running quickly.
|
|
16
|
+
|
|
17
|
+
The main goal of Knip is to keep projects clean & tidy. Everything that
|
|
18
|
+
contributes to that goal is welcome!
|
|
19
|
+
|
|
20
|
+
[1]: https://github.com/webpro-nl/knip
|
|
21
|
+
[2]: ./issue-reproduction.md
|
|
22
|
+
[3]: https://github.com/webpro-nl/knip/blob/main/.github/CONTRIBUTING.md
|
|
23
|
+
[4]: ./writing-a-plugin.md
|
|
24
|
+
[5]: https://github.com/webpro-nl/knip/blob/main/.github/DEVELOPMENT.md
|