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.jsconstredirects=[{from: '2008/12/old url with spaces',to: '/2008/12/new-url/'},// ...13 entries];exportdefaultfunctionredirectsTemplate(){returnredirects.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.mjsredirects object |
| DomStack | None — manual template required |
Proposed solution
Option A: Configuration-based redirects in global.vars.js (recommended)
// src/global.vars.jsexportdefault{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.