feat(ud): Debugger support#2015
Conversation
✅ Deploy Preview for cedarjs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Greptile SummaryThis PR adds debugger support for unified dev mode. The main changes are:
Confidence Score: 4/5This is close, but the debug-port propagation should be fixed before merging.
packages/cli/src/commands/dev/apiDebugFlag.ts Important Files Changed
Reviews (4): Last reviewed commit: "Merge branch 'main' into tobbe-feat-ud-d..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
|
| Command | Status | Duration | Result |
|---|---|---|---|
nx run-many -t build:pack --exclude create-ceda... |
✅ Succeeded | 1s | View ↗ |
nx run-many -t build |
✅ Succeeded | 31s | View ↗ |
nx run-many -t test --minWorkers=1 --maxWorkers=4 |
✅ Succeeded | 1m 43s | View ↗ |
nx run-many -t test:types |
✅ Succeeded | 10s | View ↗ |
💡 Verify your cache is correct by running tasks in a sandbox. Read docs ↗
☁️ Nx Cloud last updated this comment at 2026-06-29 11:34:13 UTC
| vi.spyOn(process, 'exit').mockImplementation(() => undefined as never) | ||
| vi.spyOn(console, 'error').mockImplementation(() => {}) | ||
|
|
||
| const { parseCliArgs, openDebugger } = await import('../cedar-unified-dev.js') |
There was a problem hiding this comment.
cedar-unified-dev.ts and runs its module-level startUnifiedDevServer() call. The new spies prevent process.exit() and hide console.error, but startup still sets process.env.__CEDAR_UNIFIED_DEV = 'true' and only stops because the mocked config is incomplete enough to crash before Vite starts. That leaked env state can affect later tests, and any future mock that includes web.port can re-enter real dev-server startup during this unit test. Please guard the entrypoint so server startup only runs when the file is executed as the CLI binary.
| const { forceOptimize, debug, portArg, debugPort, debugBrk, serverArgs } = | ||
| parseCliArgs() | ||
|
|
||
| if (debugPort !== undefined) { |
There was a problem hiding this comment.
This guard now preserves --debug-port 0 when cedar-unified-dev is started directly, but the normal cedar dev --ud --apiDebugPort 0 path can still rewrite the value before it gets here. devHandler builds the child command through getApiDebugFlag(apiDebugPort, apiAvailablePort), and that helper still treats numeric 0 as absent. When a user asks for an OS-assigned debug port through cedar dev --ud --apiDebugPort 0, the child receives the derived --debug-port 1<apiPort> value instead of --debug-port 0, so the explicit ephemeral-port request is not honored.
There was a problem hiding this comment.
@greptileai what's this "ephemeral port" you're talking about?
There was a problem hiding this comment.
"Ephemeral port" is a networking term for port 0. When you pass 0 as a port number to Node.js (or any TCP socket), the OS automatically picks any available port from its dynamic range (~49152–65535). It's useful when you don't care which specific port is used.
My original comment was flagging that if someone passed --apiDebugPort 0 intending OS-assigned port selection, getApiDebugFlag would silently ignore it — because if (apiDebugPort) treats 0 as falsy and falls through to the derived-port logic instead.
That said, looking at this PR again: it's about --debug-port for cedar-unified-dev directly, not --apiDebugPort. The if (debugPort !== undefined) guard in your changes is already correct. The getApiDebugFlag concern is pre-existing behavior unrelated to your changes, and passing 0 as a debug port is an obscure edge case no one is likely to hit.
You can safely ignore my original comment.
|
The changes in this PR are now available on npm. Try them out by running Or try it in a new app with |
1 participant
Pass through
--debug-porttocedar-unified-dev'sstartUnifiedDevServer()and attach the node inspector to vite's node process. Also adds--debug-brkwhich probably is what you want to use most of the time when debugging in an IDE. Launch with that flag from your debug configurations.For attaching to an already-running server, you'll have to trigger HMR in the file you want to debug for Vite to invalidate its cache and load the module again, which lets the debugger properly discover the breakpoint and break on it