Cannot breakpoint source TS file while debugging from VSCode

[xenobytezero]

I am having an issue where I cannot set breakpoints in the original source of my code files when using keystone dev from VSCode

I have the following in my launch.json

        {
            "type": "pwa-node",
            "request": "launch",
            "name": "keystone:dev",
            "skipFiles": [
                "<node_internals>/**"
            ],
            "program": "${workspaceFolder}\\node_modules\\@keystone-next\\keystone\\bin\\cli.js",
            "cwd": "${workspaceFolder}\\packages\\server",
            "args": [
                "dev"
            ],
            "sourceMaps": true,
            "sourceMapPathOverrides": {
                "webpack-internal:///*": "${workspaceFolder}/packages/server/.keystone/admin"
            },
            "outFiles": [
                "${workspaceFolder}/packages/server/.keystone/admin/**/*.js",
                "!**/node_modules/**"
            ]
        },

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 via server.extendExpressApp in the config.

Does anyone have a working launch.json that lets them debug the original source?

[aaronpowell]

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"
        }
    ]
}

[xenobytezero]

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.

Adding additional breakpoints after the server is running.

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.

Adding breakpoints to code outside of the "initialisation" pass of the application

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

• Click to add breakpoint inside handler, breakpoint not shown in source
• Double click new breakpoint in breakpoint list, taken to transpiled code, with the breakpoint in the wrong place
• Calling the endpoint does not trip the breakpoint.
• Removing the breakpoint from the transpiled code, then re-adding it inside the transpiled handler, then calling the endpoint DOES trip the breakpoint.

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.

https://stackoverflow.com/questions/63523469/vscode-wont-bind-client-side-breakpoints-for-nextjs-9-5-2

vercel/next.js#24445

[aaronpowell]

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.

[xenobytezero]

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)

[aaronpowell]

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

[xenobytezero]

Just realised that myself, updating my actual app as we speak, will report back with an updated app if its still an issue

[xenobytezero]

Pushed change to the Github, updated to latest versions of everything, issue is persisting.

[aaronpowell]

@xenobytezero Thanks. I can repo too.

I'll have a dig around and reach out to the VS Code team as well

[dcousens]

We've moved this to a discussion for now until we have a concrete bug/issue to resolve, but please don't hesitate to keep providing context.

[relusion]

Apparently, the problem lies in ..\node_modules@keystone-6\core\dist\loadConfig-91b801c9.cjs.dev.js within the getEsbuildConfig function. After I added 'sourcemap: true', esbuild produced a source map, and VS Code attached the debugger without any issues.

function getEsbuildConfig(cwd) { return { entryPoints: ['./keystone'], absWorkingDir: cwd, bundle: true, sourcemap: true,

I'm confident that there's a more optimal solution, but this is food for thought.

[dcousens]

Relevant code

keystone/packages/core/src/lib/config/loadConfig.ts

Line 6 in d33bb47

export function getEsbuildConfig(cwd: string): BuildOptions {

[relusion]

I have one more observation to share. Although I am now able to stop at a breakpoint in TS, the admin UI is no longer opening. The GraphQL API works fine, but it appears that the debug session is somehow affecting the rendering of the admin UI. It could be that this issue is limited to my environment.

[wjutsum]

Can confirmed this change worked for me and the admin UI loads fine.