You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add a CI check that flags relative links (./..., ../...) authored on index.md/index.mdx files in a PR diff. This is the exact bug class fixed in #375/PR #376 and tracked at larger scope in #377: any page built from a literal index.md/index.mdx file serves at its folder's own bare path with no trailing slash, so a relative link written on it resolves against the wrong parent folder in production. No existing static tool catches this, since both mint validate (doesn't check links at all) and this repo's own tools/triage-broken-links.py resolve relative links via filesystem-relative path math against the source file's disk location, not the live URL the browser actually resolves. The target genuinely exists on disk, so today's checks pass while the live link still 404s.
What to flag
On any changed index.md/index.mdx file in a PR:
A relative markdown link target starting with ./ or ../, inline ([text](./foo)) or reference-style ([n]: ./foo).
Same for raw HTML href values (<a href="./foo">, <Card href="../foo">), per the same rule documented in contribute/markdown-guide/links-in-docs.mdx.
What NOT to flag
MDX import statements (import Foo from './foo.mdx') — these are compile-time component imports, not page navigation links, and are unaffected by this bug.
Anything inside a fenced code block (```) or inline code span (`...`) — sample/documentation text, not a real link.
Already-root-relative (/...) or absolute (https://...) links.
Suggested shape
Model on the existing tools/ci/*-guard.py + .github/workflows/*-guard.yml family (e.g. version-frontmatter-guard.yml, landing-page-template-guard.yml) — warn or fail on the PR, don't auto-fix (unlike the auto-fix-workflow family, which has its own documented race-condition problem when multiple such workflows fire on the same push).
Summary
Add a CI check that flags relative links (
./...,../...) authored onindex.md/index.mdxfiles in a PR diff. This is the exact bug class fixed in #375/PR #376 and tracked at larger scope in #377: any page built from a literalindex.md/index.mdxfile serves at its folder's own bare path with no trailing slash, so a relative link written on it resolves against the wrong parent folder in production. No existing static tool catches this, since bothmint validate(doesn't check links at all) and this repo's owntools/triage-broken-links.pyresolve relative links via filesystem-relative path math against the source file's disk location, not the live URL the browser actually resolves. The target genuinely exists on disk, so today's checks pass while the live link still 404s.What to flag
On any changed
index.md/index.mdxfile in a PR:./or../, inline ([text](./foo)) or reference-style ([n]: ./foo).hrefvalues (<a href="./foo">,<Card href="../foo">), per the same rule documented incontribute/markdown-guide/links-in-docs.mdx.What NOT to flag
importstatements (import Foo from './foo.mdx') — these are compile-time component imports, not page navigation links, and are unaffected by this bug.```) or inline code span (`...`) — sample/documentation text, not a real link.index.md/index.mdx, confirmed in Relative links on release-notes index pages resolve to wrong URL (404) #375 — leaf pages resolve.//../links correctly)./...) or absolute (https://...) links.Suggested shape
Model on the existing
tools/ci/*-guard.py+.github/workflows/*-guard.ymlfamily (e.g.version-frontmatter-guard.yml,landing-page-template-guard.yml) — warn or fail on the PR, don't auto-fix (unlike the auto-fix-workflow family, which has its own documented race-condition problem when multiple such workflows fire on the same push).Related