Sapper: Folder structure for Sapper apps

Created on 10 Sep 2018  Â·  7Comments  Â·  Source: sveltejs/sapper

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

Most helpful comment

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

All 7 comments

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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

keyvan-m-sadeghi picture keyvan-m-sadeghi  Â·  4Comments

BMorearty picture BMorearty  Â·  3Comments

Rich-Harris picture Rich-Harris  Â·  3Comments

Snugug picture Snugug  Â·  4Comments

Rich-Harris picture Rich-Harris  Â·  4Comments