Repository navigation
Provide TypeScript 7.1 content mapper #533
Description
TypeScript introduced the new content mapper API in microsoft/typescript-go#4712. This will be released in TypeScript 7.1. I built mdx-content-mapper as a proof of concept and to provide feedback to the TypeScript team. I took the Volar based MDX virtual content from this repo, and iterated on top of that. I would say it’s already more stable and more feature complete than we ever had in mdx-analyzer.
We can actually use content mappers with tsc, which is a much requested feature and also really convenient for testing. 😄
I intend to incorporate the content mapper inside the mdx-analyzer repo as the @mdx-js/content-mapper package. I intend to do this following a couple of steps, where the first ones involve the removal of TypeScript support based on Volar. I do want to keep Volar and the language server to support editor features provided by vscode-markdown-languageservice.
- Remove
@mdx-js/typescript-pluginfrom the project. It will no longer be supported. I do not feel the need to deprecate this yet. People may still want to use this in web projects with TypeScript 6 until TypeScript 7 can be used in the browser with a content mapper. - Remove the full TypeScript language service support from
@mdx-js/language-server. -
Remove the TypeScript parts fromSuperseded by Replace vscode-languageservice-markdown with our own implementation #537@mdx-js/language-service. Most logic in this project currently involves TypeScript support. - Remove the dependency of
@mdx-js/language-serverontsconfig.json. It currently reads remark plugins from this file. We can hardcode sane defaults, or make it configurable using settings if this turns out necessary. This only affects what we pass tovscode-markdown-languageservice. - Incorporate
@mdx-js/content-mapperinto themdx-analyzerrepository. - Add
@mdx-js/content-mappersupport to the VSCode extension.
Considering microsoft/TypeScript#63703, I believe it will be nice if @mdx-js/content-mapper and our VSCode extension are released alongside TypeScript 7.1 RC. During the 7.1 Beta period, users can try mdx-content-mapper instead.
Activity
github-actions commentedon Aug 28, 2026
Hi! This was marked as ready to be worked on! Note that while this is ready to be worked on, nothing is said about priority: it may take a while for this to be solved.
Is this something you can and want to work on?
Team: please use the
area/*(to describe the scope of the change),platform/*(if this is related to a specific one), andsemver/*andtype/*labels to annotate this. If this is first-timers friendly, addgood first issueand if this could use help, addhelp wanted.Remove @mdx-js/typescript-plugin (#534)
wooorm commentedon Aug 30, 2026
the name
@mdx-js/content-mapperdrops the important typescript-related concept; maybe that's fine, but have you considered alternatives? Is the idea that it works in other tools than TS?remcohaszing commentedon Sep 1, 2026
I think that’s a fair question. Work is also being done in other ecosystems. Let’s look at their package names. Note that everyone is still working on this. All of these names might still change at any point. Let me know if I forgot any.
@astro/ts-content-mapperfeat(ts-content-mapper): add a TypeScript content mapper for .astro files withastro/astro#17835@vue/content-mapperfeat: content mapper (v4 alpha) vuejs/language-tools#6170ember-content-mapper(https://github.com/NullVoxPopuli/ember-content-mapper)svelte-typescript-content-mapperfeat: typescript 7 content mapper sveltejs/language-tools#3111So at this point, there’s a 50/50 split of packages that include
typescript/tsin the content mapper package name.I expect the term content mapper to become well-known in the frontend ecosystem, similar to a webpack loader or the
@typesscope.I considered the name
@mdx-js/typescript-content-mapper, but I think it’s too long. I also considered@mdx-js/ts-content-mapper, but the abbreviatedts-prefix just doesn’t look to great to me. These are just personal opinions, not technical facts.What I would personally like, is for TypeScript to suggest a best practice in their docs.
No. But if there’s user demand, I can imagine the MDX content mapper type checking
astro/vue/ etc. code blocks using those other content mappers in a future version.wooorm commentedon Sep 1, 2026
...with the note that “loader” is very ambiguous, and content mapper pretty unique.
I think I'd prefer some branding in there, and i agree that
typescript-gets long, so I'd go withts-from those.Some more ideas:
tsgo-content-mapper, using suffixes instead of prefixes (content-mapper-ts), dropping thecontent-so@mdx-js/ts-mapper?remcohaszing commentedon Sep 1, 2026
I think the term
tsgois irrelevant. This is a temporary term that will be used less as more people update to TypeScript 7.A suffix makes it sound like a library to me. This reminds me of the good ol’ days when we called libraries jQuery.js, React.js, etc.
This type of project is called a content mapper. Any form of abbreviation, such as omitting
contentormapper, isn’t used elsewhere. I think that would make it less discoverable and makes it stand out from other content mappers.remcohaszing commentedon Sep 16, 2026
I feel like we may have an easier time reimplementing the features we want from
vscode-markdown-languageservicebased on micromark than maintaining Volar mappings. MDX simply isn’t markdown. Notably it has different whitespace rules. And IMO diagnostics specifically are best handled by mdxlint, so the user has both editor and CLI support.Remove TypeScript support from language server (#538)