Asynchronous TS plugin example #2
Conversation
| } | ||
| info.languageServiceHost.getScriptVersion = (fileName) => { | ||
| if (!initialized && fileName.endsWith('.mdx')) { | ||
| return 'initializing...' |
There was a problem hiding this comment.
I think this can be any string, as long as it’s not numeric, right?
| return 'initializing...' | |
| return 'initializing…' |
| if (getProjectVersion) { | ||
| info.languageServiceHost.getProjectVersion = () => { | ||
| if (!initialized) { | ||
| return getProjectVersion() + ',initializing...' |
There was a problem hiding this comment.
I think this is rendered in the VS Code status bar, right?
Let’s use a real ellipsis and proper spacing.
| return getProjectVersion() + ',initializing...' | |
| return getProjectVersion() + ', initializing…' |
There was a problem hiding this comment.
This will not be shown to the user. The purpose of patching getProjectVersion is just so that after the initialization is completed, the language service knows that the cache needs to be refreshed.
| ], | ||
| "typescriptServerPlugins": [ | ||
| { | ||
| "name": "typescript-plugin-bundled", |
There was a problem hiding this comment.
Does this have to come from node_modules? Or can we also point to a relative path?
There was a problem hiding this comment.
It must come from node_modules and can't be a relative path.
| } from '@volar/typescript' | ||
| import {createFileProvider, resolveCommonLanguageId} from '@volar/language-core' | ||
| import {getLanguageModule} from '@mdx-js/language-service' | ||
| import {loadPlugins} from '../../language-server/lib/configuration.js' |
There was a problem hiding this comment.
It might be nicer to move this function into @mdx-js/language-service. Although it’s not ideal loadPlugins depends on Node.js APIs.
| @@ -0,0 +1,107 @@ | |||
| /** | |||
There was a problem hiding this comment.
I think it would be nice to publish this as @mdx-js/typescript-plugin, but we can do that later.
Co-authored-by: Remco Haszing <remcohaszing@gmail.com> Signed-off-by: Johnson Chu <johnsoncodehk@gmail.com>
Co-authored-by: Remco Haszing <remcohaszing@gmail.com> Signed-off-by: Johnson Chu <johnsoncodehk@gmail.com>
Co-authored-by: Remco Haszing <remcohaszing@gmail.com> Signed-off-by: Johnson Chu <johnsoncodehk@gmail.com>
Co-authored-by: Remco Haszing <remcohaszing@gmail.com> Signed-off-by: Johnson Chu <johnsoncodehk@gmail.com>
Co-authored-by: Remco Haszing <remcohaszing@gmail.com> Signed-off-by: Johnson Chu <johnsoncodehk@gmail.com>
Co-authored-by: Remco Haszing <remcohaszing@gmail.com> Signed-off-by: Johnson Chu <johnsoncodehk@gmail.com>
Volar 2 offers various small enhancements. Co-authored-by: Remco Haszing <remcohaszing@gmail.com>
Before Volar, the ESM, JSX, and markdown parts of virtual files had to map character by character, with parts shadowed by whitespace characters. This was still how virtual files were built. However, because of how Volar mappings work, this is unnecessary. This change overhauls how virtual files are generated. This leads to more flexibility of virtual files, meaning we can omit or inject content. This is already leveraged in several ways: - Markdown nodes in MDX are represented by TypeScript fragments. This provides compatibility with JSX elements that require children on a type level. - Markdown text nodes in MDX are represented by TypeScript JSX expressions containing an empty string. - JavaScript chunks are represented in the virtual markdown files as HTML comments.
Formatting embedded content causes too much unexpected behaviour in MDX files. Closes mdx-js#355
If the Props type isn’t defined, it now falls back to an empty shape instead of any. Also all keys are marked as readonly. As a result, props are no longer represented using the string `Props`, but an inline representation of the shape of the props. Given that the upcoming support for an MDX layout also requires a patched version of `Props`, this new setup is more consistent. Also the `props` description now contains a link to the props page on the MDX website.
Signed-off-by: Mateusz Burzyński <mateuszburzynski@gmail.com>
`addOffset` now handles generating content based on the original content and offsets.
This can be used for example for bracket matching.
|
Can you retarget this PR to https://github.com/mdx-js/mdx-analyzer? I think that would be better for visibility and discussions. I’m not even sure of the target repo of a PR can be changed. |
MDX allows to use indentation. In regular markdown however, indented code represents a code block. To work around this, all virtual markdown chunks are now dedented. This may change the semantic meaning of certain markdown, but it doesn’t affect editor features as far as I’m aware.
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
|
Here it's: mdx-js#371 |
See vuejs/language-tools#3789
Different from vue langauge tools, mdx-analyzer needs to load the plugin asynchronously, so
decorateLanguageServiceanddecorateLanguageServiceHostare called lazily.