Существуют разные подходы для организации sass-архитектуры, какую бы вы не выбрали, главное, чтобы она была.
Я отношусь к организации sass, как к инструменту, в первую очередь, он не должен мешать и тормозить ход мыслей. Поэтому начиная проект, я не знаю какой получится архитектура, она устаканивается по ходу работы и принимает форму подходящую для требований проекта.
Bem, Smacss, Oocss, Organic-css должны давать вам гибкость мысли, чтобы построить свой проект.
Я всегда начинаю проект со стандартной для себя файловой организации:
Все что я знаю на 100%, что мне пригодится папочка core, где будут лежат настройки проекта, общие правила, помощники, пройдемся по основным:
core/_core.sass
Служит для подключения всех файлов из папки core, вы можете подключить сюда compass, если он используется на проекте.
core/_mixins.sass
Я стараюсь не таскать с собой кучу миксинов из проекта в проект, этот файл обрастается ими по мере необходимости, но по-умолчанию у меня используются пару миксинов: em, cp, reset-btn.
core/_reset.sass
Нормалайз у меня не прижился, я использую reset в своих проектах, чтобы уровнять стили в браузерах.
core/_settings.sass
В этом файле собираются настройки для всего проекта: размеры шрифтов, цвета, максимальная ширина и т. д.
core/_base.sass
Служит для общих правил на проекте, body я делаю font-size равной заданой переменной, чтобы в дальнейшем удобно высчитывать em с помощью одноименного миксина, раньше я делал этот font-size равному 62.5%, чтобы 1em был равен 10 пикселям.
После этого я стараюсь просто верстать не уделяя особого внимания архитектуре, иногда даже в одном файле. Но за все время проекта наступают точки, когда будущая архитектура начинает прорисоваться и тогда, я раскладываю все по полочкам, как это требует проект, не выдумывая раньше времени себе ограничений, из этого получаются совершенно разные формы организации:
Например, сайт моего небольшого проекта не требовал особой организации, кстате, исходный код можно посмотреть на гитхбе: github.com/omelniz/block-flute
Одностраничный сайт, разбитый на блоки, smgomsk.ru
Паблик спич уже сайт побольше и потребовал от себя более гибкой архитектуры. theps.ru
Большие проекты, должны иметь более строгие правила, хотя и начать свой путь могут также. Правила должен кто-то поддерживать иначе проект превратится в тыкву, возможно уже через пару месяцев.
Это мой личный опыт в организации sass-архитектуры проектов, мне интересно подумать головой, а не слепо использовать имеющиеся методологии, хотя иногда именно это и нужно.
Автор: omelniz
