Introducing minlsp

Bradley Nash — Sat, 28 Mar 2026 06:32:23 +0000

I’ve heard so many Nim devs complain about LSP servers being slow, pinning the CPU at 100%, or just getting stuck.

The reason behind this is usually the same: the server has to build a massive graph of the entire project, including the standard library, project source, and all dependencies. This gets even worse when it encounters macro-heavy code.

I first ran into this a while back when I was working on a PR for nimlsp. I found the project used macros and templates heavily, and the LSP just struggled—interestingly, the lsp server itself crashed many times in vscode, the moment I converted those to general procs, it worked fine.

After hearing the same frustrations pop up in Discord again recently, I decided to polish up an unfinished project I had sitting around. After a solid "vibe coding" session this morning, I’m ready to share minlsp.

What is minlsp?

minlsp provides IDE-like features for Nim code by leveraging ctags for fast and accurate symbol indexing. Unlike traditional LSP servers that require complex AST analysis, I built minlsp to use a tag-based approach for quick symbol lookup and navigation.

By using ntagger to extract symbols directly, I’ve created a server that prioritizes speed and low memory overhead without sacrificing the features we use most.

Key Features:

Lightning Fast: Symbol identification and navigation are nearly instant.
Low Resource Footprint: It stays out of your way and won't spin up your fans just because you opened a file.
Essential IDE Support: Includes Code Completion, Hover Info, Go to Definition, Find References, Signature Help, and Document Symbols.
Macro-Resilient: It doesn't get "stuck" on complex macros or templates because it doesn't need to expand them to find symbols.

Limitations & Trade-offs

To keep minlsp lightweight, I’ve made some intentional design choices:

No Semantic Analysis: It doesn't perform type-checking or real-time error reporting (diagnostics).
Scoped References: "Find References" currently searches through open files rather than the full workspace.
No Refactoring: Features like "Rename" or automatic code formatting are not currently supported.

Choosing the Right Tool

If you need full-scale compiler integration and deep refactoring, nimlangserver remains the standard. But if you want a responsive, "no-lag" workflow—especially in massive codebases or macro-dense projects where other servers choke—minlsp offers a snappier, more stable alternative.

The project is under active development. If you’ve been frustrated by LSP lag, I’d love for you to give it a try.

Resources & Links

My Project: minlsp on GitHub
The Engine: ntagger
Inspiration: nimlsp Project
Official Tooling: nimlangserver

How npm, pnpm, and yarn Ate 40GB of My 256GB SSD

Bradley Nash — Fri, 27 Mar 2026 19:39:43 +0000

Last week my MacBook started complaining: "Your disk is almost full."

I had 8GB free. On a 256GB machine. I hadn't downloaded any movies or photos. What was going on?

The Investigation

I started hunting. First suspect: node_modules.

find ~ -name "node_modules" -type d -exec du -sh {} \; 2>/dev/null

The results made me want to cry:

~/projects/2022-client-work/node_modules              1.2GB
~/projects/abandoned-react-app/node_modules          890MB
~/projects/experiment-three-js/node_modules          750MB
~/projects/old-work-project/node_modules             1.8GB
~/projects/that-one-tutorial/node_modules            420MB
# ...20 more entries

25GB of node_modules from projects I hadn't touched in months. Some were from 2022.

Then I checked the package manager caches:

npm cache verify    # 3.2GB
pnpm store prune    # Would free 5GB
yarn cache clean    # 2.1GB

Another 10GB just sitting in package manager caches.

In total: 40GB of JavaScript build artifacts and caches. On a 256GB SSD, that's 15% of my entire disk — gone to a dependency graveyard.

The Three Package Managers Problem

If you work with JavaScript/TypeScript, you know this pain. You try npm. Then pnpm for speed. Then yarn for work. Each one maintains its own cache in a different location:

~/.npm — npm's cache
~/Library/pnpm — pnpm's store
~/Library/Caches/Yarn — yarn's cache

Plus every project has its own node_modules. You npm install once, build, deploy... and that folder sits there forever. Multiply by 20+ projects over 3 years.

I found a React project from 2022 with 1.8GB of node_modules. I had run npm install exactly once, built the project, and never touched it again. That 1.8GB sat on my SSD for 3 years.

Xcode Wasn't Innocent Either

While I was at it, I checked Xcode's cache:

du -sh ~/Library/Developer/Xcode/DerivedData
# 47GB

So my actual breakdown was:

node_modules: 25GB
npm/pnpm/yarn caches: 10GB
Xcode DerivedData: 47GB
Docker images: 8GB
Rust/Python/Go build artifacts: 5GB

95GB of dev cache on a 256GB machine. My actual code? Under 3GB.

The Manual Cleanup (Don't Do This)

I spent a Saturday manually cleaning:

# Delete old node_modules... carefully
rm -rf ~/projects/2022-*/node_modules

# Clean package manager caches
npm cache clean --force
pnpm store prune
yarn cache clean

# Wait, where does pnpm store things again?
# And did I just break something?

It took 3 hours. I was paranoid about deleting the wrong thing. And I knew I'd have to do it again in 6 months.

Building DevCleaner

I wanted a tool that would:

Find everything automatically — node_modules, npm cache, pnpm store, yarn cache, and 40+ other dev tools
Show me before deleting — no surprises, no "oops I deleted the wrong folder"
Move to Trash first — so I can verify nothing broke before emptying
Be fast — scan my entire disk in seconds, not hours

So I built it. In Nim, because I wanted to learn something new and ship something fast.

The Results

First scan: 63GB of cleanable cache.

I reviewed the list — all old projects, all safe to delete. Clicked "Clean All", everything moved to Trash. Verified my current projects still worked. Emptied Trash.

63GB back. My 256GB MacBook finally had breathing room again.

See it in action:

go.screenpal.com

Try It

If you're a JavaScript/TypeScript developer on macOS, I guarantee you have gigabytes of node_modules folders from abandoned projects. That npm package cache? Still growing.

DevCleaner finds and cleans:

✅ node_modules (npm/yarn/pnpm)
✅ npm cache, pnpm store, yarn cache
✅ 40+ other dev tools (Xcode, Docker, Rust, Python, etc.)

$4.99 while I gather feedback: https://bradleynash.gumroad.com/l/devcleaner

One-time purchase. No subscriptions. Lifetime updates.

How much dev cache is hiding on your machine? Run this and find your node_modules graveyard:

find ~ -name "node_modules" -type d -exec du -sh {} \; 2>/dev/null | sort -hr | head -20

What's your biggest offender?

DEV Community: Bradley Nash