Configuring Your Webpack Builds

[00:00 - 00:05] How to use .n with build tools. Welcome to lesson 1.4.

[00:06 - 00:14] We're going to make a webpack bundle using .n. To those of you who haven't used webpack before, it's like zip for JavaScript developers.

[00:15 - 00:21] These zip files are called bundles. So if you want to deploy code to a server in an easy way, you make a bundle.

[00:22 - 00:27] And typically, you use webpack. Or it will be built into your build tool for you.

[00:28 - 00:37] This is typically for front-end, hence the name webpack for web. But it can also be good for deploying to scripting providers like Amazon Lambda .

[00:38 - 00:52] Not only does it bundle your node modules into one file, you get to do a bunch of programmatic things to your code, like minifying for size. And in this case, we'll be saving the current environment variable valuables where they are needed.

[00:53 - 01:04] And by saving, I mean, since during development, your code will get the values from the environment. You may not always be able to set these values, so you set them in advance.

[01:05 - 01:12] This is called burn-in. Tricky thing is deciding whether or not you want to burn in your values.

[01:13 - 01:20] Because once it's built, there's no changing it. If you want to change the environment values, you need to replace the bundle.

[01:21 - 01:43] So when would you want to burn in your dot-end? When you can't control the environment from a pre-built interface, such as if you have a static front-end, or if you're uploading directly to a server where you can't , or you're using commands like SSH and you can't set the values easily.

[01:44 - 02:01] And actually, before we continue, even if you do burn in, your environment variables to a bundle, please avoid uploading your bundles to get. It's unsafe, it's messy, and even if you don't have secrets, it's not a good practice.

[02:02 - 02:07] So when would you not do burn in? You don't need to do burn in even for bundles.

[02:08 - 02:34] And if you're deploying to a service that has a dashboard for setting your environment variables, such as AWS Lambda, which we will cover in a later video, you can set your values in that dashboard. For the demo that we're going to do, we'll be building a very simple node bundle of a script that probably would not need burn in, but it makes it easy to understand burn in of the environment variables, how it works with Webpack.

[02:35 - 02:44] We'll first build it without burn in, so you can see. And then we'll show the difference in the bundle after we add dot-end.

[02:45 - 03:07] So for the demo, we're going to start with the 1.3 code, and we're going to first start off by installing Webpack. So I'm going to do that right now, but I'm not just going to install the Web pack NPM library, but I'm also going to install the CLI just so that way we can work with it more easily.

[03:08 - 03:28] Now that we've installed Webpack and the CLI, I'm going to add a script to the package JSON so that way we can run Webpack using the dev dependencies. That way you don't have to install it as a global bundle Webpack.

[03:29 - 03:35] To use Webpack, we need a config file in the root folder. I'm going to make that now.

[03:36 - 03:49] Webpack.config.js. It's going to go in the root folder, and I'm going to paste a basic example and then go over how it works.

[03:50 - 04:02] So this is an example that does not use dot-end, as in this is not using burn- in. Some things about it is that it's in development mode.

[04:03 - 04:13] It uses an entry point of index.js, which should be this file. And it outputs a main dot-js in a folder called dist.

[04:14 - 04:23] I'll build the Webpack and then you'll be able to see what happens. NPM run bundle.

[04:24 - 04:30] So now we have a dist folder. We have a main dot-js and it's got a bunch of stuff in there.

[04:31 - 04:47] You'll notice that if you go to where the code is in here, you can actually control if one of the variables, server URL, and see that it is still says process.n. server.url.

[04:48 - 05:04] That means that it will use the value of server URL on the actual server environment where this is being served to or where it's deployed. That's what we'll do is see what happens when we do add the burn-in.

[05:05 - 05:17] So to do that, we actually add dot-end in the Webpack config file directly. So we'll require that, require dot-end, and we'll configure it.

[05:18 - 05:38] And now what we'll do is we'll add a small plugin to Webpack that converts the dot-end like the environment variables into their respective values. We can even control the mode type using our node-end value.

[05:39 - 06:00] So to do that, we can set a variable which defaults to development, and then if the value of node-end is production, then we change that variable value to production, and then we change the mode to WP mode. Now let's see what the bundle looks like when you run it.

[06:01 - 06:05] NPM run bundle. Okay, it builds very quickly.

[06:06 - 06:16] When you look at the main, again, it's a lot harder to read. So let's look up server URL now.

[06:17 - 06:42] And actually, you'll see the value in their localhost 3000, which is the value in our dot-end file. I think I will point out is that if you are destructuring process dot-end, so you can sometimes do console log process dot-end.

[06:43 - 07:00] And you know, this is an object containing all the values, but it can be unstable. Like you won't always get the results that you want with WPAC because it doesn 't always work with the compiled code.

[07:01 - 07:14] It doesn't this example because of the way that we're doing it, but not all CLI tools do it the same way. So I recommend you be careful with using it in this way.

[07:15 - 07:30] The reason is that destructing process dot-end doesn't really work once the web pack is built and it will always print the whole object. This is the same as with Babel, which is another library which we'll be covering later.

[07:31 - 07:46] One thing that I will point out is that if you're using webpack and you have dot-end, you don't actually need your dot-end in your index JS because dot-end will already be evaluated. npm run bundle.

[07:47 - 08:17] So what will happen is server URL will evaluate even though we've generated the bundle and even though we don't have dot-end installed there. You can even very easily swap this dot-end with dot-end flow and it will work pretty much the same way.

[08:18 - 08:26] That's all for now. I've added some supplementary information, including information about an alternative dot-end webpack and why I recommend this method instead.