Add feature to serve page.html on requests to site.com/page about serve

[leo]

If you're site generator doesn't do it like that, it simply should: #58 (comment) 😊

[timneutkens]

Isn't this what -s, --single is for? On second though, nevermind.

[flybayer]

As far as can tell --single redirects all requests to index.html. So a request to site.com/history will be served index.html. I want history.html to be served in this case.

[timneutkens]

You're right I was too quick 😉

[leo]

Doesn't site.com/history serve history/index.html?

[flybayer]

@leo, yes, that's my workaround. But I want site.com/history to serve history.html if it's there because that's what react-snapshot generates for me. My workaround is a custom script that moves history.html to history/index.html (and likewise every other page on the site) after my build.

[joshgillies]

As react-snapshot is geared toward deployments to https://surge.sh, shouldn't this be a feature request against react-snapshot? Unless, of course @leo sees value in making list behave in the above manner?

[flybayer]

That's a possibility, but I'm sure someone else will come along and want this behavior for some other use case 🙂

[flybayer]

For list to be the go-to solution for static file hosting, I think it needs to be flexible and have a great out of the box experience. Many other static file servers like http-server already support this by default.

Can anyone think of a reason this feature shouldn't be added? The only thing I've thought of is we'd have to decide which should have the priority, history.html or history/index.html, in the case both are present.

[joshgillies]

@flybayer if http-server already offers support for your use case, what brought you to list?

Personally, I feel as though a "great out of the box experience" comes from the promise that a project does what it claims to do, and does it well. With the addition of dynamic mapping between /about and one of the following /about || /about/index.html || /about.html || /index.html is a little too far removed from the core of what list is about. Especially when you consider the list tagline is:

Single-command HTTP directory listing and file serving

Heck, it could even be argued that an option to enable single page app mode is too far... ¯_(ツ)_/¯

Unless, of course the end goal of list is to be all things to everyone, and in which case, as you were. 😄

[flybayer]

You have a good point @joshgillies 😄

Leo is why I switched to list because he basically said if you want to serve static files with now, you should use list. It turns out, list is significantly faster than http-server plus list also gzips the assets.

It definitely feels like there's a disconnect between the current tag line and @leo's latest advice. Maybe it's time for a tag line update? 🤔