typescript-language-features doesn't seem to work on virtual file system

[aslatter]

• VSCode Version: 1.27.2
• OS Version: Windows 10 Version 1803

Steps to Reproduce:

1. Install the MemFS demo file system provider extension, follow the instructions to set up a MemFS folder
2. Add a new TypeScript file to the MemFS folder, write some example TypeScript code

I expected that auto-complete, signature help, and hover information would be available in the TypeScript file, but it was not. Basic syntax-highliting and some snippets were available, however.

Does this issue occur when all extensions are disabled?: N/A

I thought I had seen a bug for this but I can't find it anymore. Currently extensions/typescript-language-features/src/typescriptServiceClient.ts has explicit checks in the vscode.Uri to block non-file schemes (normalizedPath and getWorkspaceRootForResource). I'm not sure what else needs to be fixed if those checks are removed.

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• vscode.workspace.findFiles doesn't search in user provided file systems (#55982)
• Startup issue, file system provider and new workspace – no provider for memfs:/ (#57989)

[aslatter]

FYI - I'm not interested specifically in MemFS - however we're working on a file system provider we intend to use to offer up a read-only view of TypeScript files for remote viewing and debugging. Having language server support for these would be a big help for us in this.

[DemonOne]

I ran into this issue just now trying to use python language support with the virtual file system example, same thing happens, no completions and populating python.autoComplete.extraPaths doesn't help.

[aslatter]

From digging around in the vscode sources and debugging, the problem with the TypeScript language-service is specific to it - it goes out of its way to prevent itself from working over a virtual file-system.

Any extension which does not support vfs likely needs its own fix, specific to that extension, so if the python support is provided by an extension you may want to file an issue to that extension as well.

[julien-moreau]

Hey Matt Bierner (@mjbvz)
Do you have any news about this issue? Saying "no" is a completely acceptable answer :)
Thanks

[mjbvz]

Julien Moreau-Mathis (@julien-moreau) This is not scheduled and there's no active eta. There's a risk of breaking existing extensions like live share and after almost half a year this issue has zero upvotes

[julien-moreau]

Matt Bierner (@mjbvz) thanks for your answer :)
Looks ok to me to be a feature request.
Do you have any suggestion or a tip today to activate these languages features? I guess live share has a tip or is it working on the "file" scheme?

[foorschtbar]

Julien Moreau-Mathis (@julien-moreau) This is not scheduled and there's no active eta. There's a risk of breaking existing extensions like live share and after almost half a year this issue has zero upvotes

I have the same problem...

[terrelln]

Another +1 for this issue. The FileSystemProvder API is a great idea... But it needs first class support if it is going to be more than a toy. Lacking Typescript language support isn't a great sign, because if Microsoft isn't going to make the effort to support FileSystemProviders, who is?