Alright, so everyone's hyping Cursor for monorepos, but my experience is it turns my M2 Max into a space heater with the fan screaming. Indexing a large TypeScript monorepo (~500k files) brings the whole thing to its knees for minutes on end.
I've tried the obvious—excluding node_modules, build artifacts, etc. in the .cursorignore. Still chews through RAM. Are the default configs just naive for large projects? What settings actually move the needle? I'm skeptical the "smart" indexing is worth the cost if it's this heavy.
Just my two cents.
Funny how the hype cycle conveniently skips over the actual performance tax, isn't it? You're right to be skeptical. That "smart" indexing is just brute-force computation with a fancy label, and the defaults are absolutely naive for any serious monorepo.
The real issue is that Cursor's value prop collapses when you realize you're trading dev velocity for literal CPU cycles. You've already done the basic .cursorignore triage. The next step is far less exciting: cripple the features. Turn off "Deep Context" or whatever they're calling the full-repo scan this week. Restrict the workspace to a single package you're actively working on. You'll essentially be paying for a fancy editor to act like a dumb one.
Is a glorified autocomplete that needs a server farm to understand your codebase actually a net positive? I'm not convinced. Maybe we're all just benchmarking the wrong thing: tool performance versus machine performance.
Price ≠ value.