![\"Hexanol](\"http:\/\/vanseodesign.com\/blog\/wp-content\/uploads\/2015\/12\/hexanol.png\")
Last week I talked about the @import directive<\/a> and how you could use it to create a more maintainable file and folder structure. I showed you one simple structure I learned and I promised to show you some other structures I\u2019ve come across.<\/p>\n I have a few to share and I\u2019ll talk about some of the commonalities between them to help you choose one or develop a structure that works for you.<\/p>\n I hope you don\u2019t mind if I start with the simple directory structure<\/a> I mentioned last week. Here it is as a reminder.<\/p>\n The vendor folder holds 3rd party code. The partials folder is for code you want to include and compile. The modules folder is for code you want to include, but don\u2019t want to compile.<\/p>\n Note that this structure allows you to distinguish between your code and 3rd party code and it allows you to distinguish between code you want to compile and code you don\u2019t want to compile. That\u2019s what this organization does.<\/p>\n The names of the files and folders can be changed to whatever you want. The key is this structure allows you to keep your code separate from 3rd party code and it allows you to separate your code between that which should be compiled into CSS and that which shouldn\u2019t be compiled.<\/p>\n Another structure I came across is the 7–1 pattern from Hugo Giraudel<\/a>. Here\u2019s how you might set up a directory along with some examples of files that would be in each folder.<\/p>\n The base folder<\/strong> holds boilerplate content. It holds the styles every page of your site should receive.<\/p>\n The components folder<\/strong> holds all your micro layout files. Your styles for buttons and navigation and similar page components.<\/p>\n Your macro layout files go in the layouts folder<\/strong>. Styles for major sections of the layout like a header or footer and styles for a grid system would belong here.<\/p>\n If you have styles specific to individual pages on your site, you can place them in the pages folder<\/strong>. For example it\u2019s not uncommon for the home page of your site to require page specific styles that no other page receives.<\/p>\n The themes folder<\/strong> holds files that create project specific themes. For example one section of your site might use a color scheme with primary colors, while another section builds a color scheme based on neutrals and earth tones.<\/p>\n The helpers or utils folder<\/strong> holds Sass tools, helper files, variables, and config files. These files won\u2019t be compiled.<\/p>\n Finally the vendors folder<\/strong> holds 3rd party code and the main.scss<\/strong> file uses @import statements to include the other files.<\/p>\n Here are some additional resources for this pattern<\/p>\n A number of people have written about setting up directory structures based on either a SMACSS<\/a> or BEM architecture<\/a>. I want to present four different, albeit similar, structures that build on each other and also incorporate some ideas from the 7–1 pattern.<\/p>\n Ryan Burgess leveraged some ideas from SMACSS when setting up this simple structure<\/a> for Evernote. They used four folders, Base, Layout, Modules, and Themes<\/p>\n Notice the distinction between micro and macro layout as well as the distinction for page specific styles and a general catchall for files with non-compiled code and general styles.<\/p>\n Tim Hartmann<\/a> and Bram Smulders<\/a> shared similar four folder structures.<\/p>\n Again there\u2019s the distinction between macro and micro layout styles as well as a folder that holds non-compiled code and general styles. The difference here is a State folder for state styles instead of a Themes folder for page specific styles.<\/p>\n Matt Staffer<\/a> shared the organization his company used to help them keep a SMACSS-inspired structure.<\/p>\n It\u2019s similar to the previous two structures, though note that these are files and not folders. The _other.scss<\/strong> file is the catchall and there\u2019s a _shame.scss<\/strong> file to nag you into improving the code it contains.<\/p>\n One last SMACSS based organization comes from Johannes Dreller<\/a>. It adds another directory to the ones we\u2019ve seen so far. Here\u2019s Johannes\u2019 structure along with some files each might hold.<\/p>\n The addition is the vendor folder, which is used to hold 3rd party content. The layout and module folders still distinguish macro and micro layout styles. State changes go in the state folder. Non-compiled code and general styles go in the base folder. The hacks folder takes the shame file and there\u2019s a main.scss to @import all the necessary files.<\/p>\n Matthieu Larcher & Fabien Zibi present DoCSSa\u2019s four folder organization<\/a>. <\/p>\n This structure is similar to the others I\u2019ve mentioned. The base folder holds boilerplate styles in the project folder and Sass tools in the utils folder. The files directly in the base folder are for code needed in both subfolders.<\/p>\n Components is for micro layout and specifics is a catchall for most everything else. In both cases the files directly in the folder are for those used in the subfolders. Finally there\u2019s a vendor folder for 3rd party code.<\/p>\n The last structure I\u2019ll mention comes from Matthew Anderson<\/a> and it adds some new ideas for organizing the directory.<\/p>\n First the familiar. The vendor folder holds 3rd part code, modules holds partials that contain reusable UI patterns and components. The framework folder holds all project wide and ideally project agnostic code.<\/p>\n The sections folder is similar to the shame or hacks folder. It\u2019s not necessarily code you\u2019re ashamed of, but it\u2019s code you\u2019ve yet to optimize or refactor or generally improve.<\/p>\n The two files are new. _bootstrap.scss isn\u2019t from Twitter\u2019s Bootstrap. It\u2019s a file that bootstraps the necessary files through @import statements.<\/p>\n _section.scss represents any file will become a compiled CSS stylesheet. These files will import _bootstrap.scss as well as any other project files necessary.<\/p>\n I hope seeing examples of how others organize their Sass files and folders helps you understand some of the ways people modularize their code<\/a> to keep it organized and maintainable.<\/p>\n What I hope you to take away from the structures I\u2019ve mentioned is the idea that there\u2019s no single way to organize your stylesheets<\/a> and directories, though there are common themes in the organization others have come up with.<\/p>\n These are some of the common things that others think worth keeping separate. You might decide you don\u2019t need to keep macro and micro layout styles separate and prefer to keep them together. You might not use 3rd part code on a project. See these commonalities as suggestions and not anything you absolutely have to use.<\/p>\n You can organize your files and folders however you think best. Just keep in mind that you should organize them in some meaningful way that helps you find and isolate your styles and code in a way that makes sense to you.<\/p>\n Next week I want to talk about another Sass directive<\/a>, @extend. It allows a selector to inherit styles from other selectors so you can write DRYer code<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":" As projects grows larger, the need to modularize directory and file structure increases. This is particularly true if you want to create code that can be used in other projects, in components and patterns across one or more projects, or in templates you share with others.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[10],"tags":[98,126,280],"series":[],"class_list":["post-14956","post","type-post","status-publish","format-standard","hentry","category-css","tag-modular","tag-sass","tag-structure"],"yoast_head":"\nSimple Structure<\/h2>\n
\n
\n
\n
\n
The 7–1 Pattern<\/h2>\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
SMACSS\/BEM Architecture<\/h2>\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
Others<\/h2>\n
\n
\n
\n
\n
\n
\n
Closing Thoughts<\/h2>\n
\n