[code-infra] New broken links checker

[Janpot]

See https://github.com/mui/mui-public/pull/832

[pkg-pr-new[bot]]

vite-css-base-ui-example

pnpm add https://pkg.pr.new/mui/base-ui/@base-ui-components/react@3080

pnpm add https://pkg.pr.new/mui/base-ui/@base-ui-components/utils@3080

commit: 909372a

[mui-bot]

Bundle size report

Bundle	Parsed size	Gzip size
@base-ui-components/react	0B(0.00%)	0B(0.00%)

Details of bundle changes

---

Check out the code infra dashboard for more information about this PR.

[netlify[bot]]

✅ Deploy Preview for base-ui ready!

Name	Link
🔨 Latest commit	cbbcf5084a841ba107501a2065b1649c17347274
🔍 Latest deploy log	https://app.netlify.com/projects/base-ui/deploys/6900f044b2a5af00084b6768
😎 Deploy Preview	https://deploy-preview-3080--base-ui.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[netlify[bot]]

✅ Deploy Preview for base-ui ready!

Name	Link
🔨 Latest commit	909372a0bddf3a7b7ef525bffd0ca69aa2e4f0f4
🔍 Latest deploy log	https://app.netlify.com/projects/base-ui/deploys/69024939c86db5000878922b
😎 Deploy Preview	https://deploy-preview-3080--base-ui.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[Janpot]

One slight drawback is that local/dev assertion time is significantly longer, but I don't see how we could improve it. 🤷

What do you mean with local/dev assertion time? The crawler runs in under 3 seconds, and only during docs:build.

[LukasTy]

What do you mean with local/dev assertion time? The crawler runs in under 3 seconds, and only during docs:build.

Crawler, yes, but the app needs to be built before running it. On base-ui, it's not very problematic as build completes in <30s (at least on my machine), but on bigger projects, it might be slightly annoying. To clarify, I'm referring to the difference, that currently broken link check could be run on demand, without building the documentation site. 😉 But in any case, the added security is worth the tradeoff. 👌

[Janpot]

Right, to note that the crawler could be easily run against your running dev version. Albeit by altering the script a bit (remove startCommand and repoint host to your local instance)

But in any case, the added security is worth the tradeoff.

The improvement is in covering more ground, not just links in the markdown files but anything on the site will be checked. I can see though how it causes more friction for a certain class of links. Perhaps we need to retain both checks?

[LukasTy]

Right, to note that the crawler could be easily run against your running dev version. Albeit by altering the script a bit (remove startCommand and repoint host to your local instance)

But the development version doesn't have pre-rendered pages; I'm not sure if there is room for improvement here. 🤷

The improvement is in covering more ground, not just links in the markdown files but anything on the site will be checked. I can see though how it causes more friction for a certain class of links. Perhaps we need to retain both checks?

I'm not sure if this is relevant for the size of the base-ui repo. Besides, the feedback cycle should be relatively quick as it runs on Netlify. One minor gripe, that assertions are tied to the deployment pipeline. 🙈

[Janpot]

One minor gripe, that assertions are tied to the deployment pipeline. 🙈

Yeah, I agree, but it has reasons:

1. it's the place where we're really doing a full build of the docs (markdown generation and all *)
2. it gives us the opportunity, like we do for core/X, to add a static file describing all available targets. This allows us to check all core links on X, and all X links on core without having to crawl external content.

* markdown link crawling isn't there yet, but planned