Static output always writes `foo.html`, so trailing-slash URLs 404 on hosts like GitHub Pages
Les mainteneurs répondent en général sous 1 jour
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Accessibilité débutants
- 42/100
- Type d'issue
- Fonctionnalité
- Clarté
- Plutôt claire
- Activité
- Active
- Stack technique
- typescript, vite
- Domaine
- build-system, devops
Piste de recherche
Start with packages/void/src/prerender-render.ts, especially outputFileForPath, and compare its current path mapping with the GitHub Pages behavior described in the issue. Review the dev server's trailing slash redirect and the interaction with cloudflare.assets.html_handling in issue #580 before proposing the setting. Done means the output option, redirect behavior, and Cloudflare interaction have a documented and agreed direction.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
What happens
With output: 'static', every prerendered page except / is written as <path>.html (outputFileForPath in packages/void/src/prerender-render.ts). A section with an index page and child pages, such as
pages/posts/index.island.tsx
pages/posts/hello.md
builds to
dist/client/posts.html
dist/client/posts/hello.html
There is no option to write posts/index.html instead. Seen with Void 1.3.0; outputFileForPath is unchanged on current main.
Why it matters
The SSG guide says the static output works for self-hosting and covers hosting dist/client/ yourself. GitHub Pages doesn't map a trailing-slash URL to foo.html. I published the same layout on GitHub Pages (honbin/github-pages-trailing-slash, checked on 2026-10-29):
| URL | foo.html layout (Void today) |
foo/index.html layout |
|---|---|---|
/posts |
200 | 301 to /posts/ |
/posts/ |
404 | 200 |
/posts/hello |
200 | 301 to /posts/hello/ |
/posts/hello/ |
404 | 200 |
So with Void's output, every trailing-slash URL except / returns 404, including /posts/, where posts.html sits next to a posts/ directory without an index.html. That breaks any site whose links and canonical URLs end with a slash. Cloudflare resolves both foo.html and foo/index.html (as noted in prerender-render.ts), so this doesn't show up with Void's own deploys.
Current workaround
We move the files in CI after vp build:
find dist/client -name '*.html' ! -name index.html ! -name 404.html | while read -r file; do
mkdir -p "${file%.html}"
mv "$file" "${file%.html}/index.html"
done
Related behavior
The dev server redirects /posts/ to /posts with a 301, so dev assumes URLs without a trailing slash. A directory-style output would probably need the dev redirect to follow the same choice.
Question
Would you be open to an option for directory-style static output (for example, a trailingSlash-like setting next to output: 'static')? Open points I can see:
- the setting's name and where it lives
- whether the dev server redirect follows it
- how it combines with
cloudflare.assets.html_handling(#580)
Happy to send a PR once the direction is clear.
- Langage dominant
- TypeScript
- Étoiles
- 580
- Forks
- 56
- Merge moyen
- 12 h 10 min
- PR mergées (30 j)
- 163
Préparer son environnement
Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de voidzero-dev/void
-
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
voidzero-dev/void#645 ·
Les mainteneurs répondent en général sous 1 jour
-
void deploy cannot deploy a Worker with no URL after its first deploy, and --atomic refuses itOuverte
Difficulté 4/5 1-2 jours Accessibilité débutants 48/100
voidzero-dev/void#644 ·
Les mainteneurs répondent en général sous 1 jour
-
React: `action()` and `router.visit()` never resolve when awaited in a transitionPeut-être pris @cpojer l’a pris aujourd’hui. Ouverte
voidzero-dev/void#643 · 1 personne assignée ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 3/5 1-2 jours Accessibilité débutants 57/100
voidzero-dev/void#636 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 3/5 1-2 jours Accessibilité débutants 67/100
voidzero-dev/void#635 ·
Les mainteneurs répondent en général sous 1 jour
Toutes les issues de voidzero-dev/void
Issues similaires
-
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
components-web-app/docs#307 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
localstack/localstack-mcp-server#112 ·
Les mainteneurs répondent en général sous 1 jour
-
area:frontend kind:bug priority:p1 ready
Difficulté 2/5 1-3 heures Accessibilité débutants 85/100
Les mainteneurs répondent en général sous 1 jour
-
bug ready-for-agent
Difficulté 2/5 1-3 heures Accessibilité débutants 73/100
PhyberApex/kuroshiro#1687 ·
Les mainteneurs répondent en général sous 1 jour
-
Performance (Web Vitals) collector: LCP/FCP from background tabs are not discarded, inflating p75Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 74/100
umami-software/umami#4720 ·
Les mainteneurs répondent en général sous 3 jours