chore(i18n, mdx): enable the v4 strict MDX flag and guard admonition syntax - #4725
Open
thetaPC wants to merge 1 commit into
Open
chore(i18n, mdx): enable the v4 strict MDX flag and guard admonition syntax#4725thetaPC wants to merge 1 commit into
thetaPC wants to merge 1 commit into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
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.
Issue URL: internal
What is the current behavior?
Docusaurus still applies the MDX v1 compatibility shims:
mdx1Compat.comments,.admonitionsand.headingIdsall default totrue. Nothing on this branch relies on them any more, so they are no-ops that hide regressions. A page reintroducing<!-- comment -->,:::note Titleor{#heading-id}builds fine today and breaks on the v4 upgrade instead.What is the new behavior?
The jp companion to #4723.
future.v4.mdx1CompatDisabledByDefault: true, which flips all three tofalse. One functional line; the rest of that diff moves the existingfuturecomment so each key is documented above itself.Two of the three now fail the build outright. The third does not:
:::note My Titlestops being a directive and renders as literal:::notetext on the page, with no warning and a successful build. Thecheck-admonitionsaction covers that one case, on the files each PR changes.Does this introduce a breaking change?
Other information
The action is byte-identical to the one on
main, so it is not re-tested here. Its behavior was proven on #4724, a throwaway PR that plants one legacy title alongside four forms that must not be flagged: the failing check run reports only the legacy one, and the annotation lands on the offending line. This branch has 0 legacy admonition titles, so the check lands green, and on this PR it reportsNo MDX files changed.Docusaurus's own
unusedDirectiveswarning is already enabled and catches:::typo, but it cannot catch this: it visits directive nodes, and:::note My Titleparses to a plain paragraph. There is no node to visit, which is why the check has to work on the raw text before parsing.The build produces 744 pages and 407 warnings, identical to the same tree with the flag off: nothing introduced, nothing resolved.
How to test
npm run buildand confirm it completes<!-- test -->to any page underdocs/and rebuild. It should now fail withCould not parse expression with acornorUnexpected character !, where before it built silently. Revert.Archived v5 to v7 are not built by default. They were verified with the flag on in #4717 against content identical to this branch, building 460 v5, 307 v6, 310 v7 and 326 v8 pages. To repeat it:
versions.jsonto["v8", "v7", "v6", "v5"]npx docusaurus clear(clearing only.docusaurusleaves the rspack cache)npm run build