Webpack 4 Fundamentals

Setting Up Debugging

Sean Larkin

Sean Larkin

Webpack 4 Fundamentals

Check out a free preview of the full Webpack 4 Fundamentals course

The "Setting Up Debugging" Lesson is part of the full, Webpack 4 Fundamentals course featured in this preview video. Here's what you'd learn in this lesson:

Sean illustrates how to set up debugging through Webpack and its integration with Chrome DevTools.


Transcript from the "Setting Up Debugging" Lesson

>> Sean Larkin: So now you'll see here,
>> Sean Larkin: We took it a step further. So if you want to debug a Node application or a Node script, you can do so simply by running Node and then passing a couple arguments. And I'll just show you the inline version here, so for example, debug, debug this, debug this, right.

Let's just say for any script, you would have to run node --inspect --debug-brk, which just says break on the first line. I think it's now inspect break, sorry, inspect-brk, and then it'll just be the path to your file. So of course, you're like, well, Sean, we're just calling a CLI command, and so how do we debug that webpack or whatever, like foo.js?

So if you have a debugger statement, what happens is, you can actually load this. Let's see what's script files we have in here now. So does this have a module or anything? We should just dive in and understand how the debugger works. So actually, go ahead and write this command, so debug this and then index.js, so node --inspect --inspect-brk and then src/index.js.

Now do we all have, at the least, Chrome running on your computer maybe, or if you have VS code? I'll show you the way to do it with Chrome. You can actually do it inside of VS code too, but I don't wanna derail too much cuz I know not everybody's using it.

And so, what happens when we run this, right? So npm run debugthis,
>> Sean Larkin: Wow, what happens? We now get this fancy URL, right? But what's super cool, and we're gonna be adding this feature for Microsoft Edge. You might be like, Sean, why are you on Chrome? [LAUGH] In the URL, you just type chrome//inspect.

You'll notice that you'll actually see, so I'm on a little bit earlier version of Chrome here. You might even see a little note icon that you can click on, or if you go to chrome://inspect, it'll show remote targets and you'll see this target here. And there's even a place that says Open dedicated dev tools for Node.

So if you click on that, look, it's actually broken in the module. There's your break point. That's your module scope. This is how Node loads files. And it's ironic, you're like, well, it's an iffy. My goodness. And so you can even open up a console, and you could say just global, I think is the version of window in Node.

>> Sean Larkin: There you go. Or process, it's like process.emv. Look, you know exactly what version you're running. It might be eight, it might be ten with the architecture. You're inside of Node right now, and you're stopped at a break point. It just turns out we don't have any code.

So if you wrote a debugger statement, you can actually break into it and see what that code looks like. So keep this context in mind. So this is the value for this, especially when you're working with Node tools. It's really nice to be able to debug through this kind of stuff.

[COUGH] And so therefore, we kinda have to reformat our scripts if we want to be able to debug webpack.
>> Sean Larkin: And if you have those dedicated Node tools, you instantly get, it actually switches context over. Sometimes it can be annoying, but I think there's a configuration for it.

But now you're literally in webpack right now, when you run this. Here and I'll go back to the script so you can see and follow along. So now we're literally inside of the Node process, and actually what you'll see is we're in the webpack.js, the binary file. We could even peruse this code and be like, well, what's webpack doing here?

And it just requires the webpack CLI. [LAUGH] And you can step through it, just as if you were stepping through anything else.
>> Sean Larkin: And that's super nice if you ever wanted to write your own custom plugin or custom loader or find out why something is failing. This is super valuable.

I think even you get the context, so if I wanted to say webpack, what's a good place where a webpack runs? We could go to the lib webpack.js. So if you hit Command or Ctrl+P, you get basically a file picker while you're in this state. So lib, oops, why can't I type i's today?

lib/webpack, so here is the webpack lib or Node API file. And you'll see like, Sean, wow, that's a lot of plugins. I don't understand. And I'll teach you more about this.
>> Sean Larkin: But you can set a break point almost anywhere, and I believe it'll just stop, depending on how far I've gotten.

>> Sean Larkin: I think maybe I stopped at the wrong point. Yeah, it looked like it did. But adding break points to critical pieces, custom plugins, custom loaders, if we get as far as custom loaders, we can talk about why this is valuable. And I kinda joke, but I'm dead serious.

It's kind of debug driven development, you're literally just trying to step through to understand the order of operations. Async is hard a lot of times, and so it provides really valuable context. So these are probably gonna be the scripts that we run with. And I think we've kind of beat scripts to death here.

But does anybody have any questions about the composition or have any concerns or about how specifically to use them?
>> Sean Larkin: Because I want you feeling comfortable with adding this kind of composition. Everything we do, we're really focused around composition and separation of concerns. Most people find that they have problems using webpack because they shove everything into one script, into one build file.

And so it becomes fragile, just like having a 10,000 line JavaScript file and trying to maintain it.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now