serve
serve copied to clipboard
Support foo/index.html -> foo/ without stripping ".html" from other paths?
The standard behavior I'm used to from a static file serving program is that foo.html
should be served as-is, but requests for foo/
should serve foo/index.html
if it exists, rather than a directory listing. The new cleanUrls=false
setting lets me prevent foo.html
from redirecting to foo
, but also loses the ability to serve foo/
.
Are these two things intentionally part of the same setting? I'm not sure how to get back to a traditional behavior here. Thanks!
cleanUrls=true
- foo/ (serves foo/index.html)
- foo.html -> redirect -> foo
cleanUrls=false
- foo/ (serves directory listing)
- foo.html (serves as-is)
I would prefer:
- foo/ (serves foo/index.html)
- foo.html (serves as-is)
I second this. Prefer old default behavior better.
To phrase the issue a little more generally, I think the latest release has introduced some disconnect between the stated purpose of the package and its functionality:
Assuming you would like to serve a static site, single page application or just a static file (no matter if on your device or on the local network), this package is just the right choice for you.
It behaves exactly like static deployments on Now, so it's perfect for developing your static project. Then, when it's time to push it into production, you deploy it.
This description (especially the first paragraph) makes serve
sound like a general-purpose static file server that can be used for local development and more. However, if you're using anything other than Now static deployments for the production site, there is no combination of serve.json
settings that will give consistent paths in both environments. I use Zeit Now for various projects and like it a lot, but I don't use it for everything and (with the current config options) will need to stop using serve
with projects that deploy to GitHub Pages, for example.
I realize consistency within the Zeit ecosystem is important, and it's something I value about Zeit, so if this is all intended behavior I'll certainly understand. But in that case I think the language in the readme describes this package as being more general-purpose than it is today.
We modeled serve
after superstatic. Can someone check if we're misaligning here?
With cleanUrls=false
, superstatic serves the same HTML file for both foo/
and foo/index.html
. With cleanUrls=true
, foo/
works as before, but foo/index.html
and foo/index
both redirect to foo
(without a trailing slash).
Superstatic's implementation of cleanUrls=false
matches what I'm hoping for. The cleanUrls=true
behavior seems a bit unintuitive but that probably has more to do with the trailingSlash
setting, which defaults to Superstatic will make assumptions for on the best times to add or remove the trailing slash
.
I'd like to second this as well.
The behavior behind cleanUrls is unintuitive and breaks relative paths within directories of static HTML files, i.e. whenever one document links to currentDir/index.html
and the server re-directs to currentDir
without a trailing slash, all of the relative link
and script
tags fail to load and all the browser sees is plain markup.
yes, my plain html file is getting broken.
/foo/index.html loads ./x.js
(which means /foo/x.js
) but serve rewrite it to /foo/
then /foo
and now my html breaks.