Webpack 2 Deep Dive Webpack Dev Server

[00:00:00]
>> [MUSIC]

[00:00:03]
>> Kent C Dodds: Let's look at another problem to solve here. So it's really cool that we can build our bundle and our app works. But running this command every single time we make a change to the bootstrap.js file would be insanity. I wouldn't want to do that. And so you can actually, you don't have to do this, but you can actually, with npm scripts pass additional arguments to the script.

[00:00:27] And so by adding this -- here, anything else I pass here will get forwarded on to the script. So here you see I do a whole bunch of crazy stuff right there. Here, let me fix that. And if you look at the script that npm runs, we'll take off the s there, then you'll see the npm runs webpack with the thing that I passed.

[00:00:51] So that's an npm scripts thing. Yeah, my terminal thing is kind of funny. So if we say npm run build:dev and then we will add the -s there to tell npm to be quiet, and then we'll forward on watch. Then it will build our bundle and then wait for us to make a change to the file.

[00:01:14] And the really cool thing about, here, we'll say log ('foo'). Log is a global function of, oops, we need to start up our server share. What happened? There we go. So npm start. So now we get that log foo right there. I can change it to foos, cuz I like foosball, and now it's foos.

[00:01:40] So the really cool thing about this is, because webpack is in charge of all of our assets, when it sees that a file was changed, it can just update that one file rather than rebuilding the whole thing. And so it's lightning fast. This took seven milliseconds. I dare you to race webpack to your browser to try and refresh it before it finishes.

[00:02:03] So, yeah, it is lightning fast. Even in a giant application updating a single module is very fast, even with transpilation and stuff, which is awesome. The reason that I'm doing all this in the console right here is just to illustrate the point of watch mode. We're not going to use this ourselves.

[00:02:23] We're actually going to use a special server that webpack provides for us, rather than our http server, because it does a bunch of cool things for us. So we'll go into our package Json. We're gonna have another dependency that you would normally just npm install. We'll say webpack-dev-server; and we'll need a comma there.

[00:02:48] The latest version that we're going to install, it needs to be the beta version, so it will be to 2.1.0-beta.0. And with that already installed, we're going to add a dev script. It doesn't matter what order you put these scripts in because, once we check out the next branch, it's all going to be reset anyway, so just put it wherever.

[00:03:11] And then we'll say webpack-dev-server.
>> Kent C Dodds: And let me just make sure. Now if we run npm, and we'll start that dev script, so npm run dev.
>> Kent C Dodds: Then we'll get a whole bunch of output of all this stuff. What this is is it's saying, here we have this asset called bundle.

[00:03:37] This is how big it is, and all this information. And then here all the files that are in that bundle. So here all the modules that are in it. Only one of these files is actually our file. So the webpack-dev-server has a whole bunch of modules that it's using to do its job to enhance your development experience.

[00:03:54] And we'll see some of that when we start talking about hot module replacement and stuff like that, which everybody is excited about because it's one of the biggest buzzwords around webpack. But yeah, so now if we refresh our browser, what we're actually hitting, whoops. Let me make sure that this is closed off.

[00:04:16] Close that out, restart my dev-server. And what we're actually hitting now is the webpack server itself. And so there are a couple of interesting and cool things about this. But let me show you one problem that you might run into when you're playing around with this. And that is if I try to log ('hello world') in this bootstrap file, it is gonna rebuild.

[00:04:39] And it does it very quickly, again in 42 milliseconds. And then if I go in here, I see hello world. Now that's not what I was expecting. It was supposed to be broken. So I did something [LAUGH] to make it not be broken. It's magic! [LAUGH] That's funny.

[00:04:56] Okay, source bundle. Sorry, I skipped a step and that's why it's working magically. So I'm actually gonna go ahead and stop right there and give you an opportunity to catch up and ask any questions that you have before we move onto that step that I skipped. Yeah, question.

[00:05:20]
>> Speaker 2: Question on will we look at different source maps?
>> Kent C Dodds: Yes, we will look at source maps. There are actually lots of different combinations of source maps that you can use with webpack, and it's kind of confusing. I've gone through all of them and found two that I like, one for production and one for development.

[00:05:39] Those are the only two I care about, so we'll look at those. Okay, Andres asked what should we do if our HTML is coming from a CMS? Can we use webpack-dev-server? I should have specified webpack-dev-server is not for production, webpack-dev-server, well, it's for dev, for development. And so you use it because it enhances your experience while you're developing pretty well.

[00:06:03] And then ultimately, you bundle and send your resulting bundle off to a CDN. If you're storing your HTML in a CMS, you have to do things a little bit differently because that dependency can't exactly be explicit. It sounds like it's coming from somewhere else. And so you'll have to work around that a little bit to make it work with webpack.

[00:06:32] But you'll pretty much be doing the same thing you're doing now, that one part will be outside the band of webpack. Does webpack-dev-server use the bundle.js file? That is an excellent question. I will answer that, Irvin, in the next little segment. It doesn't use the one that you generated.

[00:06:56] So, actually, you can delete your bundle.js file here. And restart your webpack-dev-server, and you'll notice that it doesn't actually generate that file again. And you go in here and it's still working. It's serving up the file from memory because memory is much faster than file system. And so, yeah.

[00:07:15] And that's part of the reason why we use webpack-dev-server in development, is so that we don't have to worry about serving it up from the file system. Yeah?
>> Speaker 3: So is there a practical limit to the size of app you can use this capability on?
>> Kent C Dodds: You're talking about the development side of things?

[00:07:34]
>> Speaker 3: Yeah, because it's fast but-
>> Kent C Dodds: Yeah, so as your app grows the bundling piece can take a while. And especially if you had a lot of pre-processors and stuff, lots of loaders, then it takes longer, and plugins and things can slow things down too. So, yeah, I've had some really big apps using webpack that take like 40 seconds to start.

[00:07:58] But once they're going, the recompilation of individual files as you were developing is lightning fast, still. Like, under 200 milliseconds. So I still can't get to the browser fast enough.
>> Speaker 2: This is cool.
>> Kent C Dodds: I agree, I think it is cool, too. So Watson Deep asks does webpack-dev-server work with other frameworks such as Express?

[00:08:24] Yes, it does. We're not going to be looking into that, but webpack-dev-server does have a Node API that you can plug in as a middleware in Express. And I'm doing it in PayPal, yeah?
>> Speaker 2: And a followup from that CMS question was, can we use a loader to pull in that external HTML?

[00:08:46]
>> Kent C Dodds: Yeah, you might be able to use a loader to, because the loader runs at bundle time, it's not a runtime thing. And so you could use a loader to take some sort of special string or something and convert it into something that works for your CMS, for example.

[00:09:05] Yeah, it's probably not the use case for a loader. It really kind of depends on the way that your CMS is set up. But yeah, you can definitely make it work, but it's probably not going to be a loader.