Use one @import per folder?

[stowball]

I like this idea of @hugogiraudel's to have one @import per folder with comma separated files http://sass-guidelin.es/#main-file (scroll down a bit)

[kllevin]

I would be hesitant to do this. I tried it with my current implementation of Scally, and as you should only be including the utilities, objects, components that you actually need for a given project, it can become confusing to find what you are looking for especially when you add generated breakpoints and other variable declarations into the mix.

My personal experience has been that it is easiest to control from the master style.scss file, as you can scan and see exactly what you have included, and what breakpoints you have set all in one place. This is especially helpful when you are on-boarding new team members to a project.

I would also argue that it may be too opinionated to make this call, and users of the framework could choose how they want to organize this file. I am not sure it makes sense to commit the master style.scss to the repo at all, and instead guidance on creating one should be part of the documentation.

[stowball]

Yeah, after I posted it I thought it wasn't such a great idea, since because Scally is highly customisable, you get in to that pain point of removing imported files and having trailing commas break your build - just like when you do the one line var statements in JS.

I am not sure it makes sense to commit the master style.scss to the repo at all, and instead guidance
on creating one should be part of the documentation.

Great call, @kllevin. It's not included as a bower or npm install, so it shouldn't be in the repo. Currently its a pain because you have to customise style.scss to test changes to Scally, but you can't commit it as is because of the paths to the @imports need to change from their defaults.

+1 for removing it

[kllevin]

I'm thinking we can write a test to check sass compilation, linting, etc. without actually having to check in `style.scss'. Hoping to make it part of the CI/Build process for Scally as well.

[chris-pearce]

+1 for removing style.scss, I agree it's a pain as it doesn't work out of the box and I think just describing how it works in the main README is good enough + soon enough they'll be the starter kit. I'll create an issue to remove it along with style.css.