Debug Server Side code using --inspect

[timofei-iatsenko]

It would be nice to have an option to enable node debugging for server-side code to be able to stop on breakpoints inspect variables and etc.

Proposed syntaxis is:

svelte-kit dev --inspect

Currently, it's possible to start debugger using:

 "dev": "NODE_OPTIONS=\"--inspect\" svelte-kit dev"

This enables inspecting and i successfully connected to the nodejs using Chrome Dev Tools.
But looks like server-side code generated without source maps and it makes it impossible to put breakpoints inside IDE such as Vs Code or Webstorm (they just ignore breakpoints and execute code without stop).

So when --inspect option is set we should pass through this flag to nodejs and enable sourcemaps in all transpilers/vite

[alexbjorlig]

I know it's normally not very nice to add a comment about +1. But I must emphasize how absolute critical debugging is for the developer experience. @thekip is there something I can help with to help with this?

[timofei-iatsenko]

Not for me, i just submitted a feature request. Looks like there is no interest from the maintainer's side, so if you implement this and prepare a PR it would be nice for everyone.

[DylanPiercey]

Looks like this would be solved by vitejs/vite#3928

[mikenikles]

I was curious about that and it turns out it's a few clicks in VS Code to make this work.

I put together a clickable walkthrough at https://twitter.com/mikenikles/status/1495781582996750337.

[timofei-iatsenko]

Debugging with "debugger;" statements was always possible, problem with debugging using breakpoints in ide. The main benefit of IDE breakpoints vs "debugger;" statements you don't need to stop and rebuild/reload current file and don't loose a debugging context.

[Rich-Harris]

I'm not sure that there's anything SvelteKit could do here — by the time you've invoked the svelte-kit CLI, Node is already running. We can't add --inspect retroactively.

It's easy to start the dev server with the inspector without editing the run script:

NODE_OPTIONS="--inspect" npm run dev

Beyond waiting for the Vite PR to get merged is there anything to be done here, or can this issue be closed?

[Nisthar]

NODE_OPTIONS="--inspect" npm run dev

I get Starting inspector on 127.0.0.1:9229 failed: address already in use everytime. Tried changing the port still doesn't work.

[Rich-Harris]

No idea why the port is in use; lsof -i tcp:9229 may help diagnose. Either way, it's not something SvelteKit can help with.

Looks like there's nothing for Kit to do here, so I'll close this

[mathieuhelie]

NODE_OPTIONS="--inspect" npm run dev

I get Starting inspector on 127.0.0.1:9229 failed: address already in use everytime. Tried changing the port still doesn't work.

This may help: I get the same error when adding NODE_OPTIONS from the terminal, but the debugger listens when adding NODE_OPTIONS to the svelte-kit dev script in package.json.

[jayfresh]

The vite PR has been closed without merging - vitejs/vite#3928

[mike-lloyd03]

Is there any current workaround to inspect responses to server-side requests?

[Jakeii]

There's another PR (vitejs/vite#9740) that looks like it may solve this, but it hasn't had any responses.

[GeoffreyBooth]

Looks like there’s nothing for Kit to do here, so I’ll close this

@Rich-Harris I think what Kit could do here is document how developers should debug server-side code. Even if it’s the same as how to debug Vite-served apps generally, it’s important enough to the developer experience that it deserves a mention in SvelteKit’s docs.

I was able to attach the Chrome DevTools debugger by running Vite directly:

NODE_OPTIONS=--inspect ./node_modules/.bin/vite dev

Running Vite via npm run dev or npx vite dev both fail, presumably because Vite is run inside a child process and the --inspect gets applied to the parent npm process when we want it attached to the child where our code is running.

[alexbjorlig]

Attaching Chrome DevTools debugger is certainly better than nothing, but could we please agree that SvelteKit most certainly deserves a well-documented best of all frameworks debugging experience?

Maybe this issue could be re-opened or a milestone created of some sort.

[rolanday]

+1. Currently evaluating SvelteKit for a new project, but the lack of clear guidance on how to debug client & server is causing me to pump the brakes -- hard. I can't imagine developing a serious app using "printf" debugging (which lots of folks seem to be doing from my searches), and it's quite surprising for such an otherwise progressive framework.

[rolanday]

In case anybody stumbles upon this thread in search of how to debug server side, the following launch.json works perferecly for me:

{
	// Use IntelliSense to learn about possible attributes.
	// Hover to view descriptions of existing attributes.
	// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
	"version": "0.2.0",

	"configurations": [
		{
			"command": "npm run dev",
			"name": "Debug SvelteKit",
			"request": "launch",
			"type": "node-terminal",
			"cwd": "${workspaceFolder}"
		},
		{
			"name": "Attach by Process ID",
			"processId": "${command:PickProcess}",
			"request": "attach",
			"skipFiles": ["<node_internals>/**"],
			"type": "pwa-node"
		}
	]
}

credit: https://gist.github.com/kiliman/a9d7c874af03369a1d105a92560d89e9

[woahitsraj]

@rolanday, The client side Sveltekit debugging is quite good. I've had no issue debugging client side code with Sveltekit in Chrome or Vscode. The basic Chrome web app configuration works well

		{
			"type": "chrome",
			"request": "launch",
			"name": "Launch Chrome against localhost",
			"url": "http://localhost:5173",
			"webRoot": "${workspaceFolder}"
		}

[rolanday]

@woahitsraj Thanks, no issues here either re: client-side. The OP was asking specifically about server-side, and above launch.json works well. (I went a little too far to say perfect since no sourcemaps, but it's javascript so not a big deal when compared to needing to printf debug.) There's a recent discord discussion as well, also referencing this ticket, which is what drew my attention back to here. Had it not been for the above launch.json, SvelteKit would have been a non-starter for me, but super glad I found a solution because I'm loving SvelteKit so far!! https://discord.com/channels/457912077277855764/1066511264311951490/1066511264311951490

[BMorearty]

Launching the process using NODE_OPTIONS=--inspect ./node_modules/.bin/vite dev and then attaching the debugger to port 9229 enables me to set breakpoints in Webstorm / Jetbrains IDEs, but only in .js files. Not in .ts files or .svelte files. Those breakpoints just don't get hit.

But since my code's in TypeScript + .svelte files, setting JS breakpoints isn't useful. 😢

[unlocomqx]

@BMorearty I used to add a debugger statement when I'm debugging in phpstorm/webstorm.. it's not fun.
I'm guessing that either webstorm can't read the sourcemaps correctly and that the sourcemaps are broken.

[BMorearty]

@unlocomqx Thank you, that did the trick.

By the way I couldn't set breakpoints in VS Code either (not even in .js files) even with @rolanday's launch.json but I didn't mention it because that's not my daily editor. Using debugger works in both IDEs. 👍🏻

[nicolas-albert]

Hello.
I'm relatively new to the Svelte/Sveltekit/nodejs world and have been doing Java for decades.

I expected the server-side debug is a formality and I'm just disappointed to see it's not the case and this ticket is closed without a clear way to do this.

If I launch the configuration with node-terminal and add a debugger in TS code, it breaks but with an error and nothing in the debugger.

I only get this in the Stack part:

dev: npm-cli.js [7328]
  vite.js [23312]
    [UriError]: if a URI does not contain an authority component, then the path cannot begin with two slash characters ("//")

There is another subtility to success for a server-side debugging ?

[maiertech]

There are different configs in circulation for server-side debugging. I use this one for +server.js and +page.server.js. +page.js runs in the browser during dev, and you can debug it there.

You need to work with debugger statements, which is not ideal.

I complement this approach with Thunder Client for API routes. It's a VS Code extension, and you can store your requests in JSON files and commit them.

[gsxdsm]

Using debugger statements is a weak workaround. We need to push to get actual sourcemap support in Vite for SSR.

[cyco130]

Here's my solution to this problem: cyco130/vavite#17. It uses Node's experimental ESM loader feature, enabling sourcemaps and breakpoints on the server. The downside is, it almost certainly leaks memory. I find it an acceptable compromise since restarting the server once in a while is enough the clean up resources but your mileage may vary.

[epavanello]

Finally, thanks @cyco130, it works for sveltekit

[abirtley]

Amazing, thank you @cyco130 ! After installing vavite as per the Usage instructions in that pull request, I could then debug the server-side typescript code using the following simple VSCode launch.json file. (I'm using yarn, and port 3000, but you could use npx run and a different port and it should work.) You can now set breakpoints in the gutter, just like with regular VSCode debugging.

{
  // Use IntelliSense to learn about possible attributes.
  // Hover to view descriptions of existing attributes.
  // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
  "version": "0.2.0",
  "configurations": [
    {
      "command": "yarn vavite-loader vite dev --port 3000",
      "name": "Launch SvelteKit server",
      "request": "launch",
      "type": "node-terminal"
    },
  ]
}

[Dan1ve]

Amazing that this works now, thanks a lot @cyco130 and others! I posted a little write-up here (incl. some details and caveats)

[AlexRMU]

Replacing this

NODE_OPTIONS="--inspect" npx vite

with this

NODE_OPTIONS="--inspect" vite

helped me

[Arikael]

Amazing that this works now, thanks a lot @cyco130 and others! I posted a little write-up here (incl. some details and caveats)

just a heads up for future viewers, with vite ^5 you will need to change the code slightly (using typescript)

let plugins = [sveltekit()];
if (mode === 'development') {
    const loaderPlugin: Promise<any> = Promise.resolve(nodeLoaderPlugin())
    plugins = [loaderPlugin, ...plugins];
}

return {
    // ... your code ...
    plugins
};

Working with WebStorm I also had to to add --experimental-loader=@vavite/node-loader to the node options in the Run/Debug Configuration.
Strangely it didn't work when I added it via package.json scripts like NODE_OPTIONS=--experimental-loader=@vavite/node-loader, but I didn't investigate further.

But it seems to work now, thanks for your efforts :)

[izackp]

hmm I'm getting

@vavite/node-loader/plugin: @vavite/node-loader is not enabled. Please run with `node --experimental-loader=@vavite/node-loader`

No matter what I try. Maybe this 'fix' is outdated?