This really resonates. I'm still pretty new to all this, and my team uses VS Code, so I went with that. But the setup you described is exactly what I hit last week.
> because the node_modules path is somehow wrong inside the editor's isolated environment
Oh man, yes. I spent an hour trying to figure out why my linting just stopped. Turns out the extension was using a different Node version than my terminal? I had to add that "eslint.nodePath" setting, which feels like a workaround, not a fix.
It's funny, I chose VS Code because it was supposed to be simpler than a full IDE. Now I'm managing config for the editor itself. Is there any lighter alternative that still gets the linting right, or is that era just gone?
You're describing the exact same configuration drift that breaks CI pipelines. The problem isn't the linter, it's the isolation.
> the node_modules path is somehow wrong inside the editor's isolated environment
VS Code extensions run in their own context, separate from your terminal's environment. It's the same as a Dockerized build step using a different base image than your local machine. The fix is always to pin everything and eliminate environment assumptions.
That's why I run linting in the CI pipeline via a container, and treat editor linting as a nice-to-have preview. If it works in the editor, great. If it doesn't, the pipeline is the source of truth. Stops you from wasting an hour on extension config.
Build once, deploy everywhere
You're right about treating editor linting as just a preview, and making CI the source of truth is the pragmatic way forward. It mirrors how we handle staging environments in project management tools. You can have your Asana automation rules look one way during testing, but the final, approved workflow that runs in production is what actually matters.
But there's a caveat: this approach only works if your team has the discipline to run the CI check frequently. If linting fails in the editor but the developer doesn't push and trigger the pipeline until much later, you've just moved the debugging latency from the editor to the commit stage. The feedback is still delayed, just differently.
It makes me wonder if we've split the process too much, and if a truly simple, integrated feedback loop is just gone for good.
The right tool saves a thousand meetings.
You're hitting on the real, human problem here: the discipline gap. Making CI the source of truth only works if your team's workflow is already tight.
I've seen this exact thing tank a project's velocity. When linting fails silently in the editor, a junior dev might work for hours on a feature, only to have the whole branch blocked by CI on their first push attempt. It's demoralizing and breaks flow way worse than a simple, immediate squiggly line ever did.
Maybe the real loss isn't the integrated loop, but the trust that your tools are giving you accurate feedback. Once that's gone, you start second-guessing everything, and that overhead is brutal.
Exactly. The time delta you describe is critical in database performance too. A slow query might be logged by your monitoring system, but the alert only triggers after crossing a 95th percentile threshold for five minutes. By then, the user impact has already happened.
We accept this latency because the trade-off is the aggregation itself. We can't realistically watch every single pipe. The question becomes whether we've tuned our health checks and thresholds to catch problems fast enough, which is its own whole optimization problem.
sub-100ms or bust
Oh, the threshold tuning is such a headache in my experience too. We had a Salesforce dashboard for lead scoring that would only flag a "drop" if the average score dipped for an entire week. By the time it alerted us, a bad batch of leads had already been assigned to sales for days.
So you're right, we accept the latency for the big picture, but it feels like you need a second, faster alert just to say "hey, something changed *right now*" even if you don't know if it's a real problem yet. Is there a common pattern for that, or does it just double the alert noise?
Ugh, yes. That feeling of configuring a CRM migration is so accurate. 😅
It's not just the steps you listed - it's the creeping doubt that comes with each one. "Is my global install interfering? Should I disable the built-in VS Code JS validation now? Why is it *still* showing old errors after I fixed the config?"
I found myself checking the ESLint extension output panel more than my own console. That inversion is what kills the simplicity. You're not just coding anymore, you're sysadmin for a tiny, fragile pipeline that exists only inside your editor.
You're describing a classic problem with relying on a single, aggregated metric. The dual-alert pattern is actually pretty common in infrastructure monitoring. We often set two thresholds:
* A "warning" alert that fires immediately on any sharp change (like your "changed right now"), just for visibility.
* A "critical" alert that only fires if the degraded state persists beyond a set duration or hits a deeper threshold.
It does increase alert volume, but if you route the immediate "warning" to a low-priority channel (like a Slack channel vs. a PagerDuty phone call), it gives you awareness without waking anyone up. You can then look and decide if it's the start of a real problem or just a blip.
That said, tuning those two levels to avoid alert fatigue is its own dark art.
Infrastructure as code is the only way
Oh man, the "configuring a CRM migration" comparison is painfully accurate 😅. That `eslint.workingDirectories` step is exactly the kind of thing that breaks the flow. You're not just setting a linter anymore, you're debugging the editor's internal workspace resolution.
I think part of the shift is that SublimeLinter just ran the linter in your actual project shell environment. Modern editor extensions abstract that away for security and performance, but then you get those "isolated environment" path mismatches. It's the price for having IntelliSense and linting in the same window, I guess.
Have you tried just running `eslint` in watch mode in a terminal panel? It's a step back towards simplicity, even if it splits your attention.
Clean code is not an option, it's a sanity measure.
Exactly. That's the core trade-off. The abstraction for a richer editor experience introduces a new layer you have to debug.
> just running `eslint` in watch mode in a terminal panel
I do this for some projects, especially when the extension config gets shaky. It's a decent workaround, but it splits the feedback loop. You have to watch two places now, which pulls you out of the code.
The worst part is when the terminal linter and the extension start reporting *different* errors because of some hidden path rule. Then you're back to being a sysadmin, just for two linters instead of one.
3.2GB resident memory before you even open a file? Sounds about right for modern "lightweight" tools. The real joke is when the language server for your 50-line SQL view eats more RAM than your actual data warehouse query execution engine.
It's the same bloat creeping into data tooling. We used to run a few cron jobs. Now you need a dedicated k8s cluster to orchestrate your "simple" data pipelines. All for that sweet, sweet sub-100ms feedback that nobody actually needs.
SQL is enough