Webpack is easy > Loaders and plugins

In the first article of this series we went through a basic webpack configuration, where we didn’t do much, but serving files in our project.

What did you think? Not too complicated, right?

Now, it’s time to add two more concepts. This concepts are really important in 2017, as we all want to write our javascript with the new ES6 syntax, all of our CSS with the shiny new specifications, and have as much fancy code as possible.

All this is possible with loaders and plugins.

The idea behind could sound a little bit weird, but once we get to go through them, is not going to be complicated anymore. I new Promise().

Loaders

They define how your code will look like. With loaders, you can modify any part of your code. You can simply point out any file extension to do the modification.

For example:

Let’s say we are making a new project, and we wan’t to write the whole code with the new ES6 syntax, because it’s how we should be writing it in 2017. Right? But, there is a little problem. Not all the browsers supports all new features of ES6 syntax, and we want them to work on all of them.

Well, the best way to do that at the moment, is to use a transpiler. For this example, we are going to use babel ⚡.

Babel will go through your code and transpile it all to ES3/4/5 which every browser supports.

Let’s configure it!

First, we need to install babel-core which you need to be able to use babel, babel-loader which will do the code modification and babel-preset-es2015, which will pick all the stable features of ES6 to your code.

$ npm install babel-core babel-loader babel-preset-es2015 --save-dev

In addition, we need to have a .babelrc file in the root of your project that look like this:

{
    "presets": [
        "es2015"
    ]
}

So when babel runs in any environment, it will pick that file and use this preset.

Then, you can go to your config and add the following lines:

module: {

    rules: [
        {
            test: /\.js$/,
            loader: 'babel-loader'
        }
    ]
}

If you are used to webpack 1.x, then you might change rules keyword to use loaders instead and remove -loader from every loader.

Also, you can check here more differences between webpack 1.x and 2.x.

We can run our prod script to see what’s the output.

$ npm run prod
> easy-webpack-config@1.0.0 prod /Users/aanglada/Projects/easy-webpack-config
> webpack --env.production
Hash: d2ab8a6ef22962d9eba2
Version: webpack 2.3.2
Time: 794ms
         Asset     Size  Chunks             Chunk Names
main.bundle.js  2.98 kB       0  [emitted]  main
   [0] ./index.js 284 bytes {0} [built]

Good! We can go and check now that our bundle look like code that the browser will understand. Did it?

If you need to use more than one loader in the same rule, it’s super simple, just do the following:

module: {

    rules: [
        {
            test: /\.js$/,
            use: ['babel-loader', 'whatever-loader']
        }
    ]
}

Replace loaders entry with use, and in this case the whole thing will be an array of loaders that will apply sequentially.

Another use case, will be writing coffeescript or typescript, so you code in any of those, but the final output will be something that all the browsers know how to deal with, javascript! 🎉🎉

Tell you what? There are loaders for everything, I normally look for them by typing “[whenever thing I need to use]-loader” in google and I always find out what I want 😂 (funny but true).

Loaders gone! 🤜 Let’s have a look at plugins.

Plugins

So, we came to the interesting part, plugins are basically webpack itself. The whole webpack is a plugin, which its behaviors can be modified by yourself, just adding a new plugin in the plugins section. Interesting right?

What does it means? Webpack is a plugin with behavior by default, bundle assets. Adding a plugin in your configuration will add, sequentially, one more step to the queue of tasks that webpack needs to do before giving away your files.

It has some build-in plugins, most of them to optimize your code, go here to see all of them.

Notice, this is webpack 1.x docs, so if you are using webpack 2.x is worth to check whether or not the plugin is still in support.

The most common behavior to add will be minimizing our files. We all want to have as little javascript files as possible to aim for the fastest scripting time and in fact the fastest page load. So, let’s add this behavior to our webpack configuration.

plugins: [
    new webpack.optimize.UglifyJsPlugin({
        minimize: true,
        sourceMap: true,
        compress: {
            warnings: false
        }
    })
]

We run our prod script again and…! Boom 💥

$ npm run prod
> easy-webpack-config@1.0.0 prod /Users/aanglada/Projects/easy-webpack-config
> webpack --env.production
Hash: d2ab8a6ef22962d9eba2
Version: webpack 2.3.2
Time: 455ms
         Asset       Size  Chunks             Chunk Names
main.bundle.js  716 bytes       0  [emitted]  main
   [0] ./index.js 284 bytes {0} [built]

Our code should be minified now and ready to be used in production.

Conclusion

Loaders and plugins add behaviors to our webpack configuration, making it more flexible and powerful.

Feel free to check out the repo, all the code from this article will be in a branch called loaders-and-plugins.

aganglada/easy-webpack-config

Also made some repos that will help you start your development process in 1…2…3…

aganglada/preact-minimal

aganglada/react-minimal

What’s comming

This is a series of articles to help you configure webpack more easily, so I will show you everything you want to know about it.

• Aliases
• Performance
• Code splitting
• Tree shaking

You can also tell me what do you want to read next.

Follow me on twitter and medium to get more webpack and frontend updates:

👨‍🚀 twitter @aganglada

✍️👨‍🚀 Alejandro Garcia Anglada

Thanks for reading! 👏