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
cleanUrls=false
I would prefer:
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.
Most helpful comment
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:
This description (especially the first paragraph) makes
servesound 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 ofserve.jsonsettings 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 usingservewith 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.