This issue was originally identified in voxpelli/voxpelli.github.com#32
Problem
Sites migrating from other static site generators often need redirect pages for old URLs. DomStack has no built-in mechanism for declaring redirects. Users must create a custom template that manually generates meta-refresh HTML pages for every redirect mapping — boilerplate that every migrating site writes independently.
Expected: A declarative way to specify redirects that DomStack processes into the correct output — HTML meta-refresh pages for static hosting, _redirects for Netlify, or vercel.json entries for Vercel.
Actual: Users must write a custom .template.js file that returns TemplateOutputOverride[] with hand-crafted HTML for each redirect.
Current behavior / workaround
// src/redirects.template.js
const redirects = [
{ from: '2008/12/old url with spaces', to: '/2008/12/new-url/' },
// ...13 entries
];
export default function redirectsTemplate () {
return redirects.map(({ from, to }) => ({
outputName: `${from}/index.html`,
content: `<!DOCTYPE html>
<html>
<head>
<meta http-equiv="refresh" content="0;url=${escapeXml(to)}" />
<link rel="canonical" href="${escapeXml(to)}" />
</head>
<body>
<p>Redirecting to <a href="${escapeXml(to)}">${escapeXml(to)}</a></p>
</body>
</html>`,
}));
}This approach has several drawbacks:
- Every project reinvents the same HTML boilerplate (including XSS-safe escaping)
- No SEO-friendly HTTP status codes — meta-refresh is client-side only
- Redirect data is siloed in the template; other parts of the build can't access it
- No build-time validation that
to targets actually exist
What other SSGs provide
| SSG |
Redirect mechanism |
| Jekyll |
redirect_from frontmatter via plugin |
| Hugo |
aliases frontmatter field |
| Astro |
astro.config.mjs redirects object |
| DomStack |
None — manual template required |
Proposed solution
Option A: Configuration-based redirects in global.vars.js (recommended)
// src/global.vars.js
export default {
redirects: [
{ from: '/2008/12/old url/', to: '/2008/12/new-url/' },
],
};DomStack would generate an index.html with meta-refresh for each redirect, optionally generate a _redirects file for Netlify/Cloudflare Pages, and validate that to targets resolve to actual pages.
Option B: Per-page redirect_to frontmatter
For individual page moves, similar to Hugo's aliases.
Option C: Document the template pattern (minimum viable)
Add a "Redirects" cookbook section showing the template-based approach as a recommended pattern, including XSS-safe URL escaping and SEO notes. This can ship immediately while the framework-level solution is designed.
Supported redirect file formats
- Netlify/Cloudflare Pages
_redirects: /old-url/ /new-url/ 301
- Vercel
vercel.json: { "redirects": [{ "source": "/old/", "destination": "/new/", "permanent": true }] }
Recommendation: Option A for the primary solution; Option C as an immediate stopgap.
Problem
Sites migrating from other static site generators often need redirect pages for old URLs. DomStack has no built-in mechanism for declaring redirects. Users must create a custom template that manually generates meta-refresh HTML pages for every redirect mapping — boilerplate that every migrating site writes independently.
Expected: A declarative way to specify redirects that DomStack processes into the correct output — HTML meta-refresh pages for static hosting,
_redirectsfor Netlify, orvercel.jsonentries for Vercel.Actual: Users must write a custom
.template.jsfile that returnsTemplateOutputOverride[]with hand-crafted HTML for each redirect.Current behavior / workaround
This approach has several drawbacks:
totargets actually existWhat other SSGs provide
redirect_fromfrontmatter via pluginaliasesfrontmatter fieldastro.config.mjsredirectsobjectProposed solution
Option A: Configuration-based redirects in
global.vars.js(recommended)DomStack would generate an
index.htmlwith meta-refresh for each redirect, optionally generate a_redirectsfile for Netlify/Cloudflare Pages, and validate thattotargets resolve to actual pages.Option B: Per-page
redirect_tofrontmatterFor individual page moves, similar to Hugo's
aliases.Option C: Document the template pattern (minimum viable)
Add a "Redirects" cookbook section showing the template-based approach as a recommended pattern, including XSS-safe URL escaping and SEO notes. This can ship immediately while the framework-level solution is designed.
Supported redirect file formats
_redirects:/old-url/ /new-url/ 301vercel.json:{ "redirects": [{ "source": "/old/", "destination": "/new/", "permanent": true }] }Recommendation: Option A for the primary solution; Option C as an immediate stopgap.