需求：打包加密 / Support for source code protection

[joyexpr]

Clear and concise description of the problem

目前貌似只支持正常的asar打包，有没有考虑过提供打包加密的能力？如混淆、字节码，对企业应用比较刚需。

类似：https://www.yuque.com/u34495/mivcfg/mmr6mu

Suggested solution

参考：

https://github.com/wallace5303/ee-core

Alternative

No response

Additional context

No response

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.

[alex8088]

in plan

[alex8088]

Source code protection feature is available since electron-vite 1.0.9. 🎉🎉🎉

Check out the documentation to learn more.

Also, you can learn more by playing with the example.

[joyexpr]

awesome! 明天试下。

看了下文档，有个疑问，文档中提到修复了异步箭头函数可能导致 Electron 应用程序崩溃的问题，这个跟transformArrowFunctions参数（默认为false）有什么关系？

另外单纯讨论 transformArrowFunctions 这个参数的话，是否将箭头函数转换为普通函数对于打完的包有什么意义和影响吗，也不是用来看的代码？

[alex8088]

默认是不转换箭头函数，由用户自己决定是否转换，箭头函数不一定就会引发electron异常，如果函数处理好逻辑，不转换也是可以的，你可以通过example示例学习一下，就可以理解了

[joyexpr]

好的，看了下例子，大概了解了。明天再测试并细了解下。

不过从用户的角度上，因为打完包，用户不会关心制品的可读性，更期望打出来的包的行为跟开发测试的一致，所以我原以为transformArrowFunctions 这个参数默认值为true可能更合适些。如果用户有明确了解后果和风险，希望提高一点打包速度，可以选择关闭箭头函数转换。个人想法哦。

[joyexpr]

刚跑了下例子，发现即使对可能抛出Error的方法进行try catch，也不能避免加密打完的包崩溃（未开启箭头函数转换情况下），所以还是建议默认开启transformArrowFunctions 并在文档中补充和（修复了异步箭头函数可能导致 Electron 应用程序崩溃）的关系

以下是一段可能的代码示例，不一定是最佳写法，但也不能说写得不对，这种情况打包后崩溃就比较不好了：

[alex8088]

@joyexpr 确实是，你的建议合理，后面优化。

[joyexpr]

hi，我们来解决另一个写死密钥字符串加密的问题吧。首先，这个需求肯定是存在的，比如对本地存储的加密密钥，如electron-store的encryptionKey参数。

目前我们是使用gnirts库先手动将密钥字符串混淆，生成一个自执行函数，然后将源代码里的密钥字符串替换成上述自执行函数

希望 electron-vite的bytecodePlugin 可以自动化这个步骤，插件增加参数：是否混淆字符串以及要混淆的字符串数组，打包时扫描到对应字符串（或者可以提供一个标识性的方法或标志，防止有些密钥因为历史等原因建得太简单或普通但又不方便改）即进行上步的替换，替换完后再进行后续的编译字节码

您觉得呢？

[alex8088]

hi，我们来解决另一个写死密钥字符串加密的问题吧。首先，这个需求肯定是存在的，比如对本地存储的加密密钥，如electron-store的encryptionKey参数。

目前我们是使用gnirts库先手动将密钥字符串混淆，生成一个自执行函数，然后将源代码里的密钥字符串替换成上述自执行函数

希望 electron-vite的bytecodePlugin 可以自动化这个步骤，插件增加参数：是否混淆字符串以及要混淆的字符串数组，打包时扫描到对应字符串（或者可以提供一个标识性的方法或标志，防止有些密钥因为历史等原因建得太简单或普通但又不方便改）即进行上步的替换，替换完后再进行后续的编译字节码

您觉得呢？

看起来是不错的想法，gnirts库也有意思，将字符串变成函数，可以试着实现。

@joyexpr you are very professional and smart :handshake:

[alex8088]

@joyexpr 有没有类似其他的库

[joyexpr]

@joyexpr 有没有类似其他的库

javascript-obfuscator 这个库貌似也有类似功能，不过功能有点多和复杂，没细研究过

不过我们插件的这个字符串混淆功能其实也可以随着版本升级进行算法更新优化，反正也不会影响终端用户的使用，甚至也可以同时支持多种算法，设计一个参数让用户选择

[kekekezi]

那个 renderer怎么加密呢 @joyexpr

[joyexpr]

那个 renderer怎么加密呢 @joyexpr

可能只能混淆吧

@alex8088 目前electron-vite模板没有对打包代码进行混淆，我尝试使用rollup-plugin-obfuscator对renderer代码进行打包混淆，在electron.vite.config.ts中添加了renderer的plugin，但build 时提示obfuscator不是一个function（实际是），有点像electron-vite的bug，能否帮忙看下

[alex8088]

@joyexpr 我看看

[kekekezi]

@joyexpr https://zhuanlan.zhihu.com/p/538772737 我试了一下这个 但是代码没有压缩 不知道是不是配置有问题

[alex8088]

@joyexpr 插件自身导出问题，在vite下使用也是会报这个错误, 它的导出形式很特别，自己写吧，就几行代码而已

严谨的，也不能说它有问题，只是electron-vite和vite一样都采用动态导入获取配置信息，不支持它的导出方式。

[joyexpr]

@joyexpr 插件自身导出问题，在vite下使用也是会报这个错误, 它的导出形式很特别，自己写吧，就几行代码而已

严谨的，也不能说它有问题，只是electron-vite和vite一样都采用动态导入获取配置信息，不支持它的导出方式。

恩，插件源码改了一行import写法就可以了。不过这个obfuscator不是太好用，fileOptions（即transform）不能开，renderChunk 的打包产出也不稳定

[redisviewer]

@joyexpr 插件自身导出问题，在vite下使用也是会报这个错误, 它的导出形式很特别，自己写吧，就几行代码而已 严谨的，也不能说它有问题，只是electron-vite和vite一样都采用动态导入获取配置信息，不支持它的导出方式。

恩，插件源码改了一行import写法就可以了。不过这个obfuscator不是太好用，fileOptions（即transform）不能开，renderChunk 的打包产出也不稳定

求指导electron-vite如何混淆渲染进程源码~~~ 这边测试不成功