Now that we've covered all theses awesome ways of breaking code down into

smaller and smaller parts, and using either manifests or globbing to bring them

all back together again, this introduces a new problem with troubleshooting.

When looking at your rendered CSS in the browser's inspector,

seeing exactly what code is doing what is difficult.

The inspector will show you what line of CSS this is,

but not what line of Sass this is, or even what Sass file it might have come from.

This is a huge sad face.

Good news is that we have the technology to make it better.

Next, we'll look at how we can get a full trace from the command line and

explore a new way of troubleshooting, source maps.

Then we'll review on how you can leverage source maps in

the Chrome inspector to see where the code is actually coming from.

Last, we will look at how you can set up automated watches from the command line,

and use tools like grunt and gulp.

Debugging CSS can be difficult in the first place.

Good thing we have tools like the inspector to use.

But these tools are pretty useless when we start using Sass in a modular way.

So, one way to address this is to expose line numbers in your

output CSS's comments.

So, let CD into this Projects Folder here.

And, I am going to create a Sass file, okay?

And then I open the Sass file up.

Let's just put some simple Sass in here to get started.

$color: orange.

And then I'm gonna say, body is, background color is using $color.

And then I also want to do this.

Oops.

So save that.

Come over here.

So now, basically just by running Sass app as CSS, I see the output.

All right. But this isn't giving me

what I'm looking for.

If I do sass--help, I get a whole lot of stuff here.

But what I'm looking for here is line numbers.

So the -l flag gives me line numbers.

So if I do sass-l and then app.sass.

We see down here, and we'll bring this up a little bit.

We see down here that there is line 3 app.scss makes body color orange and

then line 7 of app.scss makes h1 color white.

Okay, so that's really helpful information but

running it in the terminal is not very helpful.

So let's output a CSS file, so I can do the exact same thing here.

So if I do Sass dash L and then I say at SCSS,

but then I declare an output, and I say style.css.

So now I created my style CSS file.

So if I open this up, now I see output into the CSS file is

those exact same line numbers that we were looking for.

Next, we need to view what's happening in the browser.

The easiest way to do this is to start a simple server using Python.

FYI you don't need to know anything about Python.

Python is already installed on your computer most likely,

we're just gonna start up a simple server real quick.

So to do this, I'm gonna open up another tab in my bash here.

And I'm still in this project, so

I'm going to type in python-m, and

then it's simple, oops, simple HTP server.

And we are now running on port 8000, okay.

Now I'm gonna come back to my other tab over here, and the thing that I need to do

is open my index file, and I need to add my h1 in here, right?

So, h1, oop, yep, that's what I wanted.

And then, Hello World.

Great.

Now, if I go over to Chrome, and I'll bring this

up over here, and I go to local host 8000.

So there's my page.

Okay, so now, when I inspect element, and

then I have the h1 selected here.

What I see is the output is the style.scss, or the style.css at line 6.

But by clicking on this, this actually takes me to the CSS file and

then I'm seeing what we saw before in the CSS file.

So this is really helpful from this perspective to debug in this way.

So that whenever you're actually selecting something from the inspector, and

then you click on this location inspector, then it takes you literally to,

like, the cursor setting here at line 6,

and it's telling me that this came from line 7, from the app.scss file.

And of course, if we add more files in here, then this would give me from all

the different files from where the Sass is actually coming from.