I am proposing a better folder structure for Sapper apps which I think is more logical.
MyApp
build
src
-- routes folder
-- server.js
-- client.js
-- service-worker.js
-- template.html
-- rollup-config.js or webpack-config.js (Single file exporting config objects for server/client/service-worker)
assets
-- manifest.json
-- favicon.png
-- global.css
I agree that the folder structure should be changed. I was also thinking of putting everything inside a src folder, but not the build config (it's not a source file). Using a single config file is a little tricky since Sapper needs to be able to identify which config is which, and the easiest way to do that is to have separate files. We could do this sort of thing...
import config from 'sapper/config/rollup.js';
export default {
client: {
input: config.client.input(),
output: config.client.output(),
// ...
},
server: {
input: config.server.input(),
output: config.server.output(),
// ...
},
serviceworker: {
input: config.serviceworker.input(),
output: config.serviceworker.output(),
// ...
}
};
...it doesn't follow the traditional structure of a config file, though maybe that's okay? Thoughts welcome.
I was thinking of renaming assets to static, since 'assets' is commonly used to describe the generated JS and CSS files (so perhaps /client/* should become /assets/*). It also has the nice outcome that src and static would be adjacent, rather than separated by build and node_modules etc.
So my suggestion would be
|- build
|- export
|- rollup # or single rollup.config.js as described above?
|- client.config.js
|- server.config.js
|- serviceworker.config.js
|- src
|- manifest
|- # auto-generated files
|- routes
|- # route files
|- client.js
|- server.js
|- service-worker.js
|- template.html
|- static
|- manifest.json
|- # etc
A single configuration file is better than three separate files and less confusing, specially for developers coming from other similar frameworks.
I'm very much in favour of having a src folder, and putting all the entry points and routes in there. But I feel that keeping the build configs separate is clearer, because they mirror the structure of the three entry points, client.js, server.js and service-worker.js.
EDIT: at least I don't feel having three config files is confusing, _because_ they mirror the structure of the entry points.
Auto-generated files in src/manifest, isn't it an oxymoron? If I'm right src stands for "source", so how could some files be considered as source files if they are totally generated from other files? IMHO it's a little bit confusing but maybe I'm too picky…
And do not forget there should be a way to set a custom build directory, for instance if we build for Firebase hosting it has to be inside a special functions folder, like we can do now with
sapper build firebase/functions/app
Sapper will soon become very popular. We should change the folder structure as early as possible. I am in favor of single configuration file as I would like to have less cluttered and cleaner folder structure.
Released 0.21 with this change — see sapper-template or the migration guide
Most helpful comment
I agree that the folder structure should be changed. I was also thinking of putting everything inside a
srcfolder, but not the build config (it's not a source file). Using a single config file is a little tricky since Sapper needs to be able to identify which config is which, and the easiest way to do that is to have separate files. We could do this sort of thing......it doesn't follow the traditional structure of a config file, though maybe that's okay? Thoughts welcome.
I was thinking of renaming
assetstostatic, since 'assets' is commonly used to describe the generated JS and CSS files (so perhaps/client/*should become/assets/*). It also has the nice outcome thatsrcandstaticwould be adjacent, rather than separated bybuildandnode_modulesetc.So my suggestion would be