Additional option(s) for `trailingSlash`

Is your feature request related to a problem? Please describe. The trailingSlash options introduced in #1404 don’t make it straightforward to add trailing slashes to index pages but not to leaf pages. For example you might want to have /blog/ and /blog/some-post rather than /blog and /blog-some-post, since that allows the index page to contain relative links.

Describe the solution you’d like One possibility is to add a "smart" option with the semantics described in either https://github.com/sveltejs/kit/issues/733#issuecomment-835911307 or https://github.com/sveltejs/kit/issues/733#issuecomment-835973914:

• any index.svelte file gets a trailing slash if there are also non-index pages in the directory, or in child directories
• the more deterministic alternative: all index.svelte files get a trailing slash (which dictates code organisation decisions, but is probably the decision we’d regret less)

There is one problem, described in https://github.com/sveltejs/kit/issues/733#issuecomment-835911307:

There’s another wrinkle, which is that the index-ness of a URL can’t actually be determined immediately, in the general case. Consider a scenario in which you have a /foo/[a]/index.svelte and a /foo/[b].svelte. We can’t know whether /foo/x should refer to the first (in which case it should be redirected to /foo/x/?) or the second (in which case any trailing slash should be removed) without actually loading them and seeing if the first falls through to the second. (We could redirect at this later stage, but we’d then have to re-run load functions after the redirect had occurred, which is obviously undesirable. For the same reason, I don’t think we can realistically have a way of configuring this at a page level; it needs to be an app-wide setting.)

For that reason the smart option would have failure cases — rare, and presumably identifiable-at-build-time failure cases, but failure cases nonetheless.

So another option is "strict", which would have the semantics describe above but wouldn’t cause redirects: a request for /blog would 404 if the correct path was /blog/. We could implement one, both or neither.

Describe alternatives you’ve considered The "ignore" setting provides an escape hatch for userland (or upstream, e.g. at the reverse proxy level) solutions, which gives us the option of not worrying about solving this problem. We could also just declare it to not be a problem, and settle for "never" and "always" being the only options that will cause an intervention by SvelteKit (as Next does, for example).

Per-page settings are also a possibility, though this has major drawbacks as described above.

How important is this feature to you? Personally I’m good with "never" and "always", but I can definitely see the argument for /blog/. I’d rate it as a nice-to-have.

[rmunn]

Of these two semantics:

• any index.svelte file gets a trailing slash if there are also non-index pages in the directory, or in child directories
• the more deterministic alternative: all index.svelte files get a trailing slash (which dictates code organisation decisions, but is probably the decision we’d regret less)

I’d say “How about both?” I can see reasons why either one would be preferred for one person’s use case vs. someone else’s use case. The name "smart" feels like it belongs to the first one (where a decision is being made). For the second one, I’d propose "index", so that trailingSlash: "index" means “any index.svelte file gets a trailing slash” (i.e., the deterministic approach).

[Rich-Harris]

closing in favour of #7719