Skip to content
This repository was archived by the owner on Jan 11, 2023. It is now read-only.

Folder structure for Sapper apps #432

Closed
ansarizafar opened this issue Sep 10, 2018 · 7 comments
Closed

Folder structure for Sapper apps #432

ansarizafar opened this issue Sep 10, 2018 · 7 comments

Comments

@ansarizafar
Copy link

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

@Rich-Harris
Copy link
Member

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

sapper-template
|- 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

@ansarizafar
Copy link
Author

A single configuration file is better than three separate files and less confusing, specially for developers coming from other similar frameworks.

@nsivertsen
Copy link
Contributor

nsivertsen commented Sep 10, 2018

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.

@laurentpayot
Copy link

laurentpayot commented Sep 12, 2018

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…

@laurentpayot
Copy link

laurentpayot commented Sep 12, 2018

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

@ansarizafar
Copy link
Author

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.

Rich-Harris added a commit that referenced this issue Sep 19, 2018
Rich-Harris added a commit that referenced this issue Sep 24, 2018
@Rich-Harris
Copy link
Member

Released 0.21 with this change — see sapper-template or the migration guide

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants