fix(website): render GFM tables in .mdx pages - #1447
Open
Cedric Vidal (cedricvidal) wants to merge 2 commits into
Open
Cedric Vidal (cedricvidal) wants to merge 2 commits into
Cedric Vidal (cedricvidal) wants to merge 2 commits into
Conversation
Every table in a .mdx guide currently renders as literal pipe characters. Five published pages are affected — importing-skills, importing-mcp-servers, defining-profiles, importing-extensions and managing-task-prompts — showing readers raw "| Type | When to use |" text instead of a table. Astro applies its built-in GFM support to .md only. MDX inherits the configured `remarkPlugins` — the HTTP snippet plugin demonstrably runs on .mdx pages — but not that built-in, so tables are never parsed there. Listing remark-gfm explicitly restores them. Renaming the affected pages to .md would have been the smaller change, and is wrong: those five are exactly the pages that also use ```http fences, which the snippet plugin turns into a Starlight <Tabs> group. That JSX only renders in .mdx, so the rename trades broken tables for broken tabs. Verified both ways before choosing: in .md a table renders and the tabs vanish; in .mdx with this fix, both render. remark-gfm was already resolved in the lockfile as a transitive dependency, so this promotes it to a direct one and adds no new packages. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 507f8ebd-cc32-489c-afca-8941c5f8dba1
Member
|
Cedric Vidal (@cedricvidal) is it a duplicate of my own #1429? |
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Every table in a
.mdxdocumentation page renders as literal pipe characters. Five published guides are affected, showing readers raw| Type | When to use |text where a table should be:guides/importing-skillsguides/importing-mcp-serversguides/defining-profilesguides/importing-extensionsguides/managing-task-promptsCause
Astro applies its built-in GFM support to
.mdonly. MDX inherits the configuredremarkPlugins— the HTTP snippet plugin demonstrably runs on.mdxpages — but not that built-in, so tables are never parsed there. Listingremark-gfmexplicitly restores them.Why not just rename the pages to
.mdThat was the smaller change and it is wrong. Those five pages are exactly the ones that also use
```httpfences, whichremark-http-snippetsturns into a Starlight<Tabs>group. That JSX renders only in.mdx, so renaming trades broken tables for broken tabs.Verified both ways with a minimal page containing a table and an
httpfence:.md.mdxbefore.mdxafterVerification
All five guides now render tables and keep their tabs, and no page on the site is left with a literal-pipe paragraph:
<tr>defining-profilesimporting-extensionsimporting-mcp-serversimporting-skillsmanaging-task-promptsSite-wide after the change: 0 pages with unparsed tables, 203 pages built,
pnpm testgreen.Dependency note
remark-gfm@4.0.1was already resolved in the lockfile as a transitive dependency, so this promotes it to a direct one. The lockfile change is three lines and adds no new packages.