Adding npm Scripts for Environment Builds

[00:00:00]
>> Sean Larkin: And you'll notice that actually, Webpack ran successfully. And so but there's no config! There's no config. So Webpack by default, before Webpack 4, you really were only required to specify two properties, your input and your output. And we were like, we don't need to do that. People don't need to do that.

[00:00:22]
If we do it by default, then people don't even have to use a config. And they can get started really easily, like you all have done today, just using Webpack for the first time, literally, just now. Webpack looks for an entry property and we default to source and then index.js.

[00:00:43]
And actually, we don't even specify that much. We just say, I think that is all we provide there. So let's say down the road, you add a config and you wanna support type script. It could just be index.ts and you'd never have to provide that entry property. So but you do see this really helpful warning and we say hey, you didn't set a mod option.

[00:01:09]
You really should. We fell back to production mode anyway but here's where you can learn some more. And we'll cover what mode is. But so now, we can actually run Webpack from our scripts. We have access to run it now. This is what we would pass to our CI system.

[00:01:29]
We'd have node installed and we would just run this command after doing an mpm install. And so, but we can take it a step further. mpm has this awesome capability to compose scripts. So or I guess I should say it started with mpm and yarn supports it as well.

[00:01:49]
So let's say running just npm webpack, there might be different environments that you wanna build in. And so much that we're enforcing you now to think about that, that we have a mode property that specifies development or production. If you can provide that like that information like I'm just my local div environment until webpack that.

[00:02:11]
We created this property, so we could optimize for build speed over production quality or vice versa depending on what mode you're in. And so, you have the ability to compose scripts. So if you wanted to pass let's say a mode, like the mode property to webpack without the config, you can still do so but we don't wanna have to basically write out this command every single time and we can just call the original command but just add on to it, so add a dev property nd you can actually call an existing command, so npm run webpack.

[00:02:50]
And then, with this syntax here, so this --, this basically says pipe in the next arguments onto the original commands. So I can say this --mode development. So now, you can compose without having to basically rewrite like, when these get pretty large or over the top, you're gonna start noticing that like you have a billion scripts here.

[00:03:19]
And so, you, if you need to make a change, you wanna make a change once and it affects the other commands as desired. And so, why don't we just try running this and see what it gives us. So, npm run dev. And you could even see, it even tells you hey, it took this and then now we just converted it to this here.

[00:03:46]
And there we go, even the feedback has changed. Like if you look at the top, you get some slightly different reporting information, instead now, we show instead of ID's for the modules, we show the source path to the module. We even formated in a way that like if you're using, whose using VS code here?

[00:04:05]
If you haven't tried yet, dip yourself into the water and try it for the first time and you'll never go back to anything else, I'll just say that. [LAUGH] Unless like you're working on java all day and you might need Intel ja or whatever. But vs code is so nice, it's like it can provide you with this whole string and I can click command and boom, instantly into the module.

[00:04:27]
And you'll see here, like I don't even have anything in here. Web pack can still consume that though. It's just looking for that results file and it collects the source. So, why don't we, now dev is not gonna be your only environment. Why don't we add a prod script as well?

[00:04:44]
So, prod and we'll do the same thing expect our mode is gonna be production.
>> Sean Larkin: And let's run it. I keep forgetting, npm run prod.
>> Sean Larkin: There we go. So this is back to the original default that Webpack falls back to if you're not providing a mode. But we really feel the obligation to encourage you to think about having two different environments for your build.

[00:05:16]
It's super important, it's what can allow you to have faster builds or more optimized builds.
>> Sean Larkin: So let's see here, we could probably take this code. [SOUND] Why don't we just commit it to our, well, I don't wanna commit to this branch. Maybe I'll just jump to the next one here.

[00:05:44]
So we have a bunch of branches and I kinda have little micro steps. So the next one is debug scripts. So essentially, I love providing escape hatches. Who has ever even debugged a node process before? One of the most painful things is trying to console log your way through a node app or a node script and it's no different if you're wanting to debug why webpack is doing something.

[00:06:12]
And so, let's see if we can check it out. git checkout feature/0, what did I call it? Zero three? Let's try it. Okay.
>> Sean Larkin: Yeah, why don't we just jump straight to it? And then, I'm just gonna use force because it's probably gonna be like but you have unstaged changes.

[00:06:34]
There we go.