We are using electron-webpack (EW) to compile and bundle the application. This doc aims to point the specifics of our config compared to a simple one.
EW have some concept kinda enforced. Here is what we do differently.
- We do not have a
common
folder, it is only leveraged by EW thanks to@common
imports. - Our
main
target is located in webpack.config.main.js - Our
renderer
target is located in webpack.config.renderer.js - We also have a
webui
target that doesn't get along with EW, so it is executed separately via webpack.config.webui.jsNB: a PR could easily fix that IMO (@magne4000)
Nothing too fancy here. Mainly, like for the renderer part, it uses webpack.config.common.js which patches/add different things (TS, loaders, externals, etc.)
By default, EW generates a unique renderer
entry.
As we have multiple ones, they are added here.
The worker is a renderer entry as the others.
Migration files are also compiled here as they are executed by the worker.
The preload.js
is also generated here, and is directly written on the disk.
Extends webpack.config.base.js which is a common base when we are running outside EW process.
It is currently outside of EW process because:
- It uses a different
target
than the renderer or the main - We can't return multiple webpack configurations in EW custom
webpackConfig
- Actually we can but only in
mode==development
but not in `mode==production
- Actually we can but only in
- In dev mode, pages are loaded from
localhost
- But some files are required to be on the filesystem, like the preload and the migration scripts
- for simplicity, webui is also written on the filesystem (no HMR)
- HMR is active
- On the main process, reloads the whole app
- On the worker, reloads the whole app (to optimize this we must tweak services architecture)
- On the other renderers, React, stylesheets, reducers, and probably a lot of other things are reloaded on the fly
electron-builder
config files have someextraResources
andfiles
lines to cope with the fact that we use__dirname
here and there- One goal would be to minimize those lines to only the necessary ones
- All files should use
export default
instead ofmodule.exports
syntax (mainly for migration files)- This is due to the fact that
babel-runtime
adds its own exports, and we can't mix both syntax
- This is due to the fact that
- Always prefer
require
instead offs
related modules if possible