Package pages are live on mpak.dev today:
$ curl -s -o /dev/null -w "%{http_code}\n" https://mpak.dev/packages/@nimblebraininc/echo
200
After the cutover in #164, mpak.dev is GitHub Pages and registry.mpak.dev serves the app. All 41 package URLs plus /bundles need to reach their new home, or they answer with the Pages 404.
Two things make this harder than the /sitemap.xml and /feed.xml items already listed in #164's deploy-coupling section:
- GitHub Pages cannot issue a 301. Serving a page at the old path or a meta-refresh shim passes far less link equity than a real redirect, so the mechanism likely has to sit in front of Pages (CloudFront) rather than in
mpak-web.
/bundles is linked from the marketing site, the docs, and CLI output, per the comment in apps/web/src/routes/bundles.tsx. The app redirects /bundles to / on the new host, but nothing catches the old host's /bundles.
mpak-web PR #5 stands up the Pages deploy and touches no routing, so this is unowned right now.
Add /packages/* and /bundles to #164's deploy-coupling list with a named mechanism, and confirm it before DNS moves.
Package pages are live on
mpak.devtoday:After the cutover in #164,
mpak.devis GitHub Pages andregistry.mpak.devserves the app. All 41 package URLs plus/bundlesneed to reach their new home, or they answer with the Pages 404.Two things make this harder than the
/sitemap.xmland/feed.xmlitems already listed in #164's deploy-coupling section:mpak-web./bundlesis linked from the marketing site, the docs, and CLI output, per the comment inapps/web/src/routes/bundles.tsx. The app redirects/bundlesto/on the new host, but nothing catches the old host's/bundles.mpak-webPR #5 stands up the Pages deploy and touches no routing, so this is unowned right now.Add
/packages/*and/bundlesto #164's deploy-coupling list with a named mechanism, and confirm it before DNS moves.