trailing slash removed when navigating

[wighawag]

Describe the bug
I would like my path to end up with a trailing slash.
Currently with these lines, svelte kit always remove it :

kit/packages/kit/src/runtime/client/router.js

Lines 185 to 188 in 84e9023

	// remove trailing slashes
	if (location.pathname.endsWith('/') && location.pathname !== '/') {
	history.replaceState({}, '', `${location.pathname.slice(0, -1)}${location.search}`);
	}

Expected behavior
This behavior should at least be configurable.

Having a trailing slash is important to me as ipfs gateways append it anyway and so without being able to keep the trailing slash, there is a different behaviour between SPA navigation and navigation through request.

Plus it cause issue to calculate relative path as without slash the resource is now considered to be in the parent folder

I think trailing slash are more accurate in that regard since on a static website, the corresponding underlying index.html file is in its own folder.

Severity
This is a blocker for me that deploy website on ipfs

I am working on a ipfs adapter to support ipfs properly and I am currently stuck with this.

[wighawag]

The adapater repo is here : https://github.com/wighawag/sveltejs-adapater-ipfs
See readme for what it actually does : https://github.com/wighawag/sveltejs-adapater-ipfs/blob/main/README.md

The test app is here : (branch : adpater-ipfs) can be found here : https://github.com/wighawag/svelte-kit-ipfs-example/tree/adapter-ipfs

With the current modif it works but ideally I would not need to replace generated code as this is brittle

[Rich-Harris]

previous discussion here, which lead to #267. from there:

Starting with no slashes for the beta and waiting until we get a use case for something else sounds like a sensible plan to me

Sounds like we have a use case!

What we don't have is a sense of how this should be configured. Is an app-wide setting sufficient, or does it need to be per-page? What sort of thing did you have in mind?

[wighawag]

Hi @Rich-Harris thanks for the link to past discussion

What we don't have is a sense of how this should be configured. Is an app-wide setting sufficient, or does it need to be per-page?

For my use case (ipfs hosting), an app-wide config would be sufficient

ipfs gateway force the trailing slash when an index.html is detected and used.

The trailing slash make it easier to compute relative path too

[mcmxcdev]

Another use case is SEO, the same route with slash and without would be indexed as two different pages by a crawlbot, therefore deciding to redirect to either or makes sense.

[techniq]

FWIW regarding relative paths, I borrowed/tweaked this url building from routify's helpers to better handle them

import { derived, get } from 'svelte/store';
import { page } from '$app/stores';
import { goto as gotoApp } from '$app/navigation';

export function url(path: string) {
  const $page = get(page);

  if (path.match(/^\.\.?\//)) {
    // Relative path (starts with `./` or `../`)
    let [, breadcrumbs, relativePath] = path.match(/^([\.\/]+)(.*)/);
    let dir = $page.path.replace(/\/$/, '');
    const traverse = breadcrumbs.match(/\.\.\//g) || [];
    // if this is a page, we want to traverse one step back to its folder
    traverse.forEach(() => (dir = dir.replace(/\/[^\/]+\/?$/, '')));
    path = `${dir}/${relativePath}`.replace(/\/$/, '');
    path = path || '/'; // empty means root
    console.groupEnd();
  } else if (path.match(/^\//)) {
    // Absolute path (starts with `/`)
    return path;
  } else {
    // Unknown
    return path;
  }

  return path;
}

export function goto(path: string) {
  const newPath = url(path);
  return gotoApp(newPath);
}

Examples:

<a href={url(`./${item.Id}`)}>Child / Subitem path</a>
<a href={url(`../${key}`)}>Sibling path</a>
<a href={url('../')}>Parent path (back to list, etc)</a>
<a href={url('../../')}>Grandparent path</a>

[Rich-Harris]

What's wrong with just using relative paths?

[techniq]

@Rich-Harris it's been a little while to remember all the details, but when I tried to use URL I remember it not being as versatile as I needed.

For example, if I want to add a child/sub path (tack on a /id to the path), neither id nor ./id would do this (at least how I expected)

new URL('id', 'http://example.com/one/two/three').pathname
=> "/one/two/id"

new URL('./id', 'http://example.com/one/two/three').pathname
=> "/one/two/id"

I think this is mostly due to the path not ending in a / (which I prefer it doesn't) but that is also why I mentioned it here.

There are more use cases I have such as those listed above (replace the current last path (sibling path), parent path, etc).
Some of those work with URL and relative path, but not all. Don't rule out that I could just be doing it wrong, but when I researched back then (stackoverflow, etc), it didn't seem possible and hence finding how routify was doing it (since I was using it before).

[kpnnkmp]

Another use case to to not remove the trailing spaces, is how Netlify handles URLs by default. URLs without a trailing spaces will automatically get redirected (301) to the one with a trailing slash, as you can see in the below screenshot. This is impacting performance a little bit, which I measured with web.dev.

You can change it by updating the asset deployment settings of Netlify (disable the prettifier for URLs), but it is not clear this is the solution to this issue, and it (potentially) impacts other URLs in a negative way.

FYI, I am using the static adapter to deploy to Netlify.

[RaeesBhatti]

Netlify redirects tries the exact path in the request and if that is not available it will redirect to trailing slash or non-trailing slash whichever one is available.

[RaeesBhatti]

I've been looking into SvelteKit routing deeper recently for #943.
And I think I understand some of the reasoning behind the current design. Making routes/category/index.svelte responsible for /category achieves the following:

• have $layout.svelte specific to that path
• have hooks specific to that path

Because there's no other way to scope those two features down to a specific path if we're using filesystem based routing.

The trailing slash and non-trailing slash URLs can exist at the same time and support existing features in a couple of different scenarios. E.g.

1. Using $index.svelte file for trailing slash:

• routes/category/index.svelte → /category
• routes/category/$index.svelte → /category/

The problem with this approach is that /category and /category/ can't have different hooks and layouts.

2. Using $index directory for trailing slash

• routes/category/index.svelte → /category
• routes/category/$index/index.svelte → /category/

This might be a little confusing at first glance but allows scoping of layout and hooks.

2. Using $ directory for trailing slash

• routes/category/index.svelte → /category
• routes/$category/index.svelte → /category/

I think this probably the cleanest. We could also go with # as prefix for directory name.

I think any of these can be implemented without breaking existing behavior. I'm willing to put in the work and implement this since we have a need for this kind of routing for a website we want to port to SlvelteKit. But I'd like to get a go ahead from SvelteKit authors and maintainers first.

[wighawag]

@RaeesBhatti It is an interesting approach to allow for both.

I still think we need a way to have that configurable globally though and let user use normal folder name if desired. This is especially important for ipfs gateway which do not allow for path that do not ends with slash. They get redirected to path with a trailing slash. It would be confusing to force user to use $foldername.

Your proposal should be an opt-in option that let users use both trailing slash and non-trailing slash if they need it, so that use of trailing slash can continue to use the normal folder name.