A CSS Setup Built From a Decade of Experience — Part 1
Tags: ui, sass, css, frontend
Published: 2020-06-20 03:31:10

---
title: A CSS Setup Built From a Decade of Experience — Part 1
published: true
date: 2018-04-11 15:47:01 UTC
tags: ui,sass,css,frontend
canonical_url: https://medium.com/@shashilo0428/a-css-setup-built-from-a-decade-of-experience-part-1-3108814a203a
---

I’m often asked how I structure my CSS files for projects, why I do things a certain way, and why I’m so particular with my Git process. I have experience architecting projects with CMS’s like WordPress, Drupal and Magento E-commerce. I’ve also built custom PHP application solutions built with Codeigniter and Laravel. And lastly, I’ve implemented Javascript applications with React, Vue, and Angular in projects. I’ve got so much broad experience that I’d love to share with you.

First of all, in the spirit of decoupling things, I’m going to make this a 3 part series. I use SASS and SCSS files because I enjoy the syntax and I’m comfortable with it. I utilize GULP to precompile my SCSS files, but would use Webpack if it was for a Javascript project.

#### **How do I personally structure my CSS files for a project?**

It’s often confusing when you introduce a CSS directory naming convention to your team of developers. The mindset is, why make CSS more difficult to find things? If you are asking yourself this question, then let me ask you this in return. Why are all your components in separate files? It’s the same reason why CSS should be decoupled for the ease of figuring out where changes are, to allow Object Oriented programming, and less chance of merge conflicts.

The best thing I’ve experienced is to decouple your project structure. I start off with the 7–1 folder naming pattern. If you are working with a CMS, confine your folder structure towards the CMS. For instance, in Drupal you have blocks, views, nodes, pages, etc. These terms relate to the CMS. Therefore, if I’m writing styles for a view, I’m going to create a file inside the views directory of my SASS project just for this view. Therefore I would end up with this folder structure:

> sass/  
> base/  
> blocks/  
> nodes/  
> layout/  
> pages/  
> views/

Now, if I was working with a Javascript application, my fold structure is different. It would be more component driven, but follow the [7–1 Pattern](http://7%E2%80%931%20Pattern) meticulously. Each component would have it’s own SCSS file to keep them completely isolated from other components. They will have shared styles, but thats when you put global or shared styles into specific files. In the instance of the 7–1 Pattern, ‘components’ are HTML DOM components and not your application components. I create a new directory called ‘elements’ and place my HTML component elements into that directory.

> sass/  
> abstracts/  
> base/  
> components/  
> elements/  
> layout/  
> pages/  
> vendors/

As you can see, the 7–1 Pattern is a good start, but you should modify it to allow similar naming conventions towards your project. There is no right way or wrong way to do this, because in the end, all these files will be compiled into a minified CSS file anyway. It’s more of a personal or team preference on how you want to organize your SCSS files.

As a developer, your mindset should always strive to improve. As Olympic Gold medal sprinter Kim Collin quotes,

> “Strive for continuous improvement, instead of perfection.”

So true because there’s always a better way to do something, you just need to figure out how.