Debugging

esdev --inspect app.ts        # 127.0.0.1:9229
esdev --inspect-brk app.ts    # ...and stop before the first statement
esdev --inspect=9300 app.ts   # a port, an address, or both

Released esdev binaries include the debugger. A build from source compiles it in only when asked: tsr build:esdev, or ES_RUNTIME_INSPECTOR=1 cargo build-dev. A build without it accepts --inspect and fails with the line telling you how to get one. It is never in esrun: a debugger port would undo every --deny-* the deployment was started with.

Debugger listening on ws://127.0.0.1:9229/2c1e5009-be6a-4036-8ad3-185b20bbb1a0

Attach with chrome://inspect, VS Code, or any CDP client. Sources arrive with their real file: URLs, so a breakpoint set by URL lands in the file you are looking at; a paused program is genuinely stopped, and locals read through the debugger.

Use --inspect-brk for a program that ends quickly — otherwise it can be over before a client finishes connecting.

Tests

esdev test takes the same flags:

esdev test --inspect-brk src/cart.test.ts

Each test file runs in a process of its own, so the files run one at a time and each serves the debugger in turn on the same address. With --inspect-brk, every file stops before its first statement until a debugger releases it. Attach again for the next file. chrome://inspect lists each one as it starts.

A paused breakpoint would trip --timeout, so it is off while debugging. A test's own timeout option still applies. --inspect cannot be combined with --coverage, which uses the same inspector, or with --browser: use --headed and the browser's developer tools instead. With --isolation=none all the files share one process and one debugger session.

Binding

esdev --watch --inspect reclaims its port across a restart, so you can leave a debugger attached while you edit.