index.html as default file in subfolders?

[lazarljubenovic]

Currently, when I open something like localhost:8080/path, I get the fallback /index.html file instead of an existing file /path/index.html. Most servers, including GitHub pages, are by default configured "smartly" and return the index.html file (if it exists) when a folder is requested. Would be nice for this to be configurable, or maybe even default?

[lukejacksonn]

This doesn't really fit into the single page app server ethos. You should really only have one index.html file at the root of your project and load in components from there.

[lazarljubenovic]

Ah, right. This is for SPA. I used servor for single-page apps and just continued to use it for regular plain old websites, didn't even think twice. 😄

[odinho]

Do you know any no-dependency projects that has livereload and ssl that isn't "only" for SPA? I've kinda hacked servor for it, will probably just use that, unless I find something better. es-dev-server has lots of deps and slow to install.

[lukejacksonn]

Hey man 👋 I do not.. but we could surface this issue again and put the behaviour behind a flag potentially. Like --indexes which would ignore the fallback rules.

What does your hack look like?

[swyxio]

also swimming by to say this was rather unintuitive for me. using servor through svelvet, and it wasn't obvious that this was ONLY for SPAs. i kept refreshing thinking something was wrong. expected there to be a config to serve any existing html files. so i guess count this as a "+1" haha.

usecase - making a svelte site generator, need this for local dev mode

if you'll take a PR and/or give some specs i can try to PR - but also totally cool if you just want to keep it focused on the SPA usecase. my plan would be to add a flag, say --indexes like you suggest, and then modify the isRouteRequest logic and serve the correct file. Ofc if its easier for you to do it then go for it, i dont feel super confident about this stuff :)

---

edit: hang on... are we just slowly replicating sirv? help me get my head straight here i'm confused how they differ now apart from the zero dep/SPA only thing here

[lukejacksonn]

So the only reason I was conflicted about this in the first place was that if someone making a SPA visited route /example then currently they would get redirected to /index.html every time, no questions (as it sounds like @sw-yx just found out 😅) but if we enabled this by default then if they visited /example AND /example/index.html existed.. then it would serve that file instead.

Initially I thought this might be confusing but now that everything is behind a flag, users would only experience this new --indexes behaviour intentionally.

In summary, you all make good points and it shouldn't be too hard to implement. Let me have a quick play around with the code.. see whats what!

---

RE: how they differ now apart from the zero dep/SPA only thing here

The zero dependency thing has been a draw for some people as it makes install very fast (arguably only ~2s faster than sirv to npx but those seconds can add up in a project I guess) and its wysiwyg nature also makes the project very fork/hackable (which I encourage).

There is also a slight difference in feature set:

• Most crucially for me sirv lacks live reload which is done in quite a novel way here (no web sockets to keep it zero dependency)
• There is also no support for https (or the helpers that come with servor) which some APIs or environments demand to talked to over.
• Lastly servor finds free ports so that you can run multiple web servers with the same command.

That said.. I'm sure lukeed could implement all of these features in a hot minute if he wanted to. Maybe he made sirv for a slightly different purpose to servor 🤷‍♂ his stuff is always 💯

[lukejacksonn]

Alright.. so I have this working but there is one issue I can't get around which you might be able to help me with.

Here you can see that with the new flag --static enabled when you visit /nested then the file /nested/index.html is served up. Great 🌈 but the issue is.. I expected it to serve the assets relative to /nested so like /nested/assets/exists.png because I'm not prefixing those resources with a / (thats how I understood relative paths worked).

But it doesn't.. it goes for /assets/exists.png every time. Does anyone know why?

[lukejacksonn]

Ahh.. so it seems to work if I add this to the document head:

<base href="/nested/" />

Is this how you would expect it to work? I highly doubt that one would want to have to prefix all the resources in the document with /nested/ or whatever the folder name is called.

I wonder if es module imports respect base like this 🤔

[swyxio]

this is surprising to me too. i went ahead and tested it on netlify.

• source: https://github.com/sw-yx/plsdeletetrynested
• site: https://goofy-knuth-ec3489.netlify.com/nested/

so it seems that on the web, assets/exists.png in /nested resolves correctly to /nested/assets/exists.png. however it seems to behave differently in localhost.

i wouldnt recommend mucking around with <base> tags - thats currently a source of significant pain in Sapper

[lukejacksonn]

Hummm.. I wonder what it is then. I googled pretty extensively and didn't find much!

[lukejacksonn]

This is now possible in V4 (#51) with the --static flag. See #49 for more info. Thanks for the suggestion all! I'm still wondering if this is in fact the right behaviour though, for two reasons:

• Firstly I had to inject base urls to get things to get nested relative links to work properly
• Secondly I wonder about a recursive nested fallback where if given a path /a/b/c and no /a/b/c/index.html exists.. should servor check to see if there is a /a/b/index.html or /a/index.html etc? It makes sense but feels weird..

I welcome any further feedback if anyone has experience/opinions on this! 🙇

[swyxio]

wheee!