Skip to content
This repository was archived by the owner on Oct 4, 2023. It is now read-only.
This repository was archived by the owner on Oct 4, 2023. It is now read-only.

Migration to use electron-webpack #310

Open
@develar

Description

@develar

Hi. First of all, thanks for excellent boilerplate.

Because it was clear, that electron-compile and electron-forge template for vue is definitely not a way to develop Vue application, I started to use this boilerplate.

But we can make it better and fix some current issues.

  1. HMR doesn't work. Hot reload works, but... it is not productive. I want to just change my vue component and see result without reload.
  2. TypeScript support.
  3. Minor — easy update boilerplate and get rid of boilerplate files in the project.

I have fixed these issues in the https://github.com/electron-userland/electron-webpack. This new project is not called as electron-vue-scripts (as was planned initially), because, actually, in this boilerplate nothing specific for Vue and nothing prevents us to reuse boilerplate for any Electron application for any framework (or mix frameworks).

  1. HMR — issue is that some loaders cannot detect hot reload mode if webpack-dev-server is running not as CLI. e.g. Hot reload not working with webpack-dev-middleware/webpack-hot-middleware on express server elm-community/elm-webpack-loader#98 And I can confirm, that vue-loader also doesn't support HMR in this case. Yes — we can fight and investigate/fix/apply special configuration for each used loader, but it is maintenance hell. Actually, nothing prevent us to run webpack-dev-server using CLI and even more — we should, because it helps to compile faster (for the same reason why https://github.com/trivago/parallel-webpack was developed). So, CLI is used instead of programmatic usage in the electron-webpack.

    Now HMR works. And even more — there is a simple way to add HMR support for main process (mostly done on electron-webpack configuration side, but not documented/tested/helper script not provided).

  2. Way "select option during project creation" is not flexible, because what if I want to add some feature later? For what we need to complicate things, if we simply can provide some preset and detect it? Or just detect loaders (check project dependencies and devDependencies) and automatically apply corresponding configuration.

    So, two presets is implemented: electron-webpack-ts and electron-webpack-vue. These presets are nothing more than just list of dependencies (so, user don't need to list all required, because, for example, for vue we need to add 4 dependencies). electron-webpack can work without these presets, i.e. ts-loader can be installed explicitly and it will be detected.

    For example, vue support is automatically configured if vue in the project dependency.

  3. Webpack is amazing. Multiple async configs are supported. No need to reinvent the wheel. Do you want to compile the whole app — that's easy, just pass special configuration file: webpack --env.production --progress --bail --config node_modules/electron-webpack/webpack.app.config.js

    Here webpack.app.config.js is just a collection of renderer and main configs. No special script — all power of webpack in your hands and you are not limited. No boundaries are set by electron-webpack and you can use provided configuration files in a various scenarios (e.g. do not use yarn dev script, but run separately for better IDE support).

    And if user want, parallel-webpack can be also used. Maybe later we will provide special compile script but I doubt. electron-builder will support webpack configs soon and it will work better than any user solution / not electron-builder solution, because in-memory compilation will be used.

What do I suggest: change this boilerplate to use electron-webpack.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions