Dead Code Shouldn’t Exist: How We Removed 28k Lines of Code, One Knip at a Time

I've been to this conference for the last four years, so this is my fifth time at React Summit and Chase Nation. But it's actually the first time that I'm giving a talk in person here. So I'm really happy and excited to talk to you about KNIP and dead code elimination today. My name is Dominik. I'm a software engineer from Vienna. And as you just said, you can also find me as tk.dodo online almost everywhere, mostly on Blue Sky these days. And I also write a blog at tk.dodo.eu, mostly about TypeScript and React.

And of course also about React Query or 10-Stack Query, which is the open source library I've been maintaining for over the last five years. Now, quick question. Raise your hand if you've worked with 10-Stack Query or React Query before. Oh, that is a lot of hands. That's great. Always love to see that. I'm not here to talk about 10-Stack or React Query today, though. I do have some 10-Stack stickers if you want. So you can come to me afterwards and grab those.

And there are also some more talks tomorrow about 10-Stack. But today I want to talk to you about something different because beginning of last year, I joined the design engineering team at Sentry, where we're not working directly on a specific part of the product, but instead our goal is to make ship happen. We want to enable other teams to ship efficiently. And in that sense, our team actually aims to make two things possible. We want to make it easy for product teams to ship the right things efficiently and consistently.

And at the same time, kind of guard them towards not shipping the wrong or inconsistent things and get them into that pit of success per default. And to get there, a big part of our team's job is building a design system, which is a library of consistent components with good APIs and documentation and type safety and accessibility built in. Because those components need to be easily discoverable so that product developers can compose them and ship them fast without breaking things.

And for the second point, we're actively working on constraints. So that means setting up TypeScript and linting, but also project structure and documentation and teaching and also AI skills these days play a big role in that. So in a nutshell, we try to get the overall codebase of Sentry that has kind of grown organically over the last 10 years into a good shape so that both humans and their agents can ship fast. And that means we have to touch a lot of parts of the codebase regularly.

Like, for example, my very first PR at Sentry touched over 900 files because I enabled the no implicit any compiler setting, which I was really surprised that this was not turned on, to be honest. And while I did this and some other improvements, I was sometimes wondering if I should maybe, you know, sanity check the things that I was touching or at least find out where they are used. And sometimes it turns out they weren't used at all.

So when I introduced the ESLint plugin query for checking if the React query hooks are working efficiently, I got a bunch of violations, like in this hook, and I tried to fix them. And after I battled with this for a while, I wanted to find out where it was used. And it turns out it was not used at all in the codebase. So I thought to myself, OK, that's it. No more. This is slowing me down. I'm wasting a lot of time here. I got a clean house because unused code has a real cost. It means that developers will spend time reading and trying to understand it, maybe even refactoring code that shouldn't be there in the first place.

And I think this becomes even more important in the age of AI, where generating extra code is easy, but maintaining it over time is actually hard, and every unused line of code might still consume tokens or bloat the context window of agents. And library upgrades or changing lint rules becomes more painful the more usages we have, because those tools, they don't care if code is used or not. If it exists, it has to be error-free. And it might even increase our bundle size if it's not properly tree-shaken out, for example, if we have side-effectful modules.

So all in all, I think unused code is a pain. It increases cognitive load. And that's why we should care about it. It will slow us down. So how did we end up here? Well, I like to think that engineers are generally responsible beings that like to clean up after themselves, but in truth, we have to be constantly reminded about the most basic forms of cleanup. And I think we are rightfully so driven by errors, because TypeScript gives us a lot of confidence. It takes all of those dependencies that used to be in our head, and it makes them explicit in code.

Like, I can change something in the function when it returns, and it will show me all the impact that it will have. And this is something that was really hard in plain JavaScript without types, especially in larger code bases. And with TypeScript, all of that becomes explicit. Now, that is huge for our productivity and confidence. But we've also come to rely on this a lot.

And it's not just TypeScript. It's also all the linting and testing and all the other guardrails and static analysis that we have set up in our CI pipelines. Because if the thing we're touching does not show up as red somewhere, it usually means that what we're doing is still allowed or considered good practice in this code base. And we likely won't look any further than that. And I think that's plain and simple how that code sticks around. If nobody tells us to remove it, we probably won't do it.

Okay, so you might be thinking, wait a second, doesn't TypeScript catch this, right? There's my good friend, TS6133 something is declared, but its value is never read. We've all seen this when we forget an import or something, right? This is an easy TypeScript error. So doesn't TypeScript catch this? And the answer is yes and no, it depends on the situation.

So let's assume we have this very simple example, a React component called filesize, and it has a util function format bytes. Now, if this is the only place where we use this util function, if we remove the component, then yes, TypeScript will tell us that we can safely remove this function if we have the no unused local flag turned on, which I think it is on per default. But what happens if we change a tiny thing? What happens if we add an export statement in front of format bytes? Well, then TypeScript will not report any errors at all, because TypeScript simply does not do cross-module usage analysis. If something is exported, then TypeScript will just think that it will assume that it's used somewhere else and it will not report any errors on it. And yeah, in this simple scenario, this might not be a problem. But in practice, what usually happens is that those two things tend to drift apart. Like the utils move to a separate file, maybe they become global, they become used somewhere else, and then usages get removed over time. And what happens is that what stays behind is this util function that nobody uses anymore. And I think that's the easiest and most common way to produce that code. And AI also does it all the time when they take one approach and then take another approach and leave a lot of that code behind.

Now good IDs can help with that. For example, IntelliJ creates an index of everything and then they mark these things visually, but it's still up for the developers to act upon that. And I thought, you know, this can't be it. Like surely someone else must have had the same problem and already built a tool for this, right? And it turns out there are actually a couple of tools that try to help with this. There are tools like tsprune or unimported, and they have existed for quite some time. But what they all have in common now is that they're either deprecated or unmaintained and that they recommend KNIP by Lars Kuppert instead. So what is KNIP? Well, KNIP is a comprehensive tool to statically analyze your code for unused files, exports and dependencies, and then report them to you so that you can remove them. It is quite fast. It takes around six seconds in the quite large Sentry codebase. It tries to be zero config, even though in any larger repository, you might need a bit of configuration. And it has a lot of plugins, support for monorepos and is also auto-fixable.

Now that is a good sales pitch, but how does it actually work? So at its core, KNIP needs to know two things. It has to know which files are part of your project. And how complicated that is usually depends on your product structure, but it can be as easy as all your TypeScript files in your source directory. And the second thing is it has to know where the entry points to your application are. And what the entry points are, that drastically varies about which bundle or framework you're using. So for example, if you're using Next.js, then every page.tsx or layout.tsx file in your app directory would have to be one of those entry points. But if you're just using Vite, for example, it might just be your main.tsx file. And once KNIP knows that, it will traverse the project, starting from the entry points to build a graph of those used symbols. And it will then simply report on the things that are in the project, but not in that graph.

So in this example, we have three entry points. It's traversing all the green points, and then we'll find those two red dots and report them to you, because they are part of the project, but not used by any of the entry points. And that's pretty much it.

And it works remarkably well. I think it's best if I show you a little demo now on how it works. So let's go to the demo. Let's just check if this is big enough. Yeah, that looks good. So this is the Sentry codebase. Sentry is open source. The code is on GitHub. You can check it out yourself. But I had to cheat a little bit. I had to go back in time, because we now run KNIP in ZI. And when you do that, we have no unused code anymore. But I went back in time a little bit to a place where we still had unused code. So let's just run KNIP in here and see what it reports.

OK. So KNIP shows us three unused exports, front-end cards, back-end cards, and mobile cards in a file called Vital Cards. So let's go there. And then inside Vital Cards, we can see that my editor shows that this is unused and that there are no usages of this thing. But there's nothing else that reports this, but KNIP does. So let's remove this. And then we'll see there are some more things that show up, because now we have a local that is unused. And now TypeScript would say with the TS6133, that this is also unused. We can continue to remove that. So let's do that. Let's just remove all of that. And then we had the back-end cards. It's the same thing.

Let's just remove that. And then the mobile cards as well. And then let's see. There's some more types that we can remove.

And all of a sudden, there's something else that shows up. There's these generic cards, probably that was used by all of these three. So KNIP just shows us this as well.

And then there's some more. There's always more stuff coming. I was just going to keep moving until all the red stuff is gone. Sparkline chart. That's interesting. We don't need that. More stuff.

So KNIP is just the gift that keeps on giving. It's always more things. This goes. OK. What's this? Go away. More types. We don't need them. Some more stuff. Another function. OK. Is this the last one? It is not. OK. Cool. Well, there you go. Styled components. Bah. I hate them. OK. Cool. Right. Types. OK. There's some more. Yes. I love this. This is oddly satisfying. You know the feeling of removing code? It's great. OK. Now look at all these imports. There's so many imports.

Boom. OK. Perfect. Now all the red stuff is gone. So let's see what we did. Went from 565 to 191 lines of code. So we've almost removed like two-thirds of that file because of these three things that KNIP has shown us initially.

OK. So now we're done, right? We found this file. We've cleaned it up. That's really good. But are we done yet? We've removed all of those imports, right? Just to be sure, let's run KNIP again to see if there's anything else we can remove.

Oh, yeah. Now I chose more stuff. That's great. So let's look at that. We have this sparkline. Apparently, like we had this sparkline chart and this was the only one that used these sparkline things. So now we have this whole directory that we can remove. And even better, we can go to our package.json and remove a dependency like sparkline chart. Actually we haven't needed that for a while, but it was still here and we were still updating it probably. So now that can go away. And then we still have two more things that it found, two utils.

One of them is this one here. And that's especially interesting because it doesn't have zero usages. It only has one usage, but it's in the same file. So we cannot fully remove it. But what we can do is we can remove the export statements. It becomes a local util that can then be properly cleaned up if the last usage really goes away. And then we have this one here, vital card details, another function that can be removed.

Will this bring some more stuff? Yes, it will, obviously. Lots of more imports we can clean up. That's nice. Okay. So now we're done, right? Are we done? I don't know. We have to ask Knip to run it again to see if there's some more things we can remove. All right. That's cool. So now it says Knip found no issues. And this is actually what we want to see. Then we know we're done and we can make a PR and actually can be sure that we've cleaned up everything that we need to.

Okay. So this was great. It was a lot of fun. Reading all this completely unused code. But we thought maybe we can do better. Because sometimes, I don't know, developers do this thing called writing tests. I don't know if you're doing this. Maybe your AI agents are doing it for you these days. AI loves writing tests. So imagine what happens if we have code that is unused in production, but it still has a test. Technically, it's not unused. There is a usage.

But both the usage, the test, and the actual production code can be removed because we don't need it anymore. And in those cases, we not only have to maintain that code, we also run the tests in CI. And if those tests are flaky, we rerun them for no reason all the time. And that is double the pain.

So the real question is, can Knip detect those as well? And the answer is, yes, it can, because it has a dedicated production mode. And in production mode, it only focuses on the code that we actually ship. And for that, Knip must know what is a production entry and which files are part of your production code. And to get there, it has a special syntax.

Now, for an example from before, that would mean that every TSX file in source would now have the exclamation mark at the end because it is production code. And the source main.tsx is the production entry point. And then we might have some extra build scripts in the build directory that are not part of the production code. So those files would then be invisible in that production mode.

So those files would then be invisible in that production mode. And this works really good if your project is nicely structured. In Sentry, it looks more like this. But that's mainly because we don't have a dedicated place to put our test helpers and fixtures. So we have to exclude them with a leading exclamation mark from production mode. So the syntax is a bit weird. It gets a bit more configuration. But it's totally worth setting up. Because there's so many things it can show you that not even IDEs will show you.

Just one example is we had this getIncidentDiscoverUrl function that had tests but no other usage. And we could safely remove it. And at the end of the day, I think it was over two-thirds of all the dead code that we removed that came from production mode, which is basically tests plus the actual code itself. And so I think it's totally worth setting it up to. Now, all in all, I think we were able to remove a lot of that code with Knipp. But there were also some problems. And since this is a real-life story, we have to acknowledge that not everything went perfect in this plan. And there were some problems and limitations that we also ran into.

Probably the biggest one is that it influences how we work. And Sentry has hundreds of developers contributing to the code base regularly. So any change in how we work is potentially disruptive. Because one thing we tend to do is we're going to add code sometimes in PRs that don't have an explicit usage right now because we want to use them in a future PR. Now, of course, if you run Knipp in CI, it cannot differentiate between the two. So one PR I made got closed because I found code that was added six months ago and was still unused. But it turns out this was just deprioritized in the product. And there were still plans to use it. Now, with Knipp running in CI, it just doesn't work out that well to work that way. There are ways to opt out of Knipp, for example, by adding a JS doc comment at public or you can add them to the ignore config of Knipp. And then it will leave those alone. But I think it's probably better to just write code that is used.

But I think it's probably better to just write code that is used. Like PR should probably be isolated units of work. And if we can always hide things behind feature flags if we don't want to show them to customers in an early stage. Because eventually comments like this will prevent the function from being cleaned up correctly when it really becomes unused.

Another thing I've seen is the tendency to just write export in front of everything. I think AI does this. And I don't know if this comes from copy paste or whatever. But whenever we have an exported const or function that is only used within the same file, Knipp will report on that in CI. And then you have to go back and fix it and run CI again. All of this creates kind of like a slow feedback loop, which can be annoying.

To address this, we've created an optional pre-push hook that developers can opt into if they don't want to wait on CI to finish. Knipp now has a language server which powers their MCP server, but also editor integrations for VS Code and for IntelliJ. This allows getting red squiggles right in our code if an exported function is unused, helping with that otherwise slow feedback loop. I also want to point out that we need to be careful in code bases that do a lot of dynamic things. Because I managed to delete some code that I probably shouldn't have because of some things we do with require.context.

So require.context is a Webpack-specific feature that allows you to dynamically search a directory and import multiple files with a regular expression. And then Webpack turns that into some build time require statement. Now, in our cases, we were loading all of the forms that we have. And some of them showed up as unused, so I deleted them. And there was no type error and nothing because all of this is hugely dynamic. The forms were just missing at runtime. So we reverted that and fixed it.

And the fix here was to add this whole directory as an extra entry point to Knipp. But it's just worth pointing out that I don't think this is a great pattern. It doesn't work well for static analysis. Developers also can't find usages of these things. And we are at the moment migrating to a new form system which uses 10-stick form. So hopefully this code will go away soon anyways.

Now all in all, we made over 50 PRs over the course of a couple of weeks. And we could delete almost 3% of the whole sentry code base, which is 28,000 lines of code, which I think is a really big win. But the biggest win we have right now is running Knipp in CI, which prevents new dead code from making it into the code base. Because every once in a while, I find a PR that I review that has a failing CI check where Knipp found something. And then there's another commit coming after that saying make Knipp happy or something. And yeah, that makes me happy as well to see that we're not forced to do all of these cleanups as we go.

So if you want to try out Knipp, it's as easy as running mpx-knipp in your code base. See how far you can get without any configuration and it will likely show you some good stuff. And if you have some false positives, then just go and add some configuration. And then you can declutter your code base to one Knipp at a time. Thank you.

So one thing that I do see here is some questions about automation and auto-merge in CI. So I can just highlight that up on the board, up on that white one. So you were mentioning that you do integrate this into CI. And I see auto-merge as well. So maybe that is some kind of automatically automating the whole PR process, also with maybe some kind of AI review or something like that of the PR, so that things just get removed. And if the tests pass, then it's all good?

What you can do with Knipp is it has a minus minus fix flag. So it is auto-fixable in that sense. If it detects things, it can automatically remove the code for you. We don't do that, not because I don't trust it, mainly because I think it's fun to remove code. So it's kind of like one of the better parts of the job. But also, it is good to look over the things just because there might be false positives. You don't just blindly trust the tool. It's not like a formatter. If there is code that gets removed, it would be good if there's a human in the loop, at least. But it's totally doable. I know people that do it and it's fine.

I think if you don't have dynamic stuff, the worst that can happen is that Knipp removes something and then you get a compile error somewhere and then something else breaks in the pipeline. But technically, it should be totally fine to run Knipp with minus minus fix in CI, like you would do with your formatter, like you would do with ESLint, for example, if you want to do that. Yeah, okay.

And I guess that also does it recursively as well? So if it removes something and then that, by removing that, then also something else becomes removable, then it goes down that path recursively? Because I saw another question here. That is, why does Knipp not show everything to be fixed on the first run? Yeah. I think that's a good question. It only sees the code as it is now. So in order to see how the code would be after it had removed the things, it needs to remove it first and do a rerun. And I don't think it does that automatically.

So when you run it with minus minus fix, you would probably need to run it again until you get zero errors by yourself. Okay. So if you ran fix multiple times, then eventually, it would be clear. You could do a loop in CI. There you go. Yeah. Just add more loops, right? Loops are the solution, I've heard. It's so this week. Yeah, this is the latest thing. Just write loops. Don't need to write any code anymore. Another one is, so I'm not sure if this is related to the output of Webpack. So I see something here. Are bundlers such as Webpack not doing this for chunk generation? So I'm assuming this is the actual output of Webpack and the bundlers. Is this related to what you're talking about mostly? Or are you talking more about source code?

So what bundlers are doing is that they can do, modern bundlers can do tree shaking. So they take all your source modules, bundle them up, put them into separate chunks, and then basically rattle the tree to like everything falls out that's unneeded. And that works mostly for the code that you ship to users, which is why I said that code might increase your bundle size. If a module has a side effect, it will not be tree shaken out. If there's some misconfiguration, or using an older bundler, it might not be tree shaken out. But that is not one of the main reasons.

I think the main reason to not have it is so that you don't have to maintain it. You don't have to update it. And you don't have to like make sure that it always compiles with the latest updates. You don't have dependencies that you update that might get infected, even though you don't use them. Right? Yeah. Supply chain attacks are a real thing. I've heard. So yeah. Yeah, it's a thing. Yeah. Yeah.

So it's, it's not only about getting rid of the code so that your users have a smaller bundle size, but it's also all of those other things. Like not, not having to maintain it and all, just not having it in your code base at all. Exactly. Things that you don't have, you don't have to worry about. And not hoping that your bundler tree shakes them out properly. The best code is no code. Yeah. Exactly. Always has been. Yeah. So another one here is, could it, could Knip be used to clean up other types of things like localization, I18n strings? Like I guess that's a little bit harder because it needs to analyze different types of usage, like also on the string level or something like that. I'm not sure what, do you have any thoughts or experience on that? Yeah. So right now Knip just traverses the AST and it knows about imports and exports.

So right now Knip just traverses the AST and it knows about imports and exports. And I think that's where it stops. But once it has that information, I think it can theoretically go further and do other things as well. Like it could do cycle detection, it could do some other things. It could do find duplicates or complexity and stuff like that. So once you have that, that, that, that graph of imports, you can probably put some more thoughts on top of that. I don't know what the, what the plans are in regards to Knip's future. I will probably talk to Lars about it. There are already some other tools coming up that are going deeper than what Knip is doing. So I think, especially because of the rise of AI, having tools that kind of like put the guardrails around everything, I think those tools are going to become more widely used.

Yeah, totally. I think guardrails in AI usage is a big thing because everyone's like running it autonomously now and it's rampaging through your code base. And you want to have at least some idea that stuff is not going to be breaking too badly. Yeah. Aside from Knip, what other cleanup tools or approaches can you, can you recommend? Like for example, there's this E18E initiative. Maybe some of you have heard of this. Yeah. Is there anything, anything there that you like in that initiative or any other cleanup tools that you would recommend? Yeah. So it's the E18E is the Ecosystem Performance Initiative. And you would have to talk to James. He's here at the conference. And I talked to him before. They have a great ESLint plugin, apparently, that I'm not yet using. So I will be using it. It's the E18E ESLint plugin that can, can help find code dependencies that are out there to think or code snippets that could be, that are not performing, that can be auto-fixed to some other things like that. I'm definitely gonna, gonna, gonna check that out and try it on.

Okay, nice. So you have an ESLint plugin for that as well. Okay, so yeah, that may be something that you want to check out as well. I see something here, can you use Knip in poly repo? So I'm not sure if poly repo is supposed to be like maybe mono repo or something like that.

I'm not sure. Or like, like a repo with multiple packages in it or things like this. And then if there's a follow-up question, if provided as entries, so I'm assuming that then each package would have its own entries or something or. I think I understand the question. So for a mono repo, it's, it's possible to detect between packages. So you can have packages be, have like, they usually have exports defined that they expose stuff for other packages to use. And usually those entry points are not linted or are not checked because they are like consumed by other packages. But you can configure it in a mono repo so that if the last usage in a different package gets removed, you could theoretically also remove it from the source package that has it.

If we're talking about multiple repositories that you have, like for example, if your design system lives in a separate repository and then you have like multiple other repositories that depend on it, I don't think it can go that far because at that point, those things just become another NPM dependency and you're not going to check for the usages in, in all your node modules. Yeah, that's where it gets a little bit tougher, right? Also just because it isn't, it's exported from your design system. It isn't used at the moment doesn't mean that you'd want to remove it because those are kind of like public interfaces that you are cautiously and actively maintaining. So it's not like something that gets left over because you don't want to just unpublish from NPM.

Is there room for TypeScript and ESLint to become more capable to support cross-file analysis so that it can like do these type of optimizations out of the box? Do you think this is kind of like a direction that that stuff is going or is it more like these, these should be standalone tools? I think for TypeScript it's probably a conscious decision that they are not touching things that are exported. It's probably also for, for these tools going to take up a bit of, you know, performance for them to, to, to go into this analysis as well. ESLint, I don't know if they could have done it. I think ESLint specifically is meant for linting each file in isolation. And then there's TypeScript ESLint which kind of like breaks that assumption. There's ESLint import which also breaks that assumption.

Let's see. We have a, we have a few more, a few more minutes here. Is there room for TypeScript and ESLint to become more capable to support cross file analysis so that it can like do these type of optimizations out of the box? Do you think this is kind of like a direction that that stuff is going or is it more like these, these should be standalone tools? I think for TypeScript it's probably a conscious decision that they are not touching things that are exported. It's probably also for, for these tools going to take up a bit of, you know, performance for them to, to, to go into this analysis as well. ESLint, I don't know if they could have done it. I think ESLint specifically is meant for linting each file in isolation. And then there's TypeScript ESLint which kind of like breaks that assumption. There's ESLint import which also breaks that assumption. But that means it's not as easily cacheable as the normal ESLint runs. So there are trade offs to all of that. And probably a lot of things that I don't even know about. So I think that a tool that is tailor made to do one job and that does it very well, I think that's a, that's a good middle ground here.

And another one is that it does it work well with like, I don't know if you have any experience with this, but does it work well with full stack frameworks like Next.js or Remix or, or is there, is there some limitation there? Yeah, it does. What, what Knip does, it has like, I think, 150 plugins. And each of these plugins is tailor made for one of those frameworks or technologies. And then what it does is it kind of like it configures itself with entries and projects because it knows about the, you know, assumptions that these frameworks take, or maybe there are some naming conventions that these frameworks have, that some things are named page.js and then Knip just knows about this because it looks at the package.js and sees, oh, you're using these technologies. So it tries to configure itself accordingly. Yeah. And then, yeah, it, it works really well in those setups as well. Yeah. That, that makes sense. So, yeah, I think that was another, another question that just appeared to me is, can it like auto configure itself for a certain, yeah. So that's. It can, from most of the technologies I've also contributed like one or two of those plugins. If you're using a technology that is not yet well supported, you can obviously configure product entries yourself, but you can also upstream contribute a plugin and then it will get in. And like when, when I made the talk the first time it had like 130 plugins, now it has 150 plugins. So it's kind of like, oh yeah, the number is always rising. So it's very actively maintained. Is 10 stack start also a part of that or? Yes, it is. Yeah.

Sweet. Awesome. Let's see. I think. Maybe one last one here. Let's see. Are there any? Oh yeah. I think we already talked about the cascading, cascading thing. But maybe, maybe something about false negatives. If you specify the entry points incorrectly, then that will lead to false negatives, I guess. Right? Like if you specify something that shouldn't actually be an entry point, then that will be actually dead code that should be removed. For example, you have some file in source or something like that, and this becomes an entry point, then it will not be recognized. That's true.

So if you have a source script directory and you put as an entry point, like script star dot star, whatever, right? All my scripts are entry points. Then obviously if you stop using those scripts, they will not be reported because all the files will be used and will be seen as entry points. The same thing that we have with the forms. We don't actually know which form is used or not because it's just like all the directories are just an entry point. So yeah, I would try to have Knib be configured automatically with the plugins. Of course. And then try to be as narrow as possible when you overwrite some of those things. Not include like very broad glob patterns because they might include things as entry points that you don't actually want. Yeah. And that will prevent further cleanups. Yeah. Yeah. Okay. Great. Well, yeah. Put your hands together for Dominic again. Yeah. Thank you.