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.