Integrate Volar

[remcohaszing]

Currently the build is failing, because pretty much every package related to VSCode has incorrect package exports.

• Volar handles the mapping between TypeScript and LSP.
• Volar handles the mapping between TypeScript and Monaco editor.
• Volar manages virtual files.
• Volar imports TypeScript directly. As a result, the Monaco editor integration now requires path to be polyfilled.
• It is no longer possible to pass compiler options in the Monaco editor integration.
• This adds editor features for YAML based on yaml-language-server. This has a problematic indirect dependency vscode-json-languageservice.
• Markdown features are now handled by vscode-markdown-languageservice. This will be contributed upstream to Volar soon.
• Markdown definitions are broken due to a bug in Volar.
• This adds remark-frontmatter with TOML and YAML support as well as remark-gfm by default unless specified otherwise in tsconfig.json.
• The language server now requires typescript.tsdk to be passed via initialization options.
• This adds support for debugging virtual documents using Volar labs.

Closes #168
Closes #284
Closes #295
Closes #298
Closes #301
Closes #341

[changeset-bot]

🦋 Changeset detected

Latest commit: b7186e4

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[remcohaszing]

I’m inclined to make some structural changes.

• @mdx-js/language-service
  • Expose getLanguageModule — This is what processes MDX files into virtual files
  • Remove resolveConfig — This removes the dependency on volar-service-markdown, volar-service-typescript, and volar-service-yaml.
  • Maybe rename the package to @mdx-js/volar-language-module and deprecate the old name.
• @mdx-js/monaco
  • Deprecate this in favour of building your own integration with @volar/monaco.
    • This gives the user more control to integrate other features.
    • This means we don’t have to deal with bundlers behaving different from Node.js
• @mdx-js/language-server
  • Move the resolveConfig logic from @mdx-js/language-service here.
• vscode-mdx
  • This won’t change.

Any thoughts on this @mdx-js/members @johnsoncodehk?

[johnsoncodehk]

A small thing is that when users integrates @volar/monaco with the resolveConfig() of @mdx-js/language-server, unused @volar/language-server dependencies will be installed, so leaving the resolveConfig() alone in @mdx-js/language-service may be better. But I don't think it's very important.

The rest of it looks great!

[remcohaszing]

The only thing that still needs to happen is verify our supported Node.js version matches Volar’s. Most of the unified ecosystem supports Node.js 16, which is already EOL. I recall Volar requires Node.js 18+, which means the language server would too.

[remcohaszing]

I just got confirmation Volar supports Node.js 16+, so this PR is ready as-is. I want to merge this soon, but I want to wait for MDX 3 for the release.

[JounQin]

Congratulation first!

but I want to wait for MDX 3 for the release.

Is there any news about MDX 3? I haven't noticed about it.

[ChristianMurphy]

Is there any news about MDX 3? I haven't noticed about it.

MDX 3 is a new major upgrading unified and remark, with new parser fixes and improved node types. Version 3 is planned for release this week.
It could be as soon as tomorrow mdx-js/mdx#2379 (comment)

[remcohaszing]

MDX 3 won’t as big a change as MDX 2. It’s mostly a lot of small changes that are technically breaking, but don’t affect most users.

[remcohaszing]

Released in vscode-mdx@1.5.0, @mdx-js/language-server@0.2.0, @mdx-js/language-service@0.2.0 🎉