brocessing / kirby-webpack

:muscle: A Kirby CMS starter-kit with modern frontend tools
MIT License
179 stars 23 forks source link

Files layout #17

Closed puckey closed 6 years ago

puckey commented 7 years ago

While working with this setup, I find myself having to dig for directories like content / site, which I use often when developing a site.

Also it feels like there are a lot of config files in the root, which I won't be using very often.

I was wondering if a file layout like this might make sense:

arnaudjuracek commented 7 years ago

We initially designed this tree structure to make kirby-webpack as least intrusive as possible compared to a tradionnal Kirby structure ; meaning that when ready to deploy, you'll just have to deal with www/.

Moving content/ and site/ one level up should be possible, but may be confusing, as it will also move kirby roots one level up, and blur the line between Webpack and Kirby files. That is why I tend to prefer the actual tree structure regarding those two.

A quick workaround would be to symlink www/site/ and www/content/ to the root of your project, but I'm not sure how this will behave in a git env.


As for src/ and style/, I guess it is a matter of taste, and ideally main.config.js should allow you to define your own specific entry structure (cc @pqml). That said, having your JS & style sources separated by default may be less confusing.

Which would give us the following structure:

kirby-webpack/
│
├── scripts/
├── config/
│   ├── main.config.json
│   ├── kirby.config.json
│   ├── postcss.config.json
│   └── webpack.config
│
├── src/
├── style/
│
└── www/               
    # your usual Kirby website folder
    # this is still all you need to deploy to your server
    │
    ├── assets/
    ├── content/
    ├── site/
    └── ...

What do you think ?

pqml commented 7 years ago

I'm not really into splitting the src folder. It's really common in a webpack environment to have the src folder containing all assets loaded by the bundler. One of the main features of webpack is loaders: you can load everything you want from your entry files by using the loaders that fits your needs (file-loader for fonts/images, raw-loader for raw text files, json-loader for json objects, ...). So it's not just a js/css thing. If you work with components it's also a common practice to handle css from the javascript of your component (e.g. with a folder MyComponent containing css / js / assets needed by the component)

You can separate js and css by setting path.src to the project folder root and set correctly the css and js entry files, but maybe we can stop relying on the path.src variable to allow changing entry paths quicker?

Agree with @rno on not moving site & content folder one level up, but the symlink seems to be a cool idea.

For the config files, I agree with you both, but there still will be a lot of files I can't move in the root so I don't know

pqml commented 7 years ago

For the double entry folder like src and style, entries are now declared relative to the project's root folder, so it should be easier to split entries between multiple folders. (https://github.com/brocessing/kirby-webpack/releases/tag/0.7.0)

Symlink seems to be possible with Git and Linux/OSX, but they won't work on windows (they will be replace by a plain text file on git clone)

puckey commented 7 years ago

Good stuff!

When I work on a Kirby site I am always toggling between javascript/css/content/site directories, so it makes sense to me to have them all on the same level. But I understand it might be a bit confusing for other users. I will configure my own version like this instead.