Build Web Apps with Angular 2 A Deeper Look at webpack.config.js

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

[00:00:04]
>> Scott: You might've think well Scott you've already showed us the webpack what else is there left? Okay, if you have the webpack that is great, but there's still some more goodies I want to show you all. Some jewels. Some nuggets. Some gems, all right, that I'm drop. So let's pick them up.

[00:00:19] So web pack config, anybody have any questions in here about what's going on. Anything, it can be simple, don't, there's no stupid question.
>> Scott: So maybe webpack gets a job. A great way to figure out what a tool is doing is to go see the result of what it did.

[00:00:39] And if you just go look in bundle.js you can see what webpack did. Not only did it put all these comments in here, which is awesome. I don't know why it did all that, but obviously, you can see here it's creating common JS here. It's polyfilling common JS.

[00:00:54] This is common JS right here. So that's what it's doing. This is really the main reason we use web pack. The other stuff is just awesome, the building, and then the result of our code is here.
>> Scott: Browser ready ES five. That is a great way and then of course it also put in the source map linking right here which is awesome, because I told it to.

[00:01:19] Really great. And it links to this source map right here. Don't look at it. Okay, so that's what webpack does, so let's just go over again, what's going on in here, and then this time I'll go into more detail about the individual properties. So Dev Tool. There's like 30 different options you can put here.

[00:01:34] It's ridiculous, and they all do different things. They all have different build times. They all have different settings and they're made for different environments. Source maps is exactly what it sounds like. This is telling webpack, hey, create a source map for my files. And that's what it did, it created bundle.js.map right here.

[00:01:52] That's what it did. There's other ones like eval, where it will literally wrap your code in an eval and use an inline source map that way. For performance reasons, you probably understand that's probably not good for production, but maybe good for development. I don't know. But there's tons of other options that webpack offers for dev tool.

[00:02:17] I encourage you to experiment with them and what not. I usually just keep it on source maps, unless it just gets so big that it just takes so long to generate source maps. Then I'm just like all right I need to invest in a different option. And they have different options for that.

[00:02:29] Debug is exactly what it sounds like. Entry, again, this is the entry, the root module for our module. Webpack you can have more than one entry, in our case we only have one. But you can say hey, there are going to be three different module dependency trees in this application.

[00:02:47] This one starts here, this one starts here, this one starts here. You can totally do that with webpack. Which will also generate three different outputs. And you can do that too. So the syntax for that is really not that difficult. You would just put an array here, like this and you'll put the names that you want.

[00:03:05] And then down here in file name, you get access to the hash and stuff like that and you can name them however you want it. You can also use an object here and explicitly name them the way you want them to and then you can reference them down here in output.

[00:03:20] So there's so many ways you can do it. You can also do code sharing where it's like, all right, we have two different module trees, but they're also sharing this common library right here. So we're going to allow them to share it but only load it once. It's pretty cool.

[00:03:36] Or you can even say I want to use some of these modules from this module tree, on this module tree and split the code. It's pretty cool. Webpack is like ridiculous. I'll admit the learning curve with web pack is just monstrous, it's crazy. It's really nasty, I'm not gonna lie.

[00:03:53] Compared to Gope or even Grunt it's just like [NOISE], I don't know. Like you gotta be some type of scientist to understand what's going on.
>> Speaker 2: How should you approach?
>> Scott: How should you approach it? The way I approach it is, I only use it for things like this.

[00:04:09] But like again, it's capable of everything. But usually when it gets to the point where I don't know how to do it and I can't figure out, I use Gope, I just do it in Gope. And that's what I do, me personally. Should I invest time and learn webpack more?

[00:04:21] Probably, but, I'm not a scientist.
>> Speaker 3: Is there a similarity between JSPM?
>> Scott: Yeah, so JSPM uses system JS as a module loader, and system JS is actually to the spec the way modules are supposed to be ES6 modules. And System JS using the ES6 polyfill shim, so technically it is the way that models are meant to be, whereas webpack actually just converts your syntax to common JS.

[00:04:53]
>> Speaker 3: So if you learn, if you're learning webpack, there's not gonna be a lot of carry over in your knowledge to JSPM?
>> Scott: No, not really. JSP, like I said, so, System JS is compared to webpack, where they both bundle your code, but JSPM takes it from JS and then it attaches a package manager to it that can fetch packages from GitHub, Bower, npm, of course and any other repository that you want.

[00:05:19] It even has its own repository where. That's JSPM. It's just like the jack of all trades for building applications. It's just as far as features, it's just not there yet for webpack. Webpack is exploding mainly because of react and stuff, so there is so much stuff involved with it.

[00:05:35] Where JSPM is pretty good and it does a good job, it just hasn't gotten there yet. But it will be the standard and I'm glad that England are supporting, it because it's the tool to use, for sure.
>> Speaker 4: What's it lacking that's holding it back in [INAUDIBLE]?
>> Scott: I think it's just the community.

[00:05:48] The community behind webpack is just so far greater. Mainly because of react. It's just more people are developing on it, so it's expanding. Webpack two is on the horizon. JSPM was created by Guy Bedford, just one guy who made this. And he also makes it in JS, so it's just like one person doing this and then he's got community behind him, but not like webpack does.

[00:06:08] So I really, that's just a big issue but as the modules and stuff become native in a browser, I think JSPM would just take over, because there is a small difference in how you load modules with JSPM versus webpack, so it's kind of tricky but it is a standard.

[00:06:26] So eventually people will have to adopt it. This resolve here is actually pretty cool. We have these extensions here which tell the webpack, hey, these are the files we're gonna use. There's another trick we're gonna do here and you can say root and you can give it a root.

[00:06:48] In this case, I'll say app, and then now I don't have to have relative paths inside of my app. So whereas if I had a- Really?
>> Speaker 5: [LAUGH]
>> Scott: My god. I know. What is going on? Okay, let's just not click on that file.
>> Speaker 5: [LAUGH]
>> Scott: But what's happening is this root right here is saying, I want to resolve all module imports to this path, so therefore you don't have to relative paths anymore inside your, import inside your module.

[00:07:24] They all resolve to this. But I've had conflicts with typescript's Linter in this. So, because the typescript linter will look ahead, or I'm sorry, the typscript tools will look ahead to find the right path for you. And because you aren't using a relative paths, it will freak out.

[00:07:37] It'll be like, I can't find it. So, typescript will freak out but it'll load. So, I'm sure there's a way to fix that. And you can tell typescript, hey, this is also the relative path, but I haven't dug into that. But just a little nugget.
>> Speaker 3: I think that's still an open issue for typescript.

[00:07:55]
>> Scott: Is it?
>> Speaker 3: There's a, unless you're open to add mappings for search files.
>> Scott: Yeah, that would be awesome. Output, again, path file name. So loaders, again, this is where you load up your loaders. You say, any file, any module that matches this, rejects, pass it through this excluding this.

[00:08:21] You can type in include which is the inverse of exclude, you can include additional files or file or folders or whatever. And you can also pipe in different loaders here. All right you can say exclamation and you can put like, I don't know, a raw loader here. And the way it's going to work is actually going to read it from right to left, not left to right.

[00:08:44] It's weird. But don't use a raw loader here. A raw loader just brings it in as raw text. So this is how you pipe in additional loaders into webpack, just like in Gope you have different plug-ins streaming to each other, it's very similar here. So you can do that.

[00:08:59] You would see something like this if you were using Sass. And you piped it through the Sass compiler first, and then you piped it through the style loader, and then you piped it through the raw loader, so you can bring it as raw text or something like that.

[00:09:14] So that's where you would normally see that. Devserver, again this is just telling devserver passing options to the global devserver. And plugins is really awesome. This is where you can add things to webpack like Uglify, HTML templates, a notifier that ties into the notification system in Mac, when your bundles complete, all types of plugins you can put here.

[00:09:40] So, there's tons of them. They're completely different than loaders, though. They're not the same. Loaders transform your files. Plugins just add functionality to webpack. And may also transform files