How does type checking work in the VSCode Extension for MDX with experimentalLanguageServer enabled?

[thomfoolery]

We're trying to improve the content authoring experience for documentation written in MDX.

The eslint-plugin-mdx has helped a lot, but we expected the VS Code Extension for MDX to type check our component props, and other IntelliSense features like autocomplete. This would really help our authors understand what might be wrong when they are writing interactive tutorials.

We have enabled mdx.experimentalLanguageServer but we're not seeing any IntelliSense features. We're questioning if maybe we haven't configured or setup our project properly, but are struggling to figure out how/where to start debugging.

We imagine the mdx-analyzer is not aware of where the source code is for the components we provide through a MDXProvider and therefor can not provide type checking or introspection abilities.

Is there away providing additional information to the extension/language server to provide better IntelliSense assistance to our authors?

Here are the relevant issues I've uncovered

• MDX +TypeScript support (github discussion)
• Typescript - support for MDX (github issue)
• ESLint MDX - type check React component props (github issue)
• MDX Analyzer - Support components (github issue)

[remcohaszing]

I’ve just released version 1.5.0 of the MDX extension. Its IntelliSense got a complete rewrite, but I think you’ll run into the same issue. IntelliSense works, but it’s subtle. I think you want mdx-js/mdx-analyzer#352 to be implemented.

[karlhorky]

I have a wish that we can write TypeScript codes in .mdx directly without jsdoc.

That makes sense - I think that would be a common ask from the community. JSDoc is nice as an alternative, but has non-insignificant downsides: verbose, harder to use, less common (harder to find resources for), doesn't have all features of TS without extra .d.ts files.

---

That's not what I and @thomfoolery are currently looking for though - as mentioned above, I'm looking for a way to type check usages of the React components that are passed to MDX via the MDXProvider.

As @thomfoolery also guessed, it is possibly a limitation of mdx-analyzer that this doesn't work:

We imagine the mdx-analyzer is not aware of where the source code is for the components we provide through a MDXProvider and therefor can not provide type checking or introspection abilities

[remcohaszing]

Support for type checking the components prop is tracked in mdx-js/mdx-analyzer#260 and is almost done. At first I thought this was going to include support for the MDX provider, but in the end it won’t. I created a new issue for the MDX provider mdx-js/mdx-analyzer#399.

[remcohaszing]

The reason there’s not CLI yet for MDX type checking is because:

• I haven’t looked into it yet.
• I want to stable editor support before making CI fail for people.
• I want this to interoperate with other Volar based language tooling. I imagine a single Volar CLI would be useful for type checking a project that combines Astro, Emver, MDX, Svelte, Vue, and/or other frameworks that might leverage Volar in the future.

[karlhorky]

Totally makes sense, thanks for your work here and looking forward to your implementation!

If I was to try to get a small, naive MVP Node.js CLI for a type checker for .mdx for myself (not covering edge cases), do you have a suggestion for how to go about this?

Would you suggest something like the following? (maybe I'm missing a step)

1. Extract components object from inside MDXProvider prop to export
2. Compile MDX using @mdx-js/mdx
3. Run type checking using tsc on the compiled file(s) (maybe these are VFiles?)
4. Delete the compiled file(s)

(also open to options which are more hacky / require fewer steps, eg. augmenting @types/mdx)

[remcohaszing]

I really strongly recommend to base that on Volar. I know there’s code for doing something like that. There’s already vue-tsc, maybe something for Astro too. I just haven’t gotten to it for MDX yet.