Adopt using platform specifier in path for web extensions

[sandy081]

VS Code for the Web is not loading some resources in the extension with web target platform

Eg: https://ms-toolsai.vscode-unpkg.net/ms-toolsai/jupyter/2023.4.1011131224/extension/out/extension.web.bundle.js?target%3Dweb.

This seems to work fine with a simple extension sandy081.999-pse published with web target platform. I do not know why it is breaking for above extension path.

When target platform web is introduced, we decided to go with the query parameter route considering that extensions will handle URIs correctly given the vscode.uri util. It seems we need to make changes how extension paths are handled to fix this.

CC @joaomoreno

[sandy081]

@DonJayamanne Can you please share the extension that is not working for you when you published PSE for Web target? I have one with web target platform and it works for me -sandy081.999-pse

[jrieken]

When target platform web is introduced, we decided to go with the query parameter route considering that extensions will handle URIs correctly given the vscode.uri util.

I would suggest to reconsider this given that we didn't really think about this. We now discovered one issue, there is very likely more in our code base, and assuming all extensions use the uri utils is very bold

[DonJayamanne]

Can you please share the extension that is not working for you when you pu

@sandy081
Here it is

Same version here #180525 (comment)

Version 2023.4.1011131224 from the marketplace

[joaomoreno]

For context, @jrieken says:

Ok, we then need to make changes how extension paths are handled. Today /foo/bar/baz/hello.txt?something isn’t considered a child of /foo/bar/?something and therefore all those extensions run as “null extensions”. that doesn’t just affect proposed API but also logging, telemetry, storage, mementos etc pp (edited)

We construct a trie data structure for extension path lookups. For that it is just a constructor option and it ignores query and fragment. However, there might more issues because I assume this is reflected all the way into the Extension.extensionUri API and I don’t know if all extensions are expecting a query part (edited)

[joaomoreno]

Two paths forward:

• We push towards a fix in VSCode, by having the trie not bail out on query params. But as @jrieken mentioned, we might find other places in the product that do not play well with query params in URIs, further down the flow.
• We allow using the path component to specify platforms in vscode-unpkg.

By now it's rather clear that the latter is the lowest hanging and lowest risk change.

[sandy081]

We allow using the path component to specify platforms in vscode-unpkg.

With this we would also need migration on the client side - to adopt existing installed extensions to use the new path.

[joaomoreno]

This is why I renamed and left this issue open. 😉