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 "Path Configuration" 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:

The path configuration variable is used to specify the absolute path to where the bundled output files should be generated. A publicPath variable must also be specified so the Webpack Dev Server knows the location of the files on the server. After adding these configuration variables, Kent spends a few minutes answering audience questions and reviewing the build process.

Get Unlimited Access Now

Transcript from the "Path Configuration" Lesson

>> [MUSIC]

>> Kent C Dodds: One thing that webpack does is if you have images and CSS and stuff in the beginning when we see this it's gonna all go into our bundle but we're gonna wanna split that out. So we get caching and stuff and fonts won't be able to go into the bundle, we'll have to split those out.

[00:00:19] And so I don't want to litter my root directory with the bundle and all that stuff. So the way that we're gonna tackle that problem is we're going to add a path here to indicate the path that we want this bundle to land in. And we're going, that needs to be an absolute path so we're gonna use resolve.

[00:00:36] We're gonna get rid of that guy. And we're gonna resolve to the dist directory, and you can call this build, or you can call whatever you want. I like using the term dist, distribution, and so that will make your bundle get saved to a directory called dist. And so then when you, well, because it's gonna be in a different place, we need to go to your index.html and update the script for our bundle to be dist/bundle.

[00:01:07] And then you should be able to run your webpack-dev-server or well you should be able to run your build and then MPM start, and the app will load. But if you run webpack-dev-server right now it's not going to work for you. Well if you run the build first and then webpack-dev-server, it will work.

[00:01:29] Or it will look it'll work, let me show you what I mean. So we'll go ahead and run the build:dev. And then we'll run npm run dev to run our webpack-dev-server. And will refresh and everything is working, right. But if I go to my bootstrap file and update it to hello worlds.

[00:01:49] And I refresh it. That is not updating, it still says simply, whoops, hello world. And the reason for that is webpack says, anytime you get a request to where the bundle should be, I'm going to send you the in memory bundle that I have. If it's not a request to the bundle that I have, then I'm going to forge you onto the file system, and serve up statically whatever that is.

[00:02:14] So it just so happens that when it goes to get our bundle.js, it's gonna say, okay so that file I expect it to be at the root. In fact it says that in our output here. The result is served from /. And so if we actually go to bundle.js here, then we're gonna find our bundle and this has all the webpack-dev-server stuff in here.

[00:02:42] Somewhere in here it's hello worlds, yeah, there's our module right there. Don't worry, you're not shipping all this to production this is all dev stuff. And so yeah, it's serving the bundle from / but in our index.html we're looking for it from dist/bundle.js. So what it's actually serving us is what we've built with build dev command.

[00:03:05] And so what we need to do then is we're gonna go to our webpack config and we need to say the public path is, /dist/. Actually some loaders use this to know where to put image files or font files, and webpack-dev-server uses this to know where to serve our bundle from.

[00:03:35] So then if we run, let's go ahead and we'll delete the dist directory so that we're not fooled by that again, and then we'll run npm dev and you should be able to load the app and go to the bootstrap. And have that update also. So Irvin wants me to cover my favorite Adam packages.

[00:04:05] Maybe sometime I'll show you what I've got. I like Adam a lot
>> Speaker 2: Could you go back to your webpack config file?
>> Kent C Dodds: Sure.
>> Kent C Dodds: Has anybody seen webpack validator help them out at all yet. A little bit.
>> Kent C Dodds: So Billy's asking if we're gonna use post CSS or another preprocessor like SAS.

[00:04:48] We're not actually, which might be surprising cuz that's probably most of you want to do something like that. The reason that we're not is because it's pretty dead easy, or pretty simple, as far as all that you have to do, you just install a loader, you add it to a loaders array that you're gonna see in a little bit, and then you're pretty much good.

[00:05:10] You don't have to do too much, you can configure it as well. But yeah I figured we could focus on other things. And caching strategies, Daniel is asking about caching strategies to speed up consecutive builds. So there are some things that you can do with Babel to cache your Babel transpilation.

[00:05:33] I'm not gonna cover those things, you can look at the dox for that. Yeah that I know that webpack is also like that. The webpack team is working on caching things themselves just automatically for you. So it'll speed things up even further. And why is the dist folder not showing now, cuz I deleted it.

[00:05:55] So if I re-run the build, and then it's gonna add that dist folder and that's ultimately I'm gonna ship my dist directory to my CDN, but during development it doesn't appear because it's being served up in memory.
>> Kent C Dodds: Victor's asking if I can show how I set up webpack-dev-server.

[00:06:17] It's actually just a dev script with webpack-dev-server. We're gonna add some arguments a little bit later, but right now it doesn't need to be any more than that.
>> Kent C Dodds: Yeah and the index.html will be pointing to dist/bundle.js.
>> Speaker 3: I was fighting npm issues, the goal of this eventually is that all of those script tags above bundle.js will be gone.

>> Kent C Dodds: Yep, exactly. I'm glad that you asked that, cuz it reminded me of one other thing that I wanted to touch on. How many people are hoping to implement webpack in an existing app? Okay, are any of those apps just using script tags right now? Okay. Fun stuff right.

[00:07:06] That's awesome. If it's not, you're probably using grunt or gulp to compile them, right. So, yeah, so part of the reason that I'm showing you how to do it this way is because if you have in your mind some idea that you can just take your app and spend two weeks working on a rewrite to webpack.

[00:07:26] You are mistaken, that will fail. [LAUGH] So what the better approach of, it will not necessarily fail, you're all successful people. But a better approach would be to iterate on upgrading to using webpack and so, actually right now, well, once we add the production stuff, that's what we're doing next.

[00:07:50] But once we add the production build portion, then we could actually commit this and ship it. And all you have to do is make sure you run the webpack build before you ship it off to production. And so what's cool about that is, you can spend a day, or even just an afternoon adding webpack to your process and then you can iterate from there.

[00:08:11] The last thing that you want to have happen is start working on a two week refactor to make this work. And then product comes and says my goodness, we have this client, they're gonna buy if we can add this one feature and you need to stop what you're doing.

[00:08:26] Then you come back to your refactor and three weeks later and there merge conflicts everywhere and you have to start over. So the better approach is to iterate or refactoring. And so that's what exactly what we're we're doing here. So glad that you asked that. Okay I think we're gonna move on, any, yeah another question.

>> Speaker 4: Can you explain one more time why the reload didn't work unless you put in the publicPath?
>> Kent C Dodds: Yeah so, without publicPath then webpack-dev-server assumes that you want to serve the bundle from just slash. To be perfectly honest with you, I'm not sure why it doesn't just assume if I want my output file path to be in dist that's where my result will be.

[00:09:10] I don't understand exactly the intricacies behind that. But I do know that some loaders like the file loader and the URL loader, also use publicPath to know where to update URLs for files. I do know that also puclibPath can be dynamic, and so if you shift some of your assets to a CDN then you can dynamically set the publicPath so it knows where to get those assets.

[00:09:36] So that's potentially the reason. But yeah, so the reason that it wasn't updating was because you would run the build, and it would build it to the dist directory. But then webpack would serve up its in memory bundle to the / route, so not /dist/ but just /, and so what you would be getting is the stale version of the bundle.

[00:09:59] Yeah.
>> Speaker 5: One question on webpack config. How do you know whether you needed absolute path or relative path? Entry you have relative path is absolute.
>> Kent C Dodds: Yeah that's a great question. So, I wish that I could give you a better answer than this. But probably the best way, even validator's not gonna catch our context.

[00:10:25] If we do path though it'll catch us on this one. Just kidding. Actually those things actually have some other special properties. So as far as whether to know, docs, honestly yeah, and just experience. I know these things also because I have the dev right in front of me, so that's helpful too.

[00:10:54] But yeah you'll want to check the docs. Then after we finish with the production stuff, I'm gonna show you how to debug this using Chrome Inspector and stuff. I'm really excited to show you that. And so yeah hopefully that can also be helpful as well.