trailingSlash override functionality

[ryanrussell]

Describe the problem

Issue: Looking for a way to override trailingSlash from always -> never in a route sub-path

Is it possible to override the default configuration for 'always' or 'never' for a childless leaf node route?

If I'm not mistaken, before the August breaking changes, this was possible to override at the folder/page level with something like:
<script context="module"> export const trailingSlash = 'never'; </script>

Trying to export this from a +page.server.ts does not seem to convey to the current build.

It's nice to use always/never instead of using ignore to ensure all urls have a single canonical, but there are use cases where it's nice to enforce always as the default, and then apply never to childless node pages.

For example:
/topic/ - trailing slash
/topic/subtopic/ - trailing slash
/topic/subtopic/leaf-content-with-no-children - Would like to use trailingSlash = never for content here?

Asked on discord, was advised this was intentional but possibly worth creating an Issue to confirm this is a permanent, intentional design decision.

Describe the proposed solution

This would only make sense in the context of using always as the site-wide default, then allowing over-rides in subfolders.

The config option would need to be overridable server-side in a +layout.server.ts or +page.server.ts in a sub-folder.

In this example, a +page.server.ts in /topic/subtopic/ would be applied to flip always to never for children of subtopic.

Routes matching a regex like /topic/subtopic/[slug] would not receive a trailingSlash.

Alternatives considered

Using ignore and building the enforcement manually in JS or enforce with rewriterules at the LB layer.

Definitely possible, but feels undesirable.

Importance

nice to have

Additional Information

It feels like a fairly common canonicalization practice has been that folders get a trailing slash, child-most content pages do not.

If you are in a situation with a legacy site that behaves this way, you must make some tough, permanent decisions about lots of 301's if they have used a structure where only child-most content does not have a trailing slash.

Without a built-in method to replicate, it increases the level of difficulty to migrate existing sites.

Again, all possible, but it would feel smoother if this was possible without adding in nginx/custom logic/etc :)

[Rich-Harris]

The hesitation here was that a page option forces you to load the code before determining whether you need to redirect or not, which slows things down. If you can return a redirect response as soon as you know which route matched, you save yourself some work.

But now that I think more about it, maybe we're optimising for the wrong thing. There might be some gotchas involved in moving to a page option that we won't find until we try and implement it, but perhaps it's worth trying.