王森的博客

Webpack 打包后的代码是不会直接暴露 __webpack_require__ 函数，目的是为了避免污染全局变量同时也为了保护 webpack 的打包后的模块都隐藏在闭包函数里，达到数据的安全性。而有时我们为了测试某个函数，想直接获取这个内置函数，同时保证这个内置函数能使用其所带的上下文，若单独构建这个函数，创建上下文，难度非常之大，因为这个函数的上下文都在闭包函数里。而__webpack_require__.m 则可以提取所有的模块，所以拿到 __webpack_require__ 是关键。

Terser（简要的/简短的） 混淆依据混淆是发生在代码已经 bundle 之后的事情变量或者函数在被引用或赋值时才能被混淆孤立的函数或者变量可能会被移除，但不会被混淆，要通过显式地引用

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

在尝试让 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 衍生版本的。那是肯定可以执行的。

因为注入脚本是一整套塞进去的，字体，css，html 都应该打包在一个 js 里面，以 base64 方式注入，其中 dataUrlCondition 这个配置非常棒，只要将 maxSize 设置得足够大，就可以将字体文件也打包到 js 文件里面去，这样就特别方便 DOM 的注入和挂载。因为我们设定了 babel 的兼容 ES12，所以下面这些转化基本都用不到，因为 Chrome 能支持，所以也不需要这些插件，你可以直接用最新的语法，如?批量移除它们，proposal 这些都已经被作为正式版包使用了。

探索浏览器参数开发时，发现第一步 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 配置文件在代码中如何生效的。这些东西虽然不需要记忆，但是的确在以后的打包过程中动态地处理一些东西时非常有用，包括引用路径，引用的资源，甚至定义的不同变量都是能用到的。

Rebase 冲突：发生在每个提交应用到目标分支的过程中，冲突粒度较小但可能多次出现。Merge 冲突：发生在两个分支合并的整体过程中，冲突粒度较大但只出现一次。两者的冲突处理并没有本质的优劣，关键是根据场景选择合适的合并策略：选择 Rebase：当需要整理历史、保持线性记录时。选择 Merge：当需要保留分支结构、避免篡改历史时。

因为 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 的扩展。

virtualbox 安装 win7 系统坑点汇总