The release of npkill v1.0 is just around the corner, and with it come new decisions that could mark a turning point for the project.
This update will likely be one of the most important so far, as the main change is that the core will be exposed as a public API, opening up tons of possibilities—including a web version of the tool.
However, there’s an even more ambitious idea that’s been on my mind. One that raises a series of dilemmas that could elevate the project to the next level… or become a legendary blunder.
The Origin and the Need
Npkill was born out of a very specific and personal need: searching for and deleting node_modules. Nothing more. Such a simple premise that if someone had told me it would have such a big impact on the ecosystem today, I would have laughed.
The Impact of npkill Across Development Ecosystems
Over time, we saw the project gaining traction in other areas. Although npkill was clearly aimed at the Node ecosystem, other tools soon appeared based on the same idea but for different environments. Killposer, Decomposer (PHP), and npkill-rs (Rust) are three great examples of utilities well adapted to their ecosystems. This is, of course, fantastic and shows that there’s a common pain point, no matter the tech stack. Turns out the node_modules meme isn’t so exclusive after all.
The Golden Cage of Identity
What really makes npkill shine is its search engine and interactivity. And it feels like a shame that despite the efforts of so many contributors, its main use is still mostly limited to node_modules.
The Problem of Specialization
Yes, the -t --target option has been around for a while, allowing users to specify any directory as a target. But honestly, it’s not as convenient or intuitive—especially for users unfamiliar with all the options available, many of which aren’t exactly essential. But hey! You can change the cursor color! (--color)
Profiles for Everyone
So, an idea came to mind: What if npkill could be useful for any developer out-of-the-box, regardless of their language or platform?
The idea is to expand the native scope—not just be the go-to tool for Node devs cleaning up node_modules, but also the tool for any developer. How? By adding predefined profiles.
These profiles could be selected when launching the program via --profiles, or through a sub-menu in the TUI, with options like python, java, rust, go, or of course, node. Each profile would set a preset of common targets for that ecosystem. This would (I believe) significantly reduce friction for users. For web/node devs, it could also look beyond node_modules to cache-heavy folders like .angular, .next, or .nx.
Here’s an example of what a few profiles might look like:
- Python
__pycache__.venvenv
- Java
build.gradle.mvn
- Dotnet
binobj
- Unity
LibraryTempBuild
Of course, if this goes forward, we’ll need to carefully decide what folders belong in each profile to avoid accidentally deleting non-junk files.
Identity vs. Evolution
Good idea? I personally think so. But there’s something I care deeply about: npkill’s personality.
It would no longer be:
Easily find and remove old and heavy
node_modulesfolders ✨
It would be something like:
Easily find and remove old and heavy unnecessary artifact folders ✨
This project has always been, above all, a tool for dealing with node_modules. That’s its essence. Its reason for existing. So to what extent would we be diluting its core value? Would it be enough to keep everything as-is by default, and just mention the new possibilities in the documentation… for the brave souls who actually read it?
The imminent arrival of the first major release makes now the right time to introduce meaningful changes. And while “now or never” might sound a bit dramatic, some decisions, if not made at the right time, end up lingering forever.
What do you think? Should we expand npkill and explore new frontiers, or stay true to its origins? Your feedback means a lot to me. You can join the discussion or reach out via social media (links in the footer).