Webpack

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 1
NPM
1
yarn add --dev @electron-forge/plugin-webpack
Copied!
1
npm install --save-dev @electron-forge/plugin-webpack
Copied!
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:
package.json
forge.config.js
1
// If your config is only in package.json:
2
// Only showing the relevant configuration for brevity
3
{
4
  "config": {
5
    "forge": {
6
      "plugins": [
7
        ["@electron-forge/plugin-webpack", {
8
          "mainConfig": "./webpack.main.config.js",
9
          "renderer": {
10
            "config": "./webpack.renderer.config.js",
11
            "entryPoints": [{
12
              "name": "main_window",
13
              "html": "./src/renderer/index.html",
14
              "js": "./src/renderer/index.js"
15
            }]
16
          }
17
        }]
18
      ]
19
    }
20
  }
21
}
Copied!
1
// If you have set config.forge to a JavaScript file path in package.json:
2
// Only showing the relevant configuration for brevity
3
module.exports = {
4
  plugins: [
5
    ['@electron-forge/plugin-webpack', {
6
      mainConfig: './webpack.main.config.js',
7
      renderer: {
8
        config: './webpack.renderer.config.js',
9
        entryPoints: [{
10
          name: 'main_window',
11
          html: './src/renderer/index.html',
12
          js: './src/renderer/index.js'
13
        }]
14
      }
15
    }]
16
  ]
17
}
Copied!
The above configuration is the default for the Webpack template.
Node integration
The following configuration option is available in Electron Forge version 6.0.0 beta 58 and above.
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:
package.json
forge.config.js
1
// If your config is only in package.json:
2
// Only showing the relevant configuration for brevity
3
{
4
  "config": {
5
    "forge": {
6
      "plugins": [
7
        ["@electron-forge/plugin-webpack", {
8
          "mainConfig": "./webpack.main.config.js",
9
          "renderer": {
10
            "nodeIntegration": true, // defaults to false
11
            "config": "./webpack.renderer.config.js",
12
            "entryPoints": [/* entry point config */]
13
          }
14
        }]
15
      ]
16
    }
17
  }
18
}
Copied!
1
// If you have set config.forge to a JavaScript file path in package.json:
2
// Only showing the relevant configuration for brevity
3
module.exports = {
4
  plugins: [
5
    ['@electron-forge/plugin-webpack', {
6
      renderer: {
7
        nodeIntegration: true, // defaults to false
8
        config: './webpack.renderer.config.js',
9
        entryPoints: [/* entry point config */]
10
      },
11
      mainConfig: './webpack.main.config.js',
12
      // other Webpack plugin config...
13
    }]
14
  ]
15
}
Copied!
Content Security Policy
The following configuration option is available in Electron Forge version 6.0.0 beta 58 and above.
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):
package.json
forge.config.js
1
// If your config is only in package.json:
2
// Only showing the relevant configuration for brevity
3
{
4
  "config": {
5
    "forge": {
6
      "plugins": [
7
        ["@electron-forge/plugin-webpack", {
8
          // other Webpack plugin config...
9
          "devContentSecurityPolicy": "default-src 'self' 'unsafe-inline' data:; script-src 'self' 'unsafe-eval' 'unsafe-inline' data:",
10
          // other Webpack plugin config...
11
          "mainConfig": "./webpack.main.config.js",
12
          "renderer": { /* renderer config here, see above section */ }
13
        }]
14
      ]
15
    }
16
  }
17
}
Copied!
1
// If you have set config.forge to a JavaScript file path in package.json:
2
// Only showing the relevant configuration for brevity
3
module.exports = {
4
  plugins: [
5
    ['@electron-forge/plugin-webpack', {
6
      // other Webpack plugin config...
7
      devContentSecurityPolicy: `default-src 'self' 'unsafe-inline' data:; script-src 'self' 'unsafe-eval' 'unsafe-inline' data:`,
8
      // other Webpack plugin config...
9
      mainConfig: './webpack.main.config.js',
10
      renderer: { /* renderer config here, see above section */ },
11
    }]
12
  ]
13
}
Copied!
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
The following configuration option is available in Electron Forge version 6.0.0 beta 60 and above.
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):
package.json
forge.config.js
1
// If your config is only in package.json:
2
// Only showing the relevant configuration for brevity
3
{
4
  "config": {
5
    "forge": {
6
      "plugins": [
7
        ["@electron-forge/plugin-webpack", {
8
          // other Webpack plugin config...
9
          "devServer": {
10
            "stats": "verbose"
11
          },
12
          // other Webpack plugin config...
13
          "mainConfig": "./webpack.main.config.js",
14
          "renderer": { /* renderer config here, see above section */ }
15
        }]
16
      ]
17
    }
18
  }
19
}
Copied!
1
// If you have set config.forge to a JavaScript file path in package.json:
2
// Only showing the relevant configuration for brevity
3
module.exports = {
4
  plugins: [
5
    ['@electron-forge/plugin-webpack', {
6
      // other Webpack plugin config...
7
      devServer: {
8
        stats: 'verbose'
9
      },
10
      // other Webpack plugin config...
11
      mainConfig: './webpack.main.config.js',
12
      renderer: { /* renderer config here, see above section */ }
13
    }]
14
  ]
15
}
Copied!
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
1
{
2
  "name": "my-app",
3
  "main": "./.webpack/main",
4
  ...
5
}
Copied!
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
1
const mainWindow = new BrowserWindow({
2
  webPreferences: {
3
    preload: MAIN_WINDOW_PRELOAD_WEBPACK_ENTRY,
4
  }
5
});
6
​
7
mainWindow.loadURL(MAIN_WINDOW_WEBPACK_ENTRY);
Copied!
Native Modules
The following instructions are for Electron Forge version 6.0.0 beta 58 and above.
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.
Warning: Electron Forge needs to monkeypatch the asset relocator loader in order for it to work with Electron properly, so the version has been pinned to ensure compatibility. If you upgrade that version, you do so at your own risk.
webpack.main.config.js
1
module.exports = {
2
  module: {
3
    rules: [
4
      {
5
        // We're specifying native_modules in the test because the asset
6
        // relocator loader generates a "fake" .node file which is really
7
        // a cjs file.
8
        test: /native_modules\/.+\.node$/,
9
        use: 'node-loader',
10
      },
11
      {
12
        test: /\.(m?js|node)$/,
13
        parser: { amd: false },
14
        use: {
15
          loader: '@vercel/webpack-asset-relocator-loader',
16
          options: {
17
            outputAssetBase: 'native_modules',
18
          },
19
        },
20
      },
21
    ]
22
  }
23
}
Copied!
If the asset relocator loader does not work for your native module, you may want to consider using the externals configuration.
In v6 beta versions before beta 58, the Webpack templates used a fork of the asset relocator, @marshallofsound/webpack-asset-relocator-loader. It is recommended to remove the fork and migrate to @vercel/webpack-asset-relocator-loader.
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.
Electronegativity
Auto Unpack Native Modules
Last modified 4mo ago
Copy link
Edit on GitHub
Contents
What happens in production?
How do I do virtual routing?