feat: Allow embedded languages to utilise Svelte Intellisense in VSCode

[BOJIT]

Hello! This PR modifies the behaviour of the Svelte VSCode extension so that it activates for URIs that don't use the file:// scheme.
During standard extension usage, this makes no difference, as all Svelte files on disk will use the file:// scheme in their URI. However, enabling this support allows other extensions to use Svelte as an embedded language and still take full advantage of all of the Svelte extension's Intellisense.

This is handled in VSCode by a mechanism called Request Forwarding. In summary, VSCode will preprocess the custom language and create a virtual document that contains just the "Svelte" portion of the document. It can then invoke the Svelte extension on that virtual document.
The problem is that these virtual documents must use a unique URI scheme. As Svelte currently only activates on file:// scheme URIs, these requests will be dropped.

Example Use-Cases

• MDsveX syntax support: I've got a draft extension that adds MDsveX syntax support to VSCode.
• Custom languages built around Svelte. I know that Evidence BI maintain an extension that would benefit from Svelte intellisense/language features.

Potential Problems

Various parts of the extension (document snapshots, Typescript plugin) track the path of the file, not the URI. The conversion from path to URI in language-server/utils.ts will assume the file:// URI scheme when mapping between paths and URIs.

I am not familiar enough with the Svelte Language Server inner workings to fully know what the impact of supporting all URI schemes is. I've tested these modifications locally and the extension seems to behave identically to the original extension, but I would appreciate some advice from the maintainers on the impact of this change!

I'm also not sure if there are any URI schemes that should be explicitly disallowed by the extension. For example, http/https URIs ending in .svelte should probably not be recorded in document snapshots, as these might appear in webviews?

Next Steps

• My suggestion would be to only ever pass references to URIs in the language server, and only convert them into paths where speific APIs require it.
• Some of the Svelte-Kit specific Intellisense still doesn't work in virtual documents. Not sure where this gets tracked in the extension.

I'm hoping that this small change does not break any existing behaviour, as merging it will make any downstream embedded svelte extension's experience much better!

[dummdidumm]

Thanks for the detailed PR description! I'm ok to give this a try under the assumption that we're not going to jump through countless hoops to make it work 100% correctly for all use cases.

@jasonlyu123 any objections? Anything you think that might need to be adjusted / could go wrong?

[jasonlyu123]

We need some extra work with the unsaved "untitled" document. It is enabled in this PR but it seems like it sometimes causes crashes during completion. Might need to check if other stuff throws errors too.

[BOJIT]

Ah, good point! Didn't test untitled documents... Will have another look this week and check a few additional cases.

I imagine that I'll may need to raise some future PRs to fully support every embedded language forwarding feature, but the priority in this PR is to ensure that it doesn't break any existing Svelte extension features!

I'll do some further testing 👍

[BOJIT]

Okay, so after a bit more testing, I've realised that dealing with the untitled document.

The Untitled document is handled with a URI scheme of untitled. This means that with this PR, the Svelte language server is activated. The positive of this is that Untitled documents get completion/language server features, which they wouldn't otherwise. But unfortunately, any Svelte language features that require a filesystem-related call will crash. Some good notes here.

I couldn't find any official list in VSCode, but the URI schemes that could potentially be a problem are:

• untitled
• vscode
• http
• https
• git

Unfortunately, the scheme field in the DocumentSelector doesn't seem to allow more complex globs/exclusion patterns.

Best as I can tell, there are three options for properly supporting non-vdoc URIs:

1. Add a specific URI scheme that extensions can use: e.g.

documentSelector: [
    { scheme: 'file', language: 'svelte' },
    { scheme: 'embedded-svelte', language: 'svelte' },
],

Straightforward, but does limit only one extension to register a scheme provider at a time, so not ideal.

2. Modify the VSCode language client document selector to support more complex exclusion patterns for schemes.
   Potentially doable, I need to look more into what would be involved for this.

3. Make the Svelte Language Server handle non-file URIs safely.
   This is probably the most work, but does have some notable advantages.

• Full intellisense for "untitled" documents in VSCode (and possibly Git virtual docs too)
• Any editor can take advantage of request forwarding, not just VSCode.
• Ability to get "partial" Svelte extension support in VSCode for web. Currently the Svelte extension cannot be used there.

I'm happy to start exploring the last option and see how big of a change this would be. Let me know your thoughts on this.

[dummdidumm]

Sure, go ahead exploring 👍

making the language tools available on the web would be awesome, though I'm not sure how connected it really is to this work (see #1190 for more).

[jasonlyu123]

I think the problem isn't that TypeScript only handles physical files. The problem with completion is the inconsistency of the document URI schema. What is sent back in completionItem.data.uri is file: but the document is untitled:.