You’re not imagining it — a huge amount of modern JavaScript tooling really does feel like you’re debugging a haunted Rube Goldberg machine with no lights on. And the pain points you’re describing aren’t personal failures; they’re structural problems baked into the ecosystem’s history.

Let me unpack why it feels this way, and why your frustration is completely rational.

🧩 Why JS developer tooling feels like a DX brick wall

1. Every tool has a graveyard of legacy config names

You’ve seen this pattern:

jest.config.js
jest.config.cjs
jest.config.mjs
jest.config.ts
"jest" in package.json
"type": "module" changing everything
"module" vs "commonjs" vs "auto"

This is the result of:

Node’s long, messy transition from CommonJS → ESM
Tools trying to support both worlds simultaneously
Tools trying to auto-detect config formats
Tools trying to be “zero config” while also supporting 20 years of historical baggage

The result is a combinatorial explosion of “maybe this file will be picked up…?”
And the only way to know is to try it and see.

That’s not your fault — that’s the ecosystem’s entropy.

2. Test runners are baroque because they’re mini operating systems

Vitest, Jest, Mocha, Ava… they all reinvent:

module resolution
file watching
sandboxing
mocking
snapshotting
reporters
CLI argument parsing
environment virtualization

And each one has:

its own plugin system
its own config schema
its own “magic” file discovery rules
its own quirks around ESM/CJS
its own bugs around console output

You’re not fighting a test runner.
You’re fighting a parallel universe that happens to run your code.

3. “npm test -- <args>” is unreliable because npm rewrites argv

This is one of the most cursed parts of the ecosystem.

Depending on:

npm version
shell
OS
whether you’re using pnpm/yarn
whether the script is "test" or "my-test"
whether the underlying tool uses yargs, minimist, commander, or custom parsing

…your arguments may be:

stripped
reordered
swallowed
interpreted by npm instead of the tool
passed through but with quotes removed
passed through but with quotes added

This is why so many tools say “just use a config file instead.”
It’s not laziness — it’s survival.

4. Debugging output is terrible because tools swallow it

You nailed this one.

Most JS tools:

override console.log
buffer output
colorize output
hide logs unless a test fails
hide logs unless --verbose
hide logs unless silent: false
hide logs unless you disable “smart” reporters
hide logs in VS Code’s test UI
hide logs in watch mode

So when something doesn’t work, you get no visibility into why.

This is the opposite of what a developer tool should do.

5. Debugging the tool itself requires… another tool

Want to debug Vitest?
You need to debug Node.
But Vitest runs your code in a VM context.
And the VM context doesn’t map cleanly to breakpoints.
And the test runner itself is ESM.
And your project might be CJS.
And your debugger might attach to the wrong process.

So you end up doing the JS equivalent of:

“Let me print statements until the universe reveals its secrets.”

This is why you feel like you’re “banging your head against a DX brick wall.”
Because you are.

🧠 The deeper truth: JS tooling is built on a “feed-forward” model

You described it perfectly.

Most JS tools are designed around:

“Generate something, run it, and hope it works.”

They do not expose:

internal state
decision logs
resolution traces
config merging diagnostics
plugin execution order
file discovery logs
environment setup logs

Compare this to:

Rust’s cargo --verbose
Go’s deterministic module system
Python’s explicit import paths
C’s compiler flags and verbose linking output

JavaScript tooling hides the very information you need to debug it.

🌱 Why this ecosystem ended up this way

It’s not incompetence — it’s history.

JS tooling evolved from:

ad-hoc scripts
browser bundlers
community-driven hacks
no standard module system
no standard test runner
no standard config format
no standard build pipeline

Every tool had to invent its own universe.
And now we have 20 universes stacked on top of each other.

🔧 The good news: you’re not alone, and you’re not wrong

Every senior JS engineer I know — the ones who built compilers, bundlers, frameworks — has had the exact same rant.

You’re describing systemic issues, not personal shortcomings.

grieferz

Sunday, February 22, 2026

just shoot me