The debug build creates a symlink to PSES, rebuilds PSES, does not
minify the extension, and generates a TypeScript sourcemap. The release
build deletes the symlink if it exists and copies PSES, only builds PSES
if not already copied, minifies the extension, and does not generate a
TypeScript sourcemap. This removes the manual LinkEditorServices step
and ensures that the developer debugging experience works well.

@JustinGrote Want to help me merge this 😂

@andschwa shouldn't the code workspace include a debug build task?

Also while not necessary to cover in this PR, I really would like to figure out a way to build a "watch" that, on C# change, would rebuild editor services and reload the extension host. dotnet watch run can cover the first part, I don't know if we can figure out a hook to reload the extension host debug process.

@andschwa shouldn't the code workspace include a debug build task?

Doesn't need a debug "task" since it has a debug launch configuration (both of them, actually):

"Launch Extension" launches the extension under the VS Code debugger (and this PR explicitly ensure that actually works well by not minifying the code when developing), and "Attach to Editor Services" then will ask for the pwsh process to attach to (running under that launched Code instance with the extension).

If you're asking if the build task needs to be in -Configuration Debug, that's just the default build. -Configuration Release is only needed when releasing, and the automated pipelines do exactly that.

Also while not necessary to cover in this PR, I really would like to figure out a way to build a "watch" that, on C# change, would rebuild editor services and reload the extension host. dotnet watch run can cover the first part, I don't know if we can figure out a hook to reload the extension host debug process.

I'll look into it!

LGTM then, I didn't notice debug was the default, that explains what I missed.