Debugging custom VS Code extension

[jsjoeio]

This is a thread related to an issue we're currently helping someone with: debugging issues with a custom VS Code extension.

We're starting this thread with the hopes of:

• sharing our debugging process
• sharing notes
• (hopefully) sharing how we fixed the issue

Feel free to follow along here. I will add replies to this as I go.

[jsjoeio]

Debugging Workflow

Due to an issue with extension development/debugging in code-server (see #2546), we cannot develop the extension in code-server like you would a regular VS Code extension.

Instead, we must use a slightly modified debugging workflow. There are two options:

Option 1

1. make changes to the extension
2. build the extension into vsix file with npx vsce package
3. manually install in code-server with vsix file
4. test

This works but it is very tedious.

Option 2

Suggested by @code-asher

1. open extensions folder directly (usually under ~/.local/share/code-server/extensions)
2. find extension (make sure you installed vsix file otherwise you won't see it here)
3. cd into extension folder
4. edit files directly and recompile

This works well when the source files are included with the extension. If they aren't, this may be troublesome.

Notes to other maintainers

I tested developing an extension in code-server using the typical "Your First Extension" workflow. (write extension, hit F5, in the IDE window test extension). When it opens a new window, it doesn't have the extension installed so you can't test it.

I spoke to @code-asher about this and he said:

I'm not sure how hard adding support is, it might be as simple as providing the debug port in the VS Code server code
Currently we provide nothing I think

When we do look into this in the future, we'll need to see how easy/difficult it is to support extension development.

[jsjoeio]

That didn't work. We need to do this in asWebviewUri

[jsjoeio]

This is what we need to patch: lib/vscode/src/vs/workbench/api/common/shared/webview.ts

[jsjoeio]

We could stripe out the port 🤔 That might be better than the escape

[jsjoeio]

Turns out removing the port in the asWebviewUri fixes it!

// NOTE@coder (@jsjoeio)
	// We're not exactly sure how the resource.authority is used in the URI
	// but we noticed resources not loading correctly when the authority
	// contained a port like localhost:8080.
	// As a temporary workaround, we split the authority at the first colon
	// and use the first part e.g. localhost
	return URI.from({
		scheme: Schemas.https,
		authority: `${resource.scheme}+${resource.authority.split(":")[0]}.${webviewRootResourceAuthority}`,
		path: resource.path,
		fragment: resource.fragment,
		query: resource.query,
	});

[jsjoeio]

related drawing: https://excalidraw.com/#json=6022466832957440,nM6CH8Ga9F2AiLSzjJ55-A