The Webpack plugin allows you to use standard Webpack tooling to compile both your main process code and your renderer process code, with built in support for Hot Module Reloading in the renderer process and support for multiple renderers.

Installation

yarn add --dev @electron-forge/plugin-webpack

npm install --save-dev @electron-forge/plugin-webpack

Basic Usage

Configuration

You must provide two Webpack config files: one for the main process in mainConfig, and one for the renderer process in renderer.config. The complete config options are available at WebpackPluginConfig. For example, in your Forge configuration:

// If your config is only in package.json:
// Only showing the relevant configuration for brevity
{
  "config": {
    "forge": {
      "plugins": [
        ["@electron-forge/plugin-webpack", {
          "mainConfig": "./webpack.main.config.js",
          "renderer": {
            "config": "./webpack.renderer.config.js",
            "entryPoints": [{
              "name": "main_window",
              "html": "./src/renderer/index.html",
              "js": "./src/renderer/index.js"
            }]
          }
        }]
      ]
    }
  }
}

// If you have set config.forge to a JavaScript file path in package.json:
// Only showing the relevant configuration for brevity
module.exports = {
  plugins: [
    ['@electron-forge/plugin-webpack', {
      mainConfig: './webpack.main.config.js',
      renderer: {
        config: './webpack.renderer.config.js',
        entryPoints: [{
          name: 'main_window',
          html: './src/renderer/index.html',
          js: './src/renderer/index.js'
        }]
      }
    }]
  ]
}

The above configuration is the default for the Webpack template.

Node integration

If you set nodeIntegration to true in a given renderer's BrowserWindow constructor, you'll need to set the same nodeIntegration value in the corresponding Webpack plugin renderer's configuration:

// If your config is only in package.json:
// Only showing the relevant configuration for brevity
{
  "config": {
    "forge": {
      "plugins": [
        ["@electron-forge/plugin-webpack", {
          "mainConfig": "./webpack.main.config.js",
          "renderer": {
            "config": "./webpack.renderer.config.js",
            "entryPoints": [/* entry point config */],
            "nodeIntegration": true // defaults to false
          }
        }]
      ]
    }
  }
}

// If you have set config.forge to a JavaScript file path in package.json:
// Only showing the relevant configuration for brevity
module.exports = {
  plugins: [
    ['@electron-forge/plugin-webpack', {
      mainConfig: './webpack.main.config.js',
      renderer: {
        config: './webpack.renderer.config.js',
        entryPoints: [/* entry point config */],
        nodeIntegration: true // defaults to false
      },
      // other Webpack plugin config...
    }]
  ]
}

Content Security Policy

In development mode, you can set a content security policy by setting devContentSecurityPolicy in your Forge Webpack plugin configuration (note that it is separate from the main and renderer configuration):

// If your config is only in package.json:
// Only showing the relevant configuration for brevity
{
  "config": {
    "forge": {
      "plugins": [
        ["@electron-forge/plugin-webpack", {
          "mainConfig": "./webpack.main.config.js",
          "renderer": { /* renderer config here, see above section */ },
          // other Webpack plugin config...
          "devContentSecurityPolicy": "default-src 'self' 'unsafe-inline' data:; script-src 'self' 'unsafe-eval' 'unsafe-inline' data:",
          // other Webpack plugin config...
        }]
      ]
    }
  }
}

// If you have set config.forge to a JavaScript file path in package.json:
// Only showing the relevant configuration for brevity
module.exports = {
  plugins: [
    ['@electron-forge/plugin-webpack', {
      mainConfig: './webpack.main.config.js',
      renderer: { /* renderer config here, see above section */ },
      // other Webpack plugin config...
      devContentSecurityPolicy: `default-src 'self' 'unsafe-inline' data:; script-src 'self' 'unsafe-eval' 'unsafe-inline' data:`,
      // other Webpack plugin config...
    }]
  ]
}

Please note that if you wish to use source maps in development, you'll need to set 'unsafe-eval' for the script-src directive. Using 'unsafe-eval' will cause Electron itself to trigger a warning in the DevTools console about having that value enabled, which is usually fine so long as you do not set that value in production.

Dev server

In development mode, you can change most webpack-dev-server options by setting devServerin your Forge Webpack plugin configuration (note that it is separate from the main and renderer configuration):

// If your config is only in package.json:
// Only showing the relevant configuration for brevity
{
  "config": {
    "forge": {
      "plugins": [
        ["@electron-forge/plugin-webpack", {
          "mainConfig": "./webpack.main.config.js",
          "renderer": { /* renderer config here, see above section */ },
          // other Webpack plugin config...
          "devServer": {
            "stats": "verbose"
          }
          // other Webpack plugin config...
        }]
      ]
    }
  }
}

// If you have set config.forge to a JavaScript file path in package.json:
// Only showing the relevant configuration for brevity
module.exports = {
  plugins: [
    ['@electron-forge/plugin-webpack', {
      mainConfig: './webpack.main.config.js',
      renderer: { /* renderer config here, see above section */ },
      // other Webpack plugin config...
      devServer: {
        stats: 'verbose'
      }
      // other Webpack plugin config...
    }]
  ]
}

Project Setup

You need to do two things in your project files as well in order to make this plugin work.

First, your main entry in your package.json file needs to point at "./.webpack/main" like so:

package.json
{
  "name": "my-app",
  "main": "./.webpack/main",
  ...
}

Second, all loadURL and preload paths need to reference the entry points' magic global variables that this plugin will define for you. Each entry point has two globals defined: one suffixed with _WEBPACK_ENTRY, and the other suffixed with _PRELOAD_WEBPACK_ENTRY. These point to the paths for your renderer entry point and your preload script path, respectively. In the case of the main_window entry point in the earlier example, the global variables will be named MAIN_WINDOW_WEBPACK_ENTRY and MAIN_WINDOW_PRELOAD_WEBPACK_ENTRY. An example of how to use them is given below:

main.js
const mainWindow = new BrowserWindow({
  webPreferences: {
    preload: MAIN_WINDOW_PRELOAD_WEBPACK_ENTRY,
  }
});
​
mainWindow.loadURL(MAIN_WINDOW_WEBPACK_ENTRY);

Native Modules

If you used the Webpack or TypeScript + Webpack templates to create your application, native modules will mostly work out of the box. If you are setting up the plugin manually, you can make native modules work by adding the following two loaders to your module.rules configuration in your Webpack config. Ensure you install both node-loader and @vercel/webpack-asset-relocator-loader as development dependencies.

webpack.main.config.js
module.exports = {
  module: {
    rules: [
      {
        test: /\.node$/,
        use: 'node-loader',
      },
      {
        test: /\.(m?js|node)$/,
        parser: { amd: false },
        use: {
          loader: '@vercel/webpack-asset-relocator-loader',
          options: {
            outputAssetBase: 'native_modules',
          },
        },
      },
    ]
  }
}

If the asset relocator loader does not work for your native module, you may want to consider using the externals configuration.

Hot Reloading

All your renderer processes in development will have hot reloading enabled by default. It is unfortunately impossible to do hot module reloading inside a renderer preload script, WebWorkers, and the main process itself. However, Webpack is constantly watching and recompiling those files so to get updates for preload scripts simply reload the window. For the main process, just type rs in the console you launched electron-forge from and we will restart your app for you with the new main process code.

What happens in production?

In theory, you shouldn't need to care. In development we spin up webpack-dev-server instances to power your renderer processes, in prod we just build the static files. Assuming you use the globals we explained in Project Setup, everything should Just Work™ when your app is packaged.

How do I do virtual routing?

If you want to use something like react-router to do virtual routing in your app, you will need to ensure you use a history method that is not based on the browser history APIs. Browser history will work in development but not in production, as your code will be loaded from the filesystem, not a webserver. In the react-router case, you should use the MemoryRouter to make everything work.