Closed xenobytezero closed 2 years ago
Is there a reason you're using the pwa-node
launch type rather than the node-terminal
type?
Here's my launch.json
:
{
"configurations": [
{
"command": "yarn dev",
"name": "Debug dev",
"request": "launch",
"type": "node-terminal"
}
]
}
Never seen "node-terminal" before, but that does help things a little, at least with the keystone.ts
file
The problem appears to be in two main areas.
Even in the keystone.ts
file, if the server is built and running, adding a breakpoint to that file instead adds the breakpoint to the transpiled version of the code. This can be found by looking at the "Breakpoints" list in the Debug view in VSCode, adding the breakpoint, then double clicking on the new breakpoint in the list. You will be taken to the transpiled version of the code.
I have added a few extensions to the Express app (as mentioned above) and am seeing different behaviour. Breakpointing the router.get()
call trips the breakpoint during the intial setup of the server as expected. Breakpointing the handler for that endpoint is NEVER tripped when calling the endpoint.
If I then clear all breakpoints and add it again inside the handler while the server is running, the following happens
My totally naive thoughts is that this is something to do with the conflation of how source maps are generated mixing with the HMR features of NextJS? I can see some people with similar issues with NextJS apps with increasingly complex setups for their launch.json
files, none of which I could get to work with Keystone.
I think that node-terminal
is related to the auto-attach debugging feature (https://code.visualstudio.com/docs/nodejs/nodejs-debugging#_auto-attach) in which any terminal you run node
from (should) automatically attach a JS debugger. These days I don't even setup launch.json
, I just pop a terminal and run npm <whaterver>
.
I've been able to set breakpoints in files other than keystone.ts
but I'll need to setup a more complex app with extended express to test that scenario.
Ok I finally got a chance to test this with a minimal example
https://github.com/xenobytezero/keystone-debugging-example
This is a npx create-keystone-app
done today with Node 16.12, with a very simple extra endpoint added with the extendExpressApp
and a VSCode debugging launch.json
set as recommended above.
After launching the debugger with F5, I hit the breakpoint inside extendExpressApp
(keystone.ts:36
) fine, but actually hitting the endpoint (http://localhost:3000/test-plugin/endpoint
) returns the correct result but done not trigger an endpoint put in the handler (test.ts:11
)
Just looked at your sample app, that's using keystone-next
, not keystone-6
, so it's on an unsupported codebase. That may cause some problems
Just realised that myself, updating my actual app as we speak, will report back with an updated app if its still an issue
Pushed change to the Github, updated to latest versions of everything, issue is persisting.
@xenobytezero Thanks. I can repo too.
I'll have a dig around and reach out to the VS Code team as well
I am having an issue where I cannot set breakpoints in the original source of my code files when using
keystone dev
from VSCodeI have the following in my
launch.json
and setting a debug point in
keystone.ts
near the start will breakpoint, but will break on what appears to be the transpiled JavaScript in a new tab, even though the file name and path are the same as the original source.This is also true of extra code I have written that is used in the
keystone.ts
, namely extensions to the ExpressJS app viaserver.extendExpressApp
in the config.Does anyone have a working launch.json that lets them debug the original source?