交流讨论贴

[wxhccc]

本帖仅供大家讨论，包括存在的疑虑或其他的建议。

看说明里在vite里使用node模块，不知道是指的在渲染进程里使用node模块么？electron已经不建议这种方式了，而且通过preload透漏的api也应该尽可能少，过大的preload文件也会影响页面打开速度。

[467057463]

抱歉，现在才看到 issuse。原本计划是在渲染进程中使用 node 模块，首次依赖通过 hack 解决了，但依赖的依赖中使用了node 或者 commonjs 模块则不能编译，后翻查 vite 源码发现有意在前端项目中剔除了node模块，抱歉也因为这个原因不建议使用本项目进行任何开发。
另外关于在渲染进程中使用 node ，个人觉得这样的写法比推荐的 contentBridge 更爽，所以就想不接受这个安全建议，另外新的 electron 了解得不多，也许有了更多的了解会改变现在的看法。
另，由于前期调研不足匆匆上了本项目，给大家带来的困扰，在这里统一道歉。

[wxhccc]

抱歉，现在才看到 issuse。原本计划是在渲染进程中使用 node 模块，首次依赖通过 hack 解决了，但依赖的依赖中使用了node 或者 commonjs 模块则不能编译，后翻查 vite 源码发现有意在前端项目中剔除了node模块，抱歉也因为这个原因不建议使用本项目进行任何开发。 另外关于在渲染进程中使用 node ，个人觉得这样的写法比推荐的 contentBridge 更爽，所以就想不接受这个安全建议，另外新的 electron 了解得不多，也许有了更多的了解会改变现在的看法。 另，由于前期调研不足匆匆上了本项目，给大家带来的困扰，在这里统一道歉。

没事，交流讨论，本插件的工作模式挺好的，合理利用vite的插件机制可以减少electron的使用成本，我现在使用的一个第三方工具只提供了开发阶段的集成，打包需要自己使用electron-builder处理，因为个人项目写的慢，还没有加打包逻辑。
实际项目经验，开始时直接在渲染进程用node，后来有些包升级后会导致node模块相关的报错，然后改成preload里统一提供nodejs的api，这样不报错，但是打包后的文件越来越大，首页打开速度明显变慢。同时electron后续几个版本一直强调安全方面的问题，最后干脆按照安全指南推荐的方式写。
虽然明显变麻烦了，但也换来了一些优势，preload打包后只有几十行，就提供了ipc透传的功能（同时提供支持的函数的ts定义），首次开启时间也变快了。另外交互形式也分离了，页面可以在浏览器打开（没有数据源也没发正常用），如果必要时换成websocket作为通信通道，页面只需要极少量得修改。