Some popular extensions (eg GitHub Pull Requests and Issues) fail on load due to lack of Proposed API support

[aderk]

Expected behavior: Extensions load w/o error, eg GitHub.vscode-pull-request-github
Actual behavior: Extensions fail to load with the following error.

Ideas for fixing:

1. hardcode --enable-proposed-api flag for vscode (to enable for all extensions).
2. I believe issue Provide VS Code flags in VSCODE_OPTIONS #1528 could also fix this by adding the flag to VSCODE_OPTIONS once it exists.

[2020-05-28 10:24:10.809] [exthost] [error] Error: [GitHub.vscode-pull-request-github]: Proposed API is only available when running out of dev or with the following command line switch: --enable-proposed-api GitHub.vscode-pull-request-github
        at a (/usr/lib/code-server/lib/vscode/out/vs/workbench/services/extensions/node/extensionHostProcess.js:590:810)
	at Object.t.checkProposedApiEnabled (/usr/lib/code-server/lib/vscode/out/vs/workbench/services/extensions/node/extensionHostProcess.js:591:148)
	at Object.registerDecorationProvider (/usr/lib/code-server/lib/vscode/out/vs/workbench/services/extensions/node/extensionHostProcess.js:906:76)
	at new t.PullRequestsTreeDataProvider (/usr/local/x/home/aderk/.local/share/code-server/extensions/github.vscode-pull-request-github-0.16.0/media/extension.js:1:547205)
	at /usr/local/x/home/aderk/.local/share/code-server/extensions/github.vscode-pull-request-github-0.16.0/media/extension.js:1:653078
	at Generator.next (<anonymous>)
	at /usr/local/x/home/aderk/.local/share/code-server/extensions/github.vscode-pull-request-github-0.16.0/media/extension.js:1:650859
	at new Promise (<anonymous>)
	at n (/usr/local/x/home/aderk/.local/share/code-server/extensions/github.vscode-pull-request-github-0.16.0/media/extension.js:1:650607)
	at t.activate (/usr/local/x/home/aderk/.local/share/code-server/extensions/github.vscode-pull-request-github-0.16.0/media/extension.js:1:652378)
	at Function._callActivateOptional (/usr/lib/code-server/lib/vscode/out/vs/workbench/services/extensions/node/extensionHostProcess.js:825:502)
	at Function._callActivate (/usr/lib/code-server/lib/vscode/out/vs/workbench/services/extensions/node/extensionHostProcess.js:825:153)
	at /usr/lib/code-server/lib/vscode/out/vs/workbench/services/extensions/node/extensionHostProcess.js:824:94
	at processTicksAndRejections (internal/process/task_queues.js:97:5)
	at async Promise.all (index 0)

• Web Browser: Chrome
• Local OS: Ubuntu
• Remote OS: Ubuntu
• Remote Architecture: AMD64
• code-server --version: 3.3.1 6f13097

[aderk]

If you can point me in the right direction, I'm happy to try to implement option #1 with a PR. I'm getting lost between all the Args dataclasses and wondering if I need to wrangle through the vscode.patch. Thanks!

[nhooyr]

cc @code-asher

[aderk]

@code-asher Let me know if I can help out at all!

[code-asher]

For the first option all we'd need to do is add the option to our Args interface and the options constant in src/node/cli.ts. That'll make it a valid option for our parser.

We pass the entire parsed arguments object to VS Code when we spawn it so there's nothing else that needs doing in the patch or anything like that.

Option 2 would involve patching though. Probably in lib/vscode/src/vs/server/entry.ts where we get the message containing the args from the parent process. We'd check for a VSCODE_OPTIONS environment variable and if it exists we'd import VS Code's parser (parseArgs from lib/vscode/src/vs/platform/environment/node/argv.ts), use it to parse VSCODE_OPTIONS, then merge the result with the arguments received in the message.

[aderk]

I attempted option 1 to no avail in PR #1779. The arguments seem accepted, but the same error (above) persists. I also tried enabling dev mode with the VSCODE_DEV env variable set to '1' or 'true' or '', which also didn't prevent the error. I'm not sure how to debug or move forward, if you have any tips!

[code-asher]

I did some digging and I haven't the faintest idea why but it turns out the web version handles this part differently than the local version. Unfortunately it looks like fixing it will require a patch.

VS Code web expects a payload object with an enableProposedApi key: https://github.com/microsoft/vscode/blob/1.45.1/src/vs/workbench/services/environment/browser/environmentService.ts#L254

We provide that payload in src/vs/server/node/server.ts#L101. So we'd need to add enableProposedApi there (only if the proposed API flag is set; it'll be in options.args and enable-proposed-api will need to be added to the interface). Then in the environmentService.ts linked above we'd set it to the value instead of hardcoding [].

The payload type expects values to be strings so to pass that array we could use JSON.stringify & JSON.parse.

[code-asher]

I'm not sure why it didn't automatically close but this is fixed by #2002. We're working on getting a new release out.

[nhooyr]

Reopening and will close when new release is cut.

[nhooyr]

v3.5.0 with VS Code v1.48.2 has been released, fixing this issue!