After seeing some custom server.js usage a clear pattern is people using it to define static file serving from the root. For example for robots.txt or google site verification and other files that have to be served from the root.
Ideally users would not have to define this. The common way root serving has been solved is through a public directory.
For example:
This also needs to be applied to @now/next when implemented.
One implementation detail that we have to figure out is which are preferred: pages or public directory. I think it should be pages first.
I like the idea of a public directory. pages would work fine as well, but I think pages is kept a little cleaner if it is scoped to only top-level page components. Either way, this is a great feature to add!
@dwest-teo however having them in pages wouldn't cover serving .js files for example sw.js or similar 馃暤
With a new public folder is there a reason outside gradual adoption to use the static folder at the same time?
I personally prefer public because it's barely need to explained, putting it in pages could make people wonder "what should I put inside pages if is not just for pages anymore"
I think public/ is more explicit. In fact I already have a public/ folder that I copy manually to out during the export:
async exportPathMap(defaultMap) {
//...
await copy('./public', './out')
return defaultMap
}
Most helpful comment
I think
public/is more explicit. In fact I already have apublic/folder that I copy manually to out during the export: