electron-vite
electron-vite copied to clipboard
alex8088
主进程不支持热更新么？
Describe the bug
主进程不支持热更新么？支持的话应该如何配置呢？
Electron-Vite Version
1.0.2
Electron Version
17.3.1
Vite Version
2.9.1
Validations
- [X] Follow the Code of Conduct.
- [X] Read the Contributing Guidelines.
- [X] Read the docs.
- [X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
electron主进程的热更新实际为node模块更替，也有一些关于node的热更新方案，但实际应用很少也不成熟。在electron中也有一些社区模块通过检测并重启electron进程方式达到目的，但这不是热更新的概念，这种方式并不友好，不是很好的开发实践。electron-vite 渲染进程的热更新是基于vite下browser环境， electron-vite 没有关于主进程的热更新实现。
electron主进程的热更新实际为节点模块，有一些社区节点的热更新，实际应用很少通过也成熟。在electron中检测模块的启动进程中，目的也有但也不是一些替代热更新的概念，这种方式不太友好，不是很好的开发实践。electron-vite 渲染进程的热更新是基于下浏览器环境，electron-vite 关于主进程的热更新没有实现。
如果这样的话，那也就是说所有的业务逻辑都写到了渲染进程么？
electron主进程的热更新实际为节点模块，有一些社区节点的热更新，实际应用很少通过也成熟。在electron中检测模块的启动进程中，目的也有但也不是一些替代热更新的概念，这种方式不太友好，不是很好的开发实践。electron-vite 渲染进程的热更新是基于下浏览器环境，electron-vite 关于主进程的热更新没有实现。
如果这样的话，那也就是说所有的业务逻辑都写到了渲染进程么？
我是不建议将业务逻辑组织在渲染进程中，但也有人是这么做。我的建议是：主进程提供服务（如http api，native api 等等），渲染进程组织UI界面，渲染进程通过preload 来调用主进程提供的服务实现界面展示处理
那基于现在的场景，那我在main里面写的代码，岂不是每一次都需要 关掉进程 重新启动么？
electron主进程的热更新实际为节点模块，有一些社区节点的热更新，实际应用很少通过也成熟。在electron中检测模块的启动进程中，目的也有但也不是一些替代热更新的概念，这种方式不太友好，不是很好的开发实践。electron-vite 渲染进程的热更新是基于下浏览器环境，electron-vite 关于主进程的热更新没有实现。
如果这样的话，那也就是说所有的业务逻辑都写到了渲染进程么？
我是不建议将业务逻辑组织在渲染进程中，但也有人是这么做。我的建议是：主进程提供服务（如http api，native api 等等），渲染进程组织UI界面，渲染进程通过preload 来调用主进程提供的服务实现界面展示处理
那基于现在的场景，那我在main里面写的代码，岂不是每一次都需要 关掉进程 重新启动么？
那基于现在的场景，那我在main里面写的代码，岂不是每一次都需要 关掉进程 重新启动么？
electron主进程的热更新实际为节点模块，有一些社区节点的热更新，实际应用很少通过也成熟。在electron中检测模块的启动进程中，目的也有但也不是一些替代热更新的概念，这种方式不太友好，不是很好的开发实践。electron-vite 渲染进程的热更新是基于下浏览器环境，electron-vite 关于主进程的热更新没有实现。
如果这样的话，那也就是说所有的业务逻辑都写到了渲染进程么？
我是不建议将业务逻辑组织在渲染进程中，但也有人是这么做。我的建议是：主进程提供服务（如http api，native api 等等），渲染进程组织UI界面，渲染进程通过preload 来调用主进程提供的服务实现界面展示处理
那基于现在的场景，那我在main里面写的代码，岂不是每一次都需要 关掉进程 重新启动么？
是的，主进程和preload脚本变动是需要重启electron进程的，此外需要知道electron目前不支持esm，实际还是需要重新编译，重新编译重启是需要的，而渲染进程之所以可以热更新，在于Chrome browser环境支持esm。
那基于现在的场景，那我在main里面写的代码，岂不是每一次都需要 关掉进程 重新启动么？
electron主进程的热更新实际为节点模块，有一些社区节点的热更新，实际应用很少通过也成熟。在electron中检测模块的启动进程中，目的也有但也不是一些替代热更新的概念，这种方式不太友好，不是很好的开发实践。electron-vite 渲染进程的热更新是基于下浏览器环境，electron-vite 关于主进程的热更新没有实现。
如果这样的话，那也就是说所有的业务逻辑都写到了渲染进程么？
我是不建议将业务逻辑组织在渲染进程中，但也有人是这么做。我的建议是：主进程提供服务（如http api，native api 等等），渲染进程组织UI界面，渲染进程通过preload 来调用主进程提供的服务实现界面展示处理
那基于现在的场景，那我在main里面写的代码，岂不是每一次都需要 关掉进程 重新启动么？
是的，主进程和preload脚本变动是需要重启electron进程的，此外需要知道electron目前不支持esm，实际还是需要重新编译，重新编译重启是需要的，而渲染进程之所以可以热更新，在于Chrome browser环境支持esm。
那有没有这样的插件，比如我在main/index.ts 更改一行代码后，能够自动重启项目，这也是我能接受的。
同准备提这个需求，目前发现下面这个模板是支持主进程和渲染进程热更新，希望electron-vite也能支持
https://github.com/electron-vite/electron-vite-vue
@joyexpr 正在在考虑设计这一需求，说说我的顾虑和想法
通过监视重启进程的实现并不难。但在我长期的实践中，诸如一个不小心保存就重启，实际代码并没有写完整。这种反复过程和不可选择性，给我带来困扰。所以，我会认为这是一个不好的开发调试体验。我也尝试过node模块化重载的方式而非重启进程的方式，但不是很靠谱。重启进程好像是唯一可行的。
后续实现可能会导出plugin供开发者选择配置，和一些CLI命令辅助。 但我还在想如何增加可选择性，让开发者决定重启的的时机，或者一些询问机制，这些涉及一些IDE的东西。总之，也是希望给大家带来更好的开发体验，更智能一些。
此外，我也想知道一些社区开发者的开发实践情况，或者给与一些意见和想法。
理解，实际开发中，我觉得我肯定也需要根据开发的具体功能的实际情况来选择当前是否开启主进程（main、preload）热更新（重启进程），这个开关是需要的
我觉得可以先解决功能有无的问题，让用户自己选择是否开启，后续再尝试更智能化的优化
建议的开关方式，除了electron.vite.config.ts配置文件这个方式外，是否也可以考虑使用环境变量，这样我可以建2个run配置，根据需要选择跑哪个
@chenzhihang950909 @joyexpr
新版本1.0.8已支持热重载
有两种启用方式：
- 使用 CLI 选项
-w或--watch，例如electron-vite dev --watch。这是首选方式，它更加灵活。 - 使用配置项
build.watch并设为{}。此外，还可以配置更多的 watcher 选项，见 WatcherOptions。
详细见： https://cn-evite.netlify.app/guide/hot-reloading.html