Sapper: Debugging Sapper app server in dev mode in Chrome or VS Code not possible

[nsivertsen]

One can debug the server portion of a Sapper app quite well using ndb (because it handles child processes intelligently out of the box), but currently it's not possible to do so with Chrome's DevTools or VS Code. If one tries to run:

$ node --inspect node_modules/sapper/dist/cli.js dev

from inside a Sapper app, one gets:

Debugger listening on ws://127.0.0.1:9229/afd0539e-40c6-474e-bf06-4caa40c57e41
For help, see: https://nodejs.org/en/docs/inspector
✔ server (765ms)
✔ client (778ms)
> Server crashed
Starting inspector on 127.0.0.1:9229 failed: address already in use

✔ service worker (13ms)

...because sapper dev spawns a new process for the server, and by default this new process inherits all arguments from the parent process, including the port on which the DevTools server should run, and this port is obviously already occupied.

The fix is quite simple and I'm already working on a PR, just wanted to leave this here in the meantime.

[Rich-Harris]

Released 0.20.4 with the fix — thanks

[Vishwaas]

@Rich-Harris
I tried different ways to achieve this but it still fails

{
            "name": "Attach",
            "type": "node",
            "request": "attach",
            "port": 3000,
            "address": "localhost",
            "restart": false,
            "sourceMaps": false,
            "outDir": null,
            "localRoot": "${workspaceRoot}",
            "remoteRoot": null
        },
        {
            "name": "Launch via NPM 1",
            "outFiles": [
                "${workspaceRoot}/__sapper__/client.js",
                "${workspaceRoot}/__sapper__/server.js",
                "${workspaceRoot}/__sapper__/service-worker.js"
            ],
            "type": "node",
            "request": "launch",
            "stopOnEntry": true,
            "program": "${workspaceRoot}/src",
            "args": [],
            "cwd": "${workspaceRoot}",
            "runtimeExecutable": "C:\\Program Files\\nodejs\\npm.cmd",
            "runtimeArgs": ["run-script", "dev"],
            "port": 3000
        },
        {
            "type": "node",
            "request": "launch",
            "name": "Launch Program",
            "program": "${workspaceFolder}/node_modules/sapper/dist/cli.js",
            "args": ["dev"]
        }

For the last one it appears as
service worker (120ms)
cli.js:622

Server is not listening on port 3000

If I add

{
            "type": "node",
            "request": "launch",
            "name": "Launch Program",
            "program": "${workspaceFolder}/node_modules/sapper/dist/cli.js",
            "args": ["dev"],
                        "port": 3000
        }

it crashes as

[nsivertsen]

@Vishwaas in the configuration mentioned here: https://github.com/sveltejs/sapper/pull/436, note the line

"autoAttachChildProcesses": true

It should work with that line added.

[adfra]

I am experiencing the exact scenario outlined above and despite having
"autoAttachChildProcesses": true
...I still get "Server is not listening on port 3000".
Are there any other suggestions?

[jcgsville]

@adfra I am having the same problem intermittently - sometimes it works and sometimes it doesn't with no change to my code or configuration.

[mdorda]

This config works for me without any problem.

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "node",
            "request": "launch",
            "name": "Debug app",
            "protocol": "inspector",
            "program": "${workspaceFolder}/node_modules/sapper/dist/cli.js",
            "args": ["dev"],
            "console": "integratedTerminal",
            "autoAttachChildProcesses": true
        }
    ]
}

[adfra]

Thanks @mdorda - unfortunately the issue remains for me, even with an exact copy of your config.
A bit more detail: In VSCode I cannot set any active breakpoints on neither client or server files. Once I run the debugger they are just greyed out with:

Breakpoint ignored because generated code not found (Source Map Problem?)

When starting the debugger with mdorda's exact debug config I see this in the console:

PS C:\Users\somePath\code\launchassist> & 'C:\Program Files\nodejs\node.exe' '--inspect-brk=38366' 'node_modules\sapper\dist\cli.js' 'dev'
Debugger listening on ws://127.0.0.1:38366/30c973d2-f874-458e-8f1f-b902ebe44cc3
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
✔ server (2.9s)
✔ client (4.4s)
Debugger listening on ws://127.0.0.1:9222/bd137a10-7f2c-4537-8aca-f811f5489637
For help, see: https://nodejs.org/en/docs/inspector
✔ service worker (48ms)
> Server is not listening on port 3000
Socket: New client connected.
Socket: Task updated.1573124599401
Socket: Task updated.1573124604878

Contrary to the log message, the server is actually up and available on port 3000. The 'Socket:...' messages are just me clicking around in the app and things getting logged on the server side from socket.io. Breakpoints however are not triggering.

Any help would still be appreciated. Wondering if I need to point VSCode explicitly to where my compiled code is located or similar to fix sourcemaps?

Loving Sapper/Svelte, but not being able to use IDE for debugging is a killer...

[mdorda]

Grayed out breakpoints are usualy caused by missing source maps. Do you send dev option to svelte rollup plugin? But I am affraid I cannot help you. I use MacOS, configuration file I posted above and everything works.

[adfra]

Thx again @mdorda - yes, I am. The dev option going to the svelte plugin being set to TRUE (mode = 'development'). See snippet below.

export default {
client: {
input: config.client.input(),
output: config.client.output(),
plugins: [
replace({
'process.browser': true,
'process.env.NODE_ENV': JSON.stringify(mode)
}),
svelte({
dev,
hydratable: true,
emitCss: true
}),
resolve({
browser: true,
preferBuiltins: false,
dedupe
}),
commonjs(),

[adfra]

Ok, I tracked this one down, now just need a little help to fix this properly.
The problem is in fact that the sourcemaps are not there. This seems to be caused by
rollup.config.js:

export default {
client: {
output: config.client.output(), // => This actually returns sourcemap: false

When I replace config.client.output() with its hard-coded return value...

output: { dir: 'C:\Users\frank\...\__sapper__\dev/client',
entryFileNames: '[name].[hash].js',
chunkFileNames: '[name].[hash].js',
format: 'esm',
sourcemap: false},

...and swap the sourcemap value from false to true, the debugger works. (I did this for client AND server in the rollup.config.js).

Above is just a nasty hack - @Rich-Harris, I got lost in the library files on chunk3.js, could you advise how to properly get the sourcemap value to be set to true here?

[jesseskinner]

Just wanted to add that @adfra's trick worked for me. As they mentioned, I had to add this to both the client and server sections of rollup.config.js, and did so with this approach instead of copying over the return value:

output: { ...config.server.output(), sourcemap: true },

UPDATE: nevermind, still getting the "Server is not listening on port 3000" after some delay :(

[kwangure]

You got the sourcemap bit right. Now step 2.

Make sure your webroot is set correctly.

// launch.json
"webRoot": "${workspaceFolder}/__sapper__/dev/client",

I commented on a related issue here.

[ticruz38]

While I was able to debug the browser/client side of sapper, I had no success so far with the server/nodejs side.
Does anyone have a setting config to be able to debug the nodejs process of sapper?

[ticruz38]

Seems like none of the config above work for debugging on the browser in the latest vscode versions.
I am using the webpack loader with hot reloading