@@ -48,14 +48,13 @@ hands".
48
48
49
49
On the other hand, Knip is a project linter that should be part of QA. It lints,
50
50
reports and fixes only your own source code. A linter reporting issues hands
51
- control back to you (unless you [ auto-fix] ( ../features/auto-fix.mdx )
52
- everything).
51
+ control back to you (unless you [ auto-fix] [ 1 ] everything).
53
52
54
53
Besides those differences, Knip has a broader scope:
55
54
56
- - Improve DX (see [ less is more] ( ../explanations/why-use-knip.md#less-is-more ) ).
55
+ - Improve DX (see [ less is more] [ 2 ] ).
57
56
- Include non-production code and dependencies in the process by default.
58
- - Report more [ issue types] ( ./issue-types.md ) (such as unlisted dependencies).
57
+ - Report more [ issue types] [ 3 ] (such as unlisted dependencies).
59
58
60
59
## Synergy
61
60
@@ -88,13 +87,13 @@ Building up the module and dependency graph requires non-standard module
88
87
resolution and not only static but also dynamic analysis (i.e. actually load and
89
88
execute modules), such as for parsers of plugins to receive the exported value
90
89
of dynamic tooling configuration files. Additionally, [ exports consumed by
91
- external libraries] [ 1 ] require type information, as supported by the TypeScript
90
+ external libraries] [ 4 ] require type information, as supported by the TypeScript
92
91
backend. Last but not least, shell script parsing is required to find the right
93
92
entry files, configuration files and dependencies accurately.
94
93
95
94
The rippling effect of plugins and recursively adding entry files and
96
95
dependencies to build up the graph is also exactly what's meant by
97
- [ "comprehensive" here] [ 2 ] .
96
+ [ "comprehensive" here] [ 5 ] .
98
97
99
98
## Building the graph
100
99
@@ -136,9 +135,8 @@ files (`config/vitest.config.ts` and `playwright.e2e.config.ts` in the examples
136
135
above). They're recognized as configuration files and passed to their respective
137
136
plugins, and may contain additional entry files.
138
137
139
- Entry files are added to the module graph.
140
- [Module resolution](#module-resolution) might result in additional entry files
141
- recursively until no more entry files are found.
138
+ Entry files are added to the module graph. [Module resolution][6] might result
139
+ in additional entry files recursively until no more entry files are found.
142
140
143
141
# ## What does Knip look for in source files?
144
142
@@ -150,7 +148,7 @@ all nodes of the generated AST to find:
150
148
- Accessed properties on namespace imports and re-exports to track individual
151
149
export usage
152
150
- Calls to `require.resolve` and `import.meta.resolve`
153
- - Scripts in template strings (passed to [script parser][3 ])
151
+ - Scripts in template strings (passed to [script parser][7 ])
154
152
155
153
# ## What's in the graph?
156
154
@@ -188,7 +186,7 @@ there are a few issues with this approach:
188
186
189
187
- It requires lockfile parsing for each lockfile format and version of each
190
188
package manager.
191
- - The lockfile doesn't contain whether the package [has types included][4 ].
189
+ - The lockfile doesn't contain whether the package [has types included][8 ].
192
190
193
191
# # Module Resolution
194
192
@@ -209,12 +207,12 @@ seem to meet all requirements to be usable on its own by Knip:
209
207
` module.js`
210
208
211
209
A few strategies have been tried and tweaked, and Knip currently uses a
212
- combination of [enhanced-resolve][5 ], the TypeScript module resolver and a few
210
+ combination of [enhanced-resolve][9 ], the TypeScript module resolver and a few
213
211
customizations. This single custom module resolver function is hooked into the
214
212
TypeScript compiler and language service hosts.
215
213
216
214
Everything else outside the dependency graph is handled by `enhanced-resolve`
217
- when doing things like [script parsing][3 ] and resolving references to files in
215
+ when doing things like [script parsing][7 ] and resolving references to files in
218
216
other workspaces.
219
217
220
218
# ## How does Knip handle non-standard import syntax?
@@ -245,7 +243,7 @@ file. They're not a concept in Knip.
245
243
246
244
A TypeScript program has a 1-to-1 relationship with workspaces if they're
247
245
analyzed in isolation. However, by default Knip optimizes for performance and
248
- utilizes [workspace sharing][6 ]. That's why debug output contains messages like
246
+ utilizes [workspace sharing][10 ]. That's why debug output contains messages like
249
247
" Installed 2 programs for 29 workspaces" .
250
248
251
249
# ## Why doesn't Knip match my TypeScript project structure?
@@ -277,7 +275,7 @@ Knip shares the files of multiple workspaces in a single program if their
277
275
configuration allows it. This optimization is enabled by default, while it also
278
276
allows the module resolver (one per program) to do some more caching.
279
277
280
- Also see [workspace sharing][6 ].
278
+ Also see [workspace sharing][10 ].
281
279
282
280
# ## Why doesn't Knip just use `ts.findReferences`?
283
281
@@ -293,7 +291,7 @@ comprehensive graph include:
293
291
Without sacrificing these benefits, Knip does use `ts.findReferences` to find
294
292
references to class members (i.e. when the issue type `classMembers` is
295
293
included). In case analysis of exports requires type information of external
296
- dependencies, the [`--include-libs ` flag][1 ] will trigger the same.
294
+ dependencies, the [`--include-libs ` flag][4 ] will trigger the same.
297
295
298
296
# ## Why can't I use path aliases to reference other workspaces?
299
297
@@ -359,7 +357,7 @@ other file types.
359
357
Knip comes with basic "compilers" for a few common non-standard file types.
360
358
They're not actual compilers, they're regular expressions only to extract import
361
359
statements. Override the built-in Vue "compiler" with the real one in your
362
- project. Also see the answer to the previous question and [Compilers][7 ].
360
+ project. Also see the answer to the previous question and [Compilers][11 ].
363
361
364
362
# # Miscellaneous
365
363
@@ -379,7 +377,7 @@ Which mode should've been the default? They both have their merits:
379
377
tooling, including most issues found in production mode. This mode has the
380
378
most impact on DX, for the same reason.
381
379
382
- Also see [production mode][8 ].
380
+ Also see [production mode][12 ].
383
381
384
382
# ## Why doesn't Knip have...?
385
383
@@ -403,14 +401,18 @@ Examples of features that have been requested include:
403
401
404
402
These are all interesting ideas, but most increase the API surface area, and all
405
403
require more development efforts and maintenance. Time is limited and
406
- [sponsorships][9] currently don't cover - this can change though!
407
-
408
- [1] : ../guides/handling-issues.mdx#external-libraries
409
- [2] : ../explanations/why-use-knip.md#comprehensive
410
- [3] : ../features/script-parser.md
411
- [4] : ../guides/handling-issues.mdx#types-packages
412
- [5] : https://www.npmjs.com/package/enhanced-resolve
413
- [6] : ../guides/performance.md#workspace-sharing
414
- [7] : ../features/compilers.md
415
- [8] : ../features/production-mode.md
416
- [9] : /sponsors
404
+ [sponsorships][13] currently don't cover - this can change though!
405
+
406
+ [1] : ../features/auto-fix.mdx
407
+ [2] : ../explanations/why-use-knip.md#less-is-more
408
+ [3] : ./issue-types.md
409
+ [4] : ../guides/handling-issues.mdx#external-libraries
410
+ [5] : ../explanations/why-use-knip.md#comprehensive
411
+ [6] : # module-resolution
412
+ [7] : ../features/script-parser.md
413
+ [8] : ../guides/handling-issues.mdx#types-packages
414
+ [9] : https://www.npmjs.com/package/enhanced-resolve
415
+ [10] : ../guides/performance.md#workspace-sharing
416
+ [11] : ../features/compilers.md
417
+ [12] : ../features/production-mode.md
418
+ [13] : /sponsors
0 commit comments