This course has been updated! We now recommend you take the Webpack 4 Fundamentals course.

Check out a free preview of the full Webpack 2 Deep Dive course:
The "Webpack Validator" Lesson is part of the full, Webpack 2 Deep Dive course featured in this preview video. Here's what you'd learn in this lesson:

Kent spends a few minutes answering some audience questions about Webpack and ES6. He then introduces the Webpack Validator module which looks at the Webpack configuration settings and provides better feedback messages when there is a configuration error.

Get Unlimited Access Now

Transcript from the "Webpack Validator" Lesson

>> [MUSIC]

>> Kent C Dodds: So questions? Yeah?
>> Speaker 2: Is there any reason for using module exports instead of the ES6 syntax on the webpack config file?
>> Kent C Dodds: Yeah that's a great question, it's mostly because I was trying to avoid throwing too many concepts at you, but we're actually gonna be talking about ES6 modules in the course anyways.

[00:00:21] So I should have, but then the other thing is, if you don't have the Babel, it's webpack.config.Babel.js, so if you don't have the Babel bit, then that will totally break. And until last night, I was not planning on adding the Babel bit. But I added the Babel stuff so that if people didn't have Node six, then maybe hopefully they wouldn't have any problems.

[00:00:47] But yeah, so you could totally use ES6 modules in that file.
>> Speaker 2: And then another one is just they didn't catch what the reason was for putting Babel in that web config file name?
>> Kent C Dodds: Yeah, so by putting Babel in there webpack says you want me to transpile this with Babel.

[00:01:03] And so it does. So it transpiles it with Babel before requiring it, that way you can use the ES6 modules and stuff. And if you're on, one thing in particular I kept running into was in the course I do use this destructuring and Node 4 does not support destructuring, Node 6 does.

[00:01:23] So that was kind of the last thing that I was like okay, yeah I should probably have this transpiled just in case. Yes.
>> Speaker 3: Does it matter where in the file name that Babel exists?
>> Kent C Dodds: I am pretty certain that it does, it needs to be at the end, yeah last one.

[00:01:38] In a way it's a little fortuitous that people are running into problems because it illustrates why this next bit is valuable. So, oops, so the webpack configuration object is not the easiest thing in the world to be perfectly honest, and it's being worked on, but until it is even more amazing than it already is.

[00:02:01] We have this cool thing called webpack-validator, and I think the latest version is 2.2.7. So you would normally just install that, but you already have it, so. And then we're going to require it into here, here I'm gonna put it up here. Or webpack-validator, those require the webpack-validator.

[00:02:25] And then all that you do is stick it inside your export around your normal object, so you pass your configuration object to the webpack-validator function, and I think I spelled it wrong.
>> Speaker 2: But you were consistent.
>> Kent C Dodds: There we go. So yeah you could think of it like this as well.

[00:02:50] So you could say config.
>> Kent C Dodds: So you could do it either way, right now we're just doing it, wrapping it inline like that. But what this is going to do for you is if some of you who are having trouble, if you do this then you hopefully will get a useful error message, but let's say that I had a typo and I said outputs.

[00:03:16] Then I rerun the build and I'm gonna get a much more friendly outputs is not allowed where I can go look up, okay why is outputs not allowed. It's because I spelled it wrong. And so the alternative to webpack-validator is this error which is much less helpful. So yeah hopefully that catches some of the errors that y'all have been seeing.

[00:03:42] Does anyone have any questions about that?
>> Speaker 4: Was what was the dependency again, and package?
>> Kent C Dodds: Webpack-validator.
>> Speaker 5: What version? 2.2.7?
>> Kent C Dodds: Yes. Yeah, you shouldn't have to actually add it to your dependencies, because we're gonna check out the next branch all together. We'll blow away all the changes that you made.

[00:04:03] I realize that you're like this is my baby code, but it's okay. We'll check out the next branch, force all that so we're all on the same baseline to continue on. And then, yeah, so you don't actually need to put anything in your package JSON, cuz it'll come later, yeah.

>> Speaker 2: There's a quick question in chat there on some syntax
>> Speaker 6: Can you repeat that?
>> Kent C Dodds: Yeah, yeah, so the question is why const resolve with braces equals require path, instead of var or let. So this is kind of a bigger subject then the purpose of this workshop, but basically I prefer to use const because it means that the binding to that variable name is immutable.

[00:04:48] Not that the variable itself is immutable but the binding, so that assignment. Meaning I can't come in here and say resolve equals bar, that will be a runtime error or even like a parsing error. And so what's nice about that is it makes your code easier to read and think about when you're not reassigning variables all over the place.

[00:05:10] And so there are some situations where let is useful. I know that some people really like var. I'm a big fan of Kyle Simpson, but this is one place where I just, I really prefer const because I feel like it makes code easier to read. There are some places where it's block scoping, it's kind of annoying and stuff I guess, but I kind of prefer the block scoping that you get from lint and const and I prefer const because you can't reassign variables.

[00:05:38] You have to think about it when you create a variable that you're gonna reassign, so good question. And the reason that it is with the braces is because your destructuring resolve out of path. So alternatively I could say path equals require path and then I could say const resolved equals passed.resolve, but that's no fun.

[00:06:02] And so, alternatively, also, I could say, if it was a typing thing, if I didn't wanna type any more, then I'd say resolve equals require path.resolve. But I like destructuring. I think it's a really declarative way to get things out of objects. So all those things were equivalent.

[00:06:21] I just prefer it this way. And why do I use an arrow function instead of an object, so this Alberto knows that you can actually do this, and it works just fine, works just the same. The difference being in the future, we're going to actually use an argument that is passed to us in this arrow function.

[00:06:50] It makes having dev test and production webpack configurations a lot easier. We'll see that a little bit later. Good question.
>> Speaker 6: Kent?
>> Kent C Dodds: Yes?
>> Speaker 6: As long as you're on the syntax, why are you using the require instead of import?
>> Kent C Dodds: Yeah, yeah, so it was mostly, I kind of explained this a little bit earlier, but it's mostly because I initially I didn't wanna throw as many concepts at you.

[00:07:16] All of a sudden I'm throwing ES6 modules, obviously even throwing destructuring was kind of throwing people for a loop. But yeah we're gonna be looking at a ES6 modules eventually anyway so, [SOUND] [LAUGH]