In case you are not aware, Babel is a toolchain that mainly converts ECMAScript 2015 and the preceding code into a regressive version of JavaScript that is compatible with current and older browsers or environments. The main things that Babel can do for you as a developer are as follows:

• Transform syntax
• Polyfill features that are missing in your target environment using @babel/polyfill
• Perform source code transformations, called code mods

Webpack uses an API for the Babel interface. If you attempt to install it with the command line, you should get the following message:

The Node.js API for babel has been moved to babel-core.

If you receive this message, it means that you have the npm package that Babel installed and it is using the short notation of the loader in the Webpack configuration file (which is not valid anymore, as of Webpack versions 2 and later).

In webpack.config.js, you may see the following script:

  {
    test: /.m?js$/,
    loader: 'babel',
  }

As a result of installing Babel, Webpack tries to load the babel package instead of babel-loader.

To resolve this, the npm package Babel should be installed, as it is deprecated in Babel version 6. If you're using Babel version 6, then you should instead install @babel/cli or @babel/core. If one of your dependencies is installing Babel and you cannot uninstall it yourself, use the complete name of the loader in webpack.config.js:

  {
    test: /.m?js$/,
    loader: 'babel-loader',
  }

The example you have followed so far should stand you in good stead for using Babel in general, but one key use of Babel is the customized loader. This is a topic covered more extensively in the final chapter of this book, but we will now go over how Babel works with customized loaders, especially since you may not use a loader that you customize yourself.

babel-loader exposes a loader-builder utility that allows users to add custom handling of Babel's configuration for each file that it processes.

The .custom phrase accepts a callback that will be called with the loader's instance of Babel. This is so that the tool can ensure that it uses the same @babel/core instance as the loader itself.

In cases where you want to customize but don't actually have a file to call .custom, you can also pass the customize option with a string pointing to a file that exports your custom callback function.

Probably the best way to learn how this works is through a practical example; let's go through one in the following exercise.

The goal of this example is to demonstrate how babel-loader can be used to build custom loaders.

This example first uses a custom filename. This can be whatever you want, but for the sake of this exercise, the name we have chosen is ./my-custom-loader.js. You can export from this location or wherever you want:

1. Begin by creating a custom file by using the following code in ./my-custom-loader.js:

module.exports = require("babel-loader").custom(babel => {
 function myPlugin() {
 return {
 visitor: {},
 };
 }

In the preceding code block, we can see a require statement. This uses babel-loader, which we will need to create the custom loader.

2. Now, we need to configure our project to set up passing for the loader, as shown: 

return {
    customOptions({
        opt1,
        opt2,
        ...loader
    }) {
        return {
            custom: {
                opt1,
                opt2
            },
            loader,
        };
    },

Note that custom: refers to pulling out any custom options that the loader might have. Also, note the loader reference after the two options. This passes the options back with the two custom options removed.

3. Then, we pass Babel's PartialConfig object, setting the normal configuration as return cfg.options:

config(cfg) {
    if (cfg.hasFilesystemConfig()) {
        return cfg.options;
    }

    return {
        ...cfg.options,
        plugins: [
            ...(cfg.options.plugins || []),
            testPlugin,
        ],
    };
},

In the preceding code, where the testPlugin statement is made, we can see the inclusion of a custom plugin, which will then be available as an option.

4. Now, let's make the placeholder text to test the custom loader on. The preceding code should generate something like the following:

result(result) {
return {
    ...result,
    code: result.code + "
// Generated by this custom loader",
    };
    },
    };
});

This code block shows that the custom loader is generating code.

5. Ensure that your configuration is made correctly. Note that you should always replace __dirname and custom-loader with a name of your choice. In the Webpack configuration module, type the following:

.exports = {
    module: {
        rules: [{
            loader: path.join(__dirname, 'custom-loader.js'),
        }]
    }
};
customOptions(options: Object): {
    custom: Object,
    loader: Object
}

The preceding block shows you how to set up and configure customOptions.

6. Given the loader's options, split the custom options out of the options for babel-loader:

config(cfg: PartialConfig): Object

7. Given Babel's PartialConfig object, return the options object that should be passed to babel.transform:

result(result: Result): Result

Both of the preceding code blocks refer to the contents of the custom file we have built, which, in this example, is ./my-custom-loader.js.

Note that Babel's result object will allow loaders to make additional tweaks to it.

That should be all you need to get the custom loader working with Babel. Read the last chapter of this book on authoring and custom loaders for further information. Another key API often used in Webpack projects is the Node.js API.