Knip | Blog

Announcing Knip v6

Fri, 20 Mar 2026 00:00:00 GMT

Knip v6 is out!

This release is all about replacing the TypeScript backend entirely with oxc-parser and oxc-resolver, and making Knip a whole lot faster!

From TypeScript to oxc

Two years ago, the “slim down to speed up” and Knip v4 work removed a lot of overhead around TypeScript programs, made serialization and caching practical, and improved memory efficiency a lot. But there was still a ceiling: parsing and module resolution still depended on TypeScript APIs designed for IDEs and language servers — not for the kind of single-pass static analysis Knip does.

Starting today, Knip v6 parses your source files with oxc-parser. This is more than just a parser swap for the sake of using the latest ’n greatest.

Knip has always been designed to parse each file only once, but the TypeScript backend carried the overhead of wiring up an entire program along with the typechecker. That’s useful for IDEs keeping symbols connected, but much less so when you only need to traverse an AST once to collect imports and exports. The TypeScript backend made the setup as a whole harder and slower than it needed to be, especially to keep large monorepos in check.

Now with TypeScript itself Go-ing places, replacing that backend was only a matter of time.

Unsurprisingly, the search didn’t take long: oxc-parser offers everything we need and its (experimental) raw transfer is crazy fast. Massive props to overlookmotel, Boshen and all contributors for all the work on the oxc suite!

Performance tuning

Next to this major refactor, I’ve been having a ball tuning Knip’s performance further. One thing to highlight here is that a few more plugins have been refactored to statically analyze configuration files directly, as opposed to actually importing them (including transitive dependencies…). This includes the ESLint (“flat config”), tsdown and tsup plugins.

The numbers

Comparing v5 and v6 in some projects using Knip, all boosts are in the 2-4x range:

Trust me, I could look at this chart all day long! The same numbers in a table:

Project	v5.88.0	v6.0.0
astro	4.0s	2.0s
query	3.8s	1.7s
rolldown	3.7s	1.7s
sentry	11.0s	4.0s
TypeScript	3.7s	0.9s

What’s new

Did I already mention Knip got 2-4x faster?
Support for TS namespaces (and modules), new issue type namespaceMembers:

export namespace MyNamespace {
  export const myName = 'knip'; // we were ignored in v5,
  export type MyType = string; // yet in v6 we are included
}

Breaking changes

Granted, most of you won’t even notice. Here’s the list:

Dropped support for Node.js v18 → Knip v6 requires Node.js v20.19.0 or newer
Dropped issue type classMembers
Dropped --include-libs → this is now the default and only behavior
Dropped --isolate-workspaces → this is now the default and only behavior
Dropped --experimental-tags → use --tags
In reporter functions, issues.files is consistent with other issue shapes. Removed issues._files.
In the JSON reporter, issues are consistently arrays for any issue type. Removed root files.

Editor Extensions

Editor extensions benefit from the core upgrades, for being faster and more memory-efficient. Regardless of new extension releases, the local version of Knip will be detected and used. Upgrade knip in your dependencies when you’re ready.

What about classMembers?

I feel you. Even Knip itself was using it. Until today.

The problem is that the implementation relies on the JS-based ts.LanguageService API that exposes the findReferences method. TypeScript v6 is the last JS-based release, and TypeScript v7 is a full rewrite in Go. I am left wondering if it ever will be feasible and practical to build such features using primitives (i.e. not via LSP) in a JS-based CLI (references: microsoft/typescript-go#455, @typescript/api). Knip was already pretty unique for even trying this in a CLI tool.

Not that many projects seem to be using it either: github.com search for “classMembers path:knip.json”.

If your project relies on it, feel free to open an issue on GitHub or contact me and maybe we can work something out. Maybe a separate dedicated tool could work, or extended support for Knip v5.

Upgrade today

npm install -D knip@latest

Deep closing thoughts…

Remember, Knip it before you ship it! Have a great day ☀️

Knip for Editors & Agents

Wed, 17 Dec 2025 00:00:00 GMT

Three years in, Knip has found its place in over 10.000 projects and is downloaded over 18M times/month. A long period of steady growth in usage and stability allows Knip to become more accessible to more people. That’s why I’m excited and proud to introduce the brand new Editor Extension and MCP Server. For humans and coding agents alike, Knip will help keep your codebases tidy.

Don’t forget… Knip it before you ship it!

Editor Extension

This one is for you.

The usual suspects like red squiggles for unused exports are there. What really moves the needle for DX with Knip’s module graph is navigation. A completely unique way to view & fly through codebases. Connect the dots during development and refactors, while keeping things in check. We’re starting out with 3 key features:

Hover over Export for import & usage locations
Imports Tree View for direct links to implementations
Exports Tree View for direct links to import & usage locations

The extension has a built-in MCP Server with a command and resources to configure Knip for you, completely automated.

Find Knip on the VS Code Marketplace and find Knip in the Open VSX Registry.

MCP Server

Configuring Knip has always been a major headache to many. No more. Tell your coding agent to “configure knip” and it will RTFM so you don’t have to. Using a newer model like Opus 4.5 or GPT 5.2 results in an optimized knip.json file and an uncluttered codebase.

The MCP Server is available separately and built into the VS Code Extension.

Language Server

The VS Code Extension and the MCP Server are powered by the new Language Server. It’s a custom server that builds the full module graph of your project, and provides a session with a graph explorer to request all sorts of interesting information. Queries like “where is an export imported” or “is this import part of a circular dependency” are just scratching the surface here.

Extensions for other IDEs can be built on top. See language-server/README.md

Lint Findings

Imports & Exports

Contention

The IDE extension shows extra issues in the tree views like circular dependencies. We’re starting out with some extra novelties like conflicting and branched/diamond-shaped import chains.

Circular Dependencies

If an import is part of a circular dependency, Knip will display:

Conflicts

TypeScript shows direct conflicts when importing or re-exporting the same named export from different files. Except when the problem is more subtle and the chain spans more than one file. Knip warns:

Branching

Branched or diamond-shaped imports chains indicate unnecessary re-exports and complexity. They help to untangle large codebases and shrink or get rid of barrel files. Knip warns:

VS Code Extension Settings

The State of Knip

Fri, 28 Feb 2025 00:00:00 GMT

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 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 and plugins first).

Case 1: Next.js

Let’s say this default configuration represents, greatly simplified, the default entry patterns for projects using Next.js:

{
  "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:

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:

next.config.ts

const nextConfig = {
  pageExtensions: ['page.tsx'],
  env: {
    BASE_URL: process.env.BASE_URL.toLowerCase(),
  },
};

export default nextConfig;

$ 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 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:

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:

.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 and a script parser, and other affordances such as auto-fix.

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! ✂️

Two Years

Fri, 04 Oct 2024 00:00:00 GMT

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! 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:

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! 🟩 🟥 🟥 🟥 🟥

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 for you while we’re at it:

The auto-fix feature 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, 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:

And so many more on and off the radar. Very, very cool!

Acknowledgements

Thanks to Joshua Goldberg for emoji-blast! 🎉

Announcing Knip v5

Sat, 10 Feb 2024 00:00:00 GMT

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:

knip.js

export const version = 'v5';
export const getRocket = () => '🚀';

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:

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:

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:

knip --include nsExports

Or in your configuration file:

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:

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:

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:

knip.js

export const version = 'v5';
/** @launch */
export const getRocket = () => '🚀';

And then exclude the tag like so:

$ 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, 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, other reporter output, or custom preprocessing. 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!

npm install -D knip

pnpm add -D knip

bun add -D knip

yarn add -D knip

Remember, Knip it before you ship it! Have a great day ☀️

Announcing Knip v4

Tue, 16 Jan 2024 00:00:00 GMT

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 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 (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!

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:

knip --include classMembers

{
  "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!

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:

/** @custom */
export const myExport = 1;

Then, include or exclude such tagged exports from the report like so:

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.

Let’s Go!

What are you waiting for? Start using Knip v4 today!

npm install -D knip

pnpm add -D knip

bun add -D knip

yarn add -D knip

Remember, Knip it before you ship it! Have a great day ☀️

Slim down to speed up

Thu, 14 Dec 2023 00:00:00 GMT

tl;dr; Memory usage is up to 50% lower, runs are up to 60% faster and you can start using v4 canary today. No “unused class members” for the time being, but this feature is planned to be restored.

Introduction

Honestly, performance has always been a challenge for Knip. A longstanding bottleneck has finally been eliminated and Knip is going to be a lot faster. Skip straight to the bottom to install v4 canary and try it out! Or grab yourself a nice drink and read on if you’re interested in where we are coming from, and where we are heading.

Projects & Workspaces

From the start, Knip has relied on TypeScript for its robust parser for JavaScript and TypeScript files. And on lots of machinery important to Knip, like module resolution and accurately finding references to exported values. Parts of it can be customized, such as the (virtual) file system and the module resolver.

In TypeScript terms, a “project” is like a workspace in a monorepo. Same as each workspace has a package.json, each project has a tsconfig.json. The ts.createProgram() method is used to create a program based on a tsconfig.json and the machinery starts to read and parse source code files, resolve modules, and so on.

Up until v2, when Knip wanted to find unused things in a monorepo, all programs for all workspaces were loaded into memory. Workspaces often depend on each other, so Knip couldn’t load one project, analyze it and dispose it. This way, connections across workspaces would be lost.

Shared Workspaces

Knip v2 said goodbye to this approach and implemented its own TypeScript backend (after using ts-morph for this). Based on the compatibility of compilerOptions, workspaces were merged into shared programs whenever possible. Having less programs in memory led to significant performance improvements. Yet ultimately it was still a stopgap, since everything was still kept in memory for the duration of the process.

“Why does everything need to stay in memory?”, you may wonder. The answer is that Knip uses findReferences at the end of the process. Knip relied on this TypeScript Language Server method for everything that’s not easy to find. More about that later in the story of findReferences

Serialization

Fortunately, everything that’s imported and exported from source files (including things like members of namespaces and enums) can be found relatively easily during AST traversal. This way, references to exports don’t have to be “traced back” later on.

It’s mostly class members that are harder to find due to their dynamic nature. Without these, all information can be serialized for storage and retrieval (in memory or on disk). Slimming down by taking class members out of the equation simplifies things a lot and paves the way for all sorts of improvements.

We Have To Slim Down

The relevant part in the linting process can be summarized in 5 steps:

Collect entry files and feed them to TypeScript
Read files, resolve modules, and create ASTs
Traverse ASTs and collect imports & exports
Match exports against imports to determine what’s unused
Find references to hard-to-find exported values and members

If we would hold on to reporting unused class members, then especially steps 2 and 5 are hard to decouple. The program and the language service containing the source files used to eventually trace back references can’t really be decoupled. So class members had to go. Sometimes you have to slim down to keep moving. One step back, two steps forward.

If you rely on this feature, fear not. I plan to bring it back before the final v4, but possibly behind a flag.

What’s In Store?

So with this out of the way, everything becomes a lot clearer and we can finally really start thinking about significant memory and performance improvements. So what’s in store here? A lot!

We no longer need to keep everything in memory, so workspaces are read and disposed in isolation, one at a time. Memory usage will be spread out more even. This does not make it faster, but reducing “out of memory” issues is definitely a Good Thing™️ in my book.
Knip could recover from unexpected exits and continue from the last completed workspace.
The imports and exports are in a format that can be serialized for storage and retrieval. This opens up interesting opportunities, such as local caching on disk, skipping work in subsequent runs, remote caching, and so on.
Handling workspaces in isolation and serialization result in parallelization becoming a possibility. This becomes essential, as module resolution and AST creation and traversal are now the slowest parts of the process and are not easy to optimize significantly (unless perhaps switching to e.g Rust).
No longer relying on findReferences speeds up the export/import matching part part significantly. So far I’ve seen improvements of up to 60% on total runtime, and my guess is that some larger codebases may profit even more.
The serialization format is still being explored and there is no caching yet, but having the steps more decoupled is another Good Thing™️ that future me should be happy about.

Back It Up, Please

I heard you. Here’s some example data. You can get it directly from Knip using the --performance flag when running it on any codebase. Below we have some data after linting the Remix monorepo.

Knip v3

$ knip --performance

Name                           size  min     max      median   sum
-----------------------------  ----  ------  -------  -------  -------
findReferences                  223    0.55  2252.35     8.46  5826.95
createProgram                     2   50.78  1959.92  1005.35  2010.70
getTypeChecker                    2    5.04   667.45   336.24   672.48
getImportsAndExports            396    0.00     7.19     0.11   104.46

Total running time: 9.7s (mem: 1487.39MB)

Knip v4

$ knip --performance

...

Name                           size  min     max      median   sum
-----------------------------  ----  ------  -------  -------  -------
createProgram                     2   54.36  2138.45  1096.40  2192.81
getTypeChecker                    2    7.40   664.83   336.12   672.23
getImportsAndExports            396    0.00    36.36     0.16   224.37
getSymbolAtLocation            2915    0.00    29.71     0.00    65.63

Total running time: 4.3s (mem: 729.67MB)

Takeaways

The main takeaways here:

In v3,findReferences is where Knip potentially spends most of its time
In v4, total running time is down over 50%
In v4, memory usage is down 50% (calculated using process.memoryUsage().heapUsage)
In v4, getImportsAndExports is more comprehensive to compensate for the absence of findReferences - more on that below

Remember, unused class members are no longer reported by default in v4.

The story of `findReferences`

Did I mention Knip uses findReferences…? Knip relied on it for everything that’s not easy to find. Here’s an example of an export/import match that is easy to find:

import.ts

import { MyThing } from './thing.ts';

export.ts

export const MyThing = 'cool';

In v2 and v3, Knip collects many of such easy patterns. Other patterns are harder to find with static analysis. This is especially true for class members. Let’s take a look at the next example:

MyClass.ts

class MyClass {
  constructor() {
    this.method();
  }
  method() {}
  do() {}
}

export const OtherName = MyClass;

instance.ts

import * as MyNamespace from './MyClass.ts';

const { OtherName } = MyNamespace;

const instance = new OtherName();

instance.do();

Without a call or new expression to instantiate OtherName, its method member would not be used (since the constructor would not be executed). To figure this out using static analysis goes a long way. Through export declarations, import declarations, aliases, initializers, call expressions… the list goes on and on. Yet all this magic is exactly what happens when you use “Find all references” or “Go to definition” in VS Code.

Knip used findReferences extensively, but it’s what makes a part of Knip rather slow. TypeScript needs to wire things up (through ts.createLanguageService and program.getTypeChecker) before it can use this, and then it tries hard to find all references to anything you throw at it. It does this very well, but the more class members, enum members and namespaced imports your codebase has, the longer it inevitably takes to complete the process.

Besides letting go of class members, a slightly more comprehensive AST traversal is required to compensate for the absence of findReferences (it’s the getImportsAndExports function in the metrics above). I’d like to give you an idea of what “more comprehensive” means here.

In the following example, referencedExport was stored as export from namespace.ts, but it was not imported directly as such:

namespace.ts

export const referencedExport = () => {};

index.ts

import * as NS from './namespace.ts';

NS.referencedExport();

Previously, Knip used findReferences() to “trace back” the usage of the exported referencedExport.

The gist of the optimization is to pre-determine all imports and exports. During AST traversal of index.ts , Knip sees that referencedExport is attached to the imported NS namespace, and stores that as an imported identifier of namespace.ts. When matching exports against imports, this lookup comes at no extra cost. Additionally, this can be stored as strings, so it can be serialized too. And that means it can be cached.

Knip already did this for trivial cases as shown in the first example of this article. This has now been extended to cover more patterns. This is also what needs to be tested more extensively before v4 can be released. Its own test suite and the projects in the integration tests are already covered so we’re well on our way.

For the record, findReferences is an absolute gem of functionality provided by TypeScript. Knip is still backed by TypeScript, and tries to speed things up by shaking things off. In the end it’s all about trade-offs.

Let’s Go!

You can start using Knip v4 today, feel free to try it out! You might find a false positive that wasn’t there in v3, please report this.

npm install -D knip@canary

Remember, Knip it before you ship it! Have a great day ☀️

A Brief History Of Knip

Sun, 15 Oct 2023 00:00:00 GMT

If you are fond of short lists and brief histories, then this page was written just for you!

2022-10-04: The initial commit. 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.
2022-11-22: Unused dependencies and support for workspaces and plugins in the first alpha of v1.
2023-01-10: Lots of testing and fixes led to Knip v1.
2023-03-22: Knip v2 saw a full rewrite of the TypeScript backend.
2023-10-15: Introduction of Knip v3.

Announcing Knip v3

Sun, 15 Oct 2023 00:00:00 GMT

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!

Today, Knip has over 140k weekly downloads on npm, almost 4000 stars on GitHub, and over 500 repositories 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)
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
Production mode now includes types by default (add --exclude types for previous behavior)
Removed --ignore-internal flag; @internal exports ignored in production mode now
The --debug-file-filter flag is removed
The jsonExt reporter is now the default JSON reporter (the previous one is gone)
Moved typescript to peerDependencies (requires >=5.0.4)

Installation

Try out the latest Knip v3 release today!

npm install -D knip

pnpm add -D knip

bun add -D knip

yarn add -D knip

Remember, Knip it before you ship it! Have a great day ☀️

Announcing Knip v2

Wed, 22 Mar 2023 00:00:00 GMT

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 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.

Announcing Knip v1

Wed, 04 Jan 2023 00:00:00 GMT

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).
Workspaces have been moved from the root of the config to the workspaces key (see workspaces).
The --dir argument has been renamed to --workspace.

Example

A configuration like this in v0.13.3 or before…

{
  "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…

{
  "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:

{
  "entry": "src/index.ts!",
  "project": "src/**/*.ts!",
  "cypress": {
    "entry": "src/**/*.e2e.ts"
  }
}

Knip | Blog

Announcing Knip v6

Knip v6 is out!

From TypeScript to oxc

Performance tuning

The numbers

What’s new

Breaking changes

Editor Extensions

What about classMembers?

Upgrade today

Deep closing thoughts…

Knip for Editors & Agents

Editor Extension

MCP Server

Language Server

Screenshots

Lint Findings

Imports & Exports

Contention

Circular Dependencies

Conflicts

Branching

VS Code Extension Settings

The State of Knip

Two Cases

Case 1: Next.js

Case 2: Knip does that?!

Comprehensive

The End

Two Years

Smiling faces

Updates

Stable

Projects using Knip

Sponsors

Acknowledgements

Announcing Knip v5

Case 1

Case 2

Include unused exports in namespaces

Handling exports in namespaced imports

1. Use named imports

2. Standardized JSDoc tags

3. Arbitrary JSDoc tags

A better default

Let’s Go!

Announcing Knip v4

Highlights

Major Changes

Unused Class Members

Compilers

Ignore Files

What’s Next?

One More Thing…

Let’s Go!

Slim down to speed up

Introduction

Projects & Workspaces

Shared Workspaces

Serialization

We Have To Slim Down

What’s In Store?

Back It Up, Please

Knip v3

Knip v4

Takeaways

The story of findReferences

Let’s Go!

A Brief History Of Knip

Announcing Knip v3

So… What’s Been Cooking Lately?

Breaking Changes

Installation

Announcing Knip v2

Breaking changes

Changes

New features

Other improvements

Announcing Knip v1

The story of `findReferences`