Migrate to Volar #388
Migrate to Volar #388
Conversation
|
| @@ -161,12 +163,12 @@ export class Extracted { | |||
| * on the view type. | |||
| */ | |||
| abstract class TokenView { | |||
| #tokens: Token[]; | |||
| tokens: Token[]; | |||
There was a problem hiding this comment.
This is an awful hack so that I can generate Volar CodeMapping objects from Tokens.
A better solution would be to have the extractor be able to generate CodeMappings itself...
| "command": "marko.debug.showScriptOutput", | ||
| "title": "Show Extracted Script Output", | ||
| "category": "Marko (Debug)" |
There was a problem hiding this comment.
Small QOL improvement, could be split into a separate PR
| // TODO: Is this necessary? | ||
| // provideDocumentSymbols(document, token) { | ||
| // if (token.isCancellationRequested) return; | ||
| // return worker(document, (virtualCode) => { | ||
| // return provideDocumentSymbols(virtualCode); | ||
| // }); | ||
| // }, |
There was a problem hiding this comment.
I'm probably missing something - but I wasn't sure if Marko specific document symbols were still necessary and that couldn't be provided by TS or HTML.
| import type { Diagnostic } from "@volar/language-server"; | ||
| import { TextDocument } from "vscode-languageserver-textdocument"; | ||
|
|
||
| export function enhanceDiagnosticPositions( |
There was a problem hiding this comment.
This is necessary to ensure we show diagnostics. Volar doesn't seem to display them when they are larger than the code mappings, so I clamp the diagnostics to the most reasonable code mapping we can find...
There is almost certainly a better way, but this seems good enough for now?
| // This will cause the plugin to be called again, so we check that the extension is not already added. | ||
| ps.setHostConfiguration({ | ||
| extraFileExtensions: extraExtensions.concat( | ||
| Processors.extensions.map((extension) => ({ |
There was a problem hiding this comment.
I notice we're using Processors here, but extractors elsewhere... I'm wondering if we should be using Processors in the MarkoVirtualCode?
This is a clean version of #294.
This is a proof of concept that shows what it might look like if the Marko Language Tools migrated to Volar as a base.
This proof-of-concept is roughly complete for our purposes, we've been using it for the past few months.
Motivation and Context
Migrating to Volar resolves the issues we've had with the VSCode plugin on Windows (#240), and it improves the responsiveness of the plugin on Windows.
Why Volar?
MarkoFile->MarkoVirtualCodePlugin->LanguageServicePluginTODO
This is fairly untested, I mostly hacked it up so it works with our project.
Questions