sveltejs / sveltejs/kit

adapter-static: control “`route.html` or `route/index.html`” output separately from `trailingSlash` option

Open
#8,770 9 comments 9 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

p2-nice-to-have
Dominant language
JavaScript
Stars
20.8k
Forks
2.3k
Avg merge
1d 16h
Merged PRs (30d)
156

Description

Describe the problem

I’m generating a static site that I’m putting in an Amazon S3 bucket where it gets served by CDN. My app has a file path like this:

src/routes/foo/+page.js
src/routes/foo/+page.svelte
  1. When I build the site, I want this output as build/foo/index.html.
  2. I want it accessible to my users at /foo, with no trailing slash.

My understanding of the docs is that the only option I have to influence this is export const trailingSlash in my src/routes/+layout.js file. If I use either export const trailingSlash = 'never' or 'ignore', the build command produces build/foo.html. This doesn’t work for me, as my CDN doesn’t resolve /foo to /foo.html.

This leaves export const trailingSlash = 'always', which does cause the build command to produce my desired output of build/foo/index.html. But of course the point of trailingSlash = 'always' is to prevent a path of /foo from working; it must be /foo/. This isn’t the style we use for other URLs, and we want these URLs to be shareable without users needing to know that they shouldn’t strip off this unusual trailing slash. Or to boil down my feature request into a single sentence:

  • I want to use adapter-static to output “folder-based” routes (like src/routes/foo/+page.js) as folders containing index.html files (like build/foo/index.html) without also needing to make trailing slashes required.
Describe the proposed solution

It seems to me like the simplest solution would be to create a new option to explicitly control HTML file output style (whether to output as foo.html or as foo/index.html), and if present it would override the choice determined by trailingSlash.

Alternatives considered

I read https://github.com/sveltejs/kit/issues/5334 and that issue seemed to get derailed into discussions of redirects and other aspects I’m not concerned with. I agree with the original poster’s feeling that it seems wrong that trailingSlash seems to collapse together two orthogonal options (how to treat trailing slashes in paths, and whether to output foo/+page.js as foo.html or foo/index.html).

After writing all of the above I just discovered https://github.com/sveltejs/kit/pull/3801, where what I’m asking for seems to have been removed because the assumption was that there wouldn’t be static hosts out there that behave the way I’m describing, where a hosted foo.html isn’t accessible via /foo and foo/index.html requires a trailing slash. These are configurable options; SvelteKit shouldn’t assume that no hosts support resolving foo/index.html for /foo(no trailing slash). Amazon S3’s website hosting default behavior is to redirect /foo to /foo/ and serve the index file for /foo/, but this can be changed.

Importance

i cannot use SvelteKit without it

Additional Information

No response

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The issue identifies src/routes/+layout.js and adapter-static as the relevant entry points; start by tracing how trailingSlash selects foo.html versus foo/index.html. Done means the output style can be controlled separately, producing build/foo/index.html while allowing /foo without a required trailing slash, with the relevant behavior verified across the existing trailing-slash modes.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
build-system, web-dev
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.