王森的博客

在实际开发中，我发现团队对于这几个路径的设置上是纯靠猜的，通过一点点地尝试来找到可行的路径，这是不应该的，我们应该很清晰地了解这几个概念，以下通过截图和代码进行细节讲解。

在尝试让 ChatGPT 自动开发一个桌面壁纸更改的功能时，发现引入了一个 wallpaper 库，这个库的入口文件是 index.js，但是 package.json 文件下的 type:"module"，这样造成了无论你使用 import from 还是 require，都会报 ES Module 引入错误，针对于这个问题，让 GPT 给了很多方案，但是都没有解决实质问题，最终，经过多次测试，发现必须借助打包工具 webpack 才能搞定这个事情。

很多人应该都不会electron主进程调试，electron-vue 框架给了一种node调试的一种方法，这里记录下来，对很多人应该都有用，另外，对于webstorm对electron的支持，这里也记录一下，方便大家提高开发效率

最早有 Babel polyfill 的概念是接触 ES6 语法时，大概是 2016 年，被 polyfill 坑的时候是 2021 年开发谷歌插件时，经过 webpack 打包的代码中，我竟然看到有东西在重写 Promise，导致了原生的 Promise 不可用，后来我就开始对 Polyfill 进行了解，本文主要还是想彻底搞明白 Babel 怎么针对不同版本下的 ES 高级语法的支持和转化问题，怎么让自己的代码尽可能地少被 Babel 转化，从而利用浏览器原生 API 来提高代码运行速度，以及缩短打包时

在学习 Chromium 源码时发现，Electron 就相当于在 Chromium 源码的基础之上，又追加了 Node.js 的运行环境，并且使得 Node.js 和 Chromium 网页环境可以互相通信，互相取用各自的 API，形成了一个新的浏览器应用，也即 Electron 是 Chromium 浏览器的一个超集，而且 Electron 和 Chrome 内核的对应关系可能更为复杂，并不是很轻易就替换新的 Chromium 内核打造出来新的 Electron 衍生版本的。那是肯定可以执行的。

探索浏览器参数开发时，发现第一步 Chromium 源码编译这块就坑点很多，这里统一记录下，以便未来碰到类似的 Visual Studio 编译时，会遇到同样的问题。遇到问题的关键点，主要还是对于 VS IDE 的不熟练，以及对 C++相关知识的欠缺导致。基于 B 站 Up 主的这个 Chromium 源码编译视频合集进行整理。

结尾遗留的 Webpack 升级到 5 的问题继续开展，在独立构建 Webpack5+Vue2 脚手架成功的前提下，理论上 Electron-Vue 升级到 Webpack5 不应该有任何问题，本文重新整理思路，以肯定可以升级成功的结论前提下，继续探索问题所在，同时打算在解决问题后，重新整理 Webpack 批量构建过程。

很多前端同学总是模糊地知道这就是个打包的工具，再深了就不知道它到底怎么打包的，这里简要说下它是怎么打包的。要从 js 模块化说起，什么叫模块化？模块化的意思就是我们如果要想让代码具有可维护性，而不是将全部代码都塞在一个文件里一次性读入内存，那么我们就必须搞一种动态/静态引入的机制，静态引入顾名思义，就是将代码分门别类放在不同的文件夹下下面，在最后打包的时候，通过运行打包脚本，将原来不同文件目录的代码都追加在一个文件里面，这种叫静态引入。

这种新式 ES 语法不支持打包，如若支持的话，又发现新版的 babel 插件又依赖于 babel7，导致出现 babel 版本冲突，最后的解决方案，则是全面升级 babel 至 babel7，并且适配好 webpack4（目前 electron-vue 框架正在用的），现将整个升级过程记录，同时也完善下.babelrc 配置文件在代码中如何生效的。这些东西虽然不需要记忆，但是的确在以后的打包过程中动态地处理一些东西时非常有用，包括引用路径，引用的资源，甚至定义的不同变量都是能用到的。

因为 wadesk 开发了本地 http 服务，http 本地服务是运行在 electron-main 的纯 node 环境中的，这个之前探讨了 node 下怎么使用 fetch 时就提到了一个 https-proxy-agent 库，这次使用 axios，发现 axios 自带 proxy 配置项，就没有多想，造成了 4 个小时的时间浪费，此次排查应该作为一个反思例子对待。

背景electron 主渲进程的打包，以及 preload 的打包，还有注入脚本的打包，这些东西 webpack 本身是自带的，这里主要讲一下 target: node 模式

electron-vue npm run build 打包超级慢的原因不是最终electron-builder环节的问题，而是webpack打包渲染进程的问题，今天经过与ChatGPT一起优化，终于把速度降了大概5倍左右，直接让文件打包速度快了很多。

因为组员对于 Electron 打包过程存在比较迷糊的状态，且自己也没主动探索 Electron-vue 打包细节，导致每次打包过程都消耗 5-6 分钟的时间，在需要测试生产打包时，极其浪费时间，为此针对 Electron-vue 打包的几个环节进行拆解，来减少打包时间，提高开发效率。

在开发 Electron 过程中，我们想知道 Electron 打包的最终形态是什么样的，以便我们能更好的理解 Electron 打包的过程，以及逆向来快速追踪一些问题，例如下面这个报错，以前这类报错都是靠猜，现在则可以快速定位，找到源码问题发生点

目前谷歌扩展有 50W 之多，覆盖面比较广，而 Electron 又是基于谷歌浏览器内核开发的，如果将两者结合，那么就能大大节省很多开发时间，开发出来的客户端功能却更加丰富，不过 Electron 并没有完美支持谷歌扩展，尤其是谷歌扩展 MV3 版本中提供的大量的 API，Electron 本身都是不支持的，这就给开发者一种误导，Electron 不支持 MV3 的扩展。

自从2022年底chatgpt上线后，sse就进入了大众的视野，之前是谁知道这玩意是什么？但是打字机的效果看起来是真的很不错，一度吸引了很多人的趋之若鹜，当然了这个东西的确挺好用，而且实现很简单，之前我用python的demo讲了一下SSE的概念，看起来有很多人看，但是并没有说明白这个原理，这次再彻底把这个原理给说明白，而且我发现通过node.js 的Express框架来说明这个概念更加简洁，所以今天就用Express框架来说明SSE概念，这样对前端同学更加友好。

经过通信层面的优化后，我们不再走 Electron 提供的内置进程间通信 IPC，改为利用 Express 提供的 Http 本地服务来进行多处直达通信机制，同时利用本地 Sqlite 来保存大量数据，但 Express 提供的本地服务是支持并发请求的，而 Sqlite 是不支持行锁的机制，一旦有写入操作，Sqlite 都是直接锁库，除了采用单表单库减少锁库问题外，另外就是走队列的方式来逐个入库，避免写锁问题。

这个东西可能是我十几年前最开始接触的东西，第一次web开始，就是要做登录注册的功能，当时就涉及到cookie和session，用的还是Java，Java 来做Web本身就够晦涩难懂的了，跟更古老的C做Web开发差不了多少（已C语言的方式做了一个Html的字符串输出的模板引擎），即使现在有了SB好了很多， 但也高度封装了底层代码，甚至好多现在Java开发连servlet是啥东西都不知道了。这篇文章是写给新人的，当然很多老开发者看似懂了，其实也只不过是唯手熟尔，对于底层到底发生了什么，自己能否手敲实现相关的

之前写了一篇Electron通信的方式，讲述了一下三者之间的通信机制，比较恶心，后来发现有个@electron/remote，可以让渲染进程直接访问主进程，但遗憾的是，preload.js无法使用这个库，webview更是不可能直接触达主进程，总要通过preload.js绕一圈才能找到渲染进程。为此，我们需要一个新的方式，来解决所有通信链路的问题。

remote是个老库，早期Electron版本中有个remote对象，这个对象可以横跨所有进程，随意通信，后来官方认为不安全，被干掉了，之后有人利用Electron的IPC通信，底层通过Promise的await能力，模拟了一个类似的remote对象，即@electron/remote没有当年的remote那么强大，但是也很好用，当然，若觉得自己生命值较长，可以不屑一顾，自己再造轮子。

在调研浏览器多开的过程中，electron 有自带的 browserview，webview，但是上面两个受制于 electron 内核版本限制，升级不够灵活，对新版的网页支持可能不及时，甚至不兼容，必须通过发布新的客户端版本才能解决，此外，这两个组件本身也不稳定，经常内存溢出，如果能改为 chrome 自己开发的浏览器内核来运行，则以上问题解决起来都不会特别吃力，所以才有了对 Electorn 控制浏览器多开的技术调研。下载好之后，找到路径，在地址栏输入 cmd，按回车，即可打开控制台。

​写客户端多分身本地数据交替升级解决方案 - 绝对干货全网难找-CSDN博客发现需要不同的代码库依赖同一个github升级库，这样就能保证主线版本的升级，大家都在一个分支上，并且也方便查看升级代码，比较升级代码，也方便主线代码的升级过程，非常Nice，为此，这里特意进行一个Demo实现。

开发客户端时，为了应对不同客户的不同需求，大杂烩的客户端往往使得代码非常凌乱，补丁代码越堆越多，但是这并不能让产品的付费转化提高，每个用户都有自己的需求偏重，同时也更在意自己的需求的体验和稳定性，不断地增加更多功能，会使得系统过于庞大，同时还降低了系统的稳定，互相影响是难免的。但如果抽离不同功能形成新的版本，就会出现分裂，渐渐地就会出现底层数据结构的分裂，一旦分开就有走得快的，走得慢的，慢的和快的就会产生结构的不同，为了应对这种结构的自然变化，以及使用者的不可控（对方可能一直用着旧版本），这就造成了版本

程序员编码的最大问题是受制于最初c++面向过程的思维引导，导致后续所有的代码里面，if...elseif...非常多，同时想要让自己的一串代码尽可能处理更多可能的场景，此外，还想将公共逻辑抽出，我们最喜欢做的事情就是，先设置几个变量，然后不断地分析逻辑，不断地追加变量的值

开发过程中，有些时候，要访问公司内网服务器，提供的一些服务啥的，但是问题的关键是用户使用的网络各不相同，所以就要动态地使用系统代理来访问，但是主进程默认为控制台级别的请求，不走系统网络，除非你代码中指定走系统代理，这个就有了这篇内容

Franz是Electron开发中一个比较深度的开源代码，但因含有大量的基础知识，导致早期我没有花费时间来倒腾这个，这次采用按图索骥地方式，借助AI的提示，一点点地将启动过程搞出来，这估计是官方故意搞得一个坑，大概意思时 ，连运行起来的本事都没有，就别看代码了，看也白看！

electron 这东西文档乱七八糟，版本迭代飞快，里面技术还多得不得了，但强大是真的强大，好用是真的好用，头疼是真的头疼，搞不好就内存泄漏了，问题多多，踩坑多多，后期我把代码整理号了，发到gitee上，再追加上来。npm可以设置代理，如果不会的，请自行搜索，这里就细讲了，有时候代理也不行就需要，在控制台，设置环境，不加这个，也能让你下载安装包下到怀疑人生，实在搞不了安装包问题的，可以私信我发node-modules。还有个热更新报错，这个去年已经讲了，这里就不再赘述，改了即可。