The last lesson walked through installing Sass. Next, let's discuss how to integrate it into a project. This lesson will address how to configure a project to use Sass, including necessary commands and files.
As mentioned in a previous lesson, there are two parts to Sass: The term relates to both Sass syntax, and the tool that compiles this syntax back into CSS for the browser. We installed the software to compile Sass in the last lesson. Now we just need to write in Sass syntax and start compiling!
The process for using Sass in a project is composed of three pieces:
The input file is where we write styles in Sass syntax. Sass files use the .scss syntax (short for Sass CSS). But the browser cannot use these styles directly. It doesn't understand them. So Sass compiles this file's contents into plain old CSS the browser is capable of reading, and places it in an output file.
Standard names for input files include application.scss, app.scss, and input.scss. While you can technically name it anything without receiving errors, these names are common convention and allow other developers to quickly identify your input file.
The output file is where Sass will place the CSS it compiles from the Sass code in our input files. We never, ever, ever edit the output file directly. We only ever alter and write code in our input file. The output file is produced automatically by a terminal command (which we'll discuss in just a moment).
Common names for output files include main.css, raw.css, styles.css, and output.css. Again, these are not technically required, but are standard practice so other developers can quickly identify the file. You'll see these names online and in the field.
The setup for the most basic iteration of a Sass project looks something like this:
teeny-tiny-sample-sass-project/
├── index.html
├── css
│ └── output.css
└── scss
└── input.scss
Here we have a standard project directory and index.html file. However, notice we have two style directories: one for css and one for scss.
css contains CSS styles in our output.css output file. But because we're working in Sass, we never edit the css directly. This is the output generated by Sass after compiling our Sass syntax.
scss contains Sass syntax styles, and our input.scss input file. This is where we write our Sass-syntaxed styles.
The stylesheet linked in the <head> of index.html should be css/output.css, because the browser cannot inherently understand the Sass syntax in input.scss.
But not all Sass projects are this simple. Sass also supports creating many small, modular stylesheets and later compiling them into a big CSS output file for the browser. And there's many ways to organize a project with lots of small stylesheets like this.
As you experiment and troubleshoot your own Sass in class, you may encounter these larger structures online. Know that we'll discuss more advanced Sass architectures later this week. But for now, plan on structuring your projects similar to the example above.
After creating input and output files in the relevant directories, we can tell Sass to compile our input into vanilla CSS in our output by running a terminal command:
$ sass filepath-of-input.scss filepath-of-output.css
If, for instance, we were working in a project structured like the one above, this command would look like:
$ sass scss/input.scss css/output.css
There are three parts to this command:
sass to invoke Sass. Easy enough.Running this command with the proper filenames corresponding to the input and output files in your own project invokes Sass to compile Sass syntax from the input file into corresponding CSS in the output file.
In the next lesson we'll address some of the particular features and functionalities we can use with Sass to further optimize our styles' code.