Copy extension binaries during main vscode task

[jmcphers]

This change addresses an issue in which the tree-sitter.wasm file does not load in release builds, which causes R testing to fail.

This problem is a regression from the 1.96 merge. The problem was that we were copying the binaries as part of the build task compileExtensionsBuildTask.

positron/build/gulpfile.vscode.js

Lines 617 to 623 in 4ea5c56

	const vscodeTask = task.define(`vscode${dashed(platform)}${dashed(arch)}${dashed(minified)}`, task.series(
	compileBuildTask,
	compileExtensionsBuildTask,
	compileExtensionMediaBuildTask,
	minified ? minifyVSCodeTask : bundleVSCodeTask,
	vscodeTaskCI
	));

After 1.96, this build task is no longer invoked as part of the main vscode task; it was replaced with compileNonNativeExtensionsBuildTask.

positron/build/gulpfile.vscode.js

Lines 603 to 610 in 2d4492c

	const vscodeTask = task.define(`vscode${dashed(platform)}${dashed(arch)}${dashed(minified)}`, task.series(
	compileBuildTask,
	cleanExtensionsBuildTask,
	compileNonNativeExtensionsBuildTask,
	compileExtensionMediaBuildTask,
	minified ? minifyVSCodeTask : bundleVSCodeTask,
	vscodeTaskCI
	));

This change did not generate a merge conflict since there are no Positron edits to this list.

The fix is to add the copyExtensionBinariesTask to the main vscode task in a Positron code fence, to reduce the odds of this situation happening again.

Addresses #6345.

Reusing VS Code's tree-sitter-wasm

As a side note, the first thing I tried was using VS Code's tree-sitter-wasm instead of continuing to bundle a redundant copy in positron-r. This turned out to be more of a mess than it was worth. Specifically:

• it is possible to cause VS Code's tree-sitter.wasm file to load using the locateFile option in Parser.init, but it is not compatible with the JavaScript side of the module
• it is also not possible (or at least not easy) to wholly switch from web-tree-sitter => @vscode/tree-sitter-wasm due to API differences

Release Notes

New Features

• N/A

Bug Fixes

• Restore R package testing functionality (R package testing UI doesn't work in release builds #6345)

QA Notes

I'm surprised this problem is not causing more failures! This fix isn't really specific to R or testing UI. If you see any issues post 1.96 that appear to be due to a missing binary in an extension, this is a likely cause.

[github-actions]

E2E Tests 🚀
This PR will run tests tagged with: @:critical

^{readme  valid tags}

[juliasilge]

I made a local release build and the R package testing UI now works for me. ✅

Note

I had to blow away the state for the release build of Positron on my machine in order to get things going again. I think the state of the testing UI is stored in its broken, no-parsing, trying-to-run situation in some storage somewhere. If folks have run into this problem in the wild, I suspect they will need to also do this to get unstuck again.

[jennybc]

Thanks @jmcphers for this!