前言
- 技术预演第一步很重要，开始错了后面可能都是白费力气
起因
- 打包优化是我之前一直想解决的一个问题，修改webpack源码也是增加缓存和多线程这两个方式juejin.im/post/5def81…
- 前段时间的esbuild使我眼前一亮，提供了一些新的思路，是不是二进制的文件执行效率比nodejs快？
- 使用golang这样编译型是不是会是提升脚本语言执行效率的一种途径，例如用python和node.js写的脚本开发过程比较简单，开发速度很快（相对于一个Java项目）,但是这些脚本同样的一个问题就是执行效率低也是解释型语言通病之一。开发语言没有优劣之分只是区分不同的应用场景，最快的执行效率，不代表最快的开发效率，最快的开发效率也不代表有最好的生态社区稳定性等等。
- 小结如果用c开发打包脚本是不是更快呢哈哈？
开始
- nodejs有个pkg的打包工具可以将nodejs打包成二进制文件（其实是一种环境模拟的机制）
- 第一步写个测试两万个文件的读写，用nodejs跑和nodejs打包错了的exe跑（我就错在这一步，当时可能比较兴奋）
- 第二步用pak打包一个webpack4只要注释掉两行代码就可以正确执行了
- 第三步改进脚手架把angular-cli 本地化打包成exe
- 执行构建命令
- 结果是能打包出来，然后效率并没有提升
注意事项
pkg打包过程中本地路径引用的问题一定要注意（例如__dirname是在执行二进制的文件目录下面而不是真正执行的工作目录下面）
| |
||
| value | with node | packaged | comments |
| __filename | /project/app.js | /snapshot/project/app.js | |
| __dirname | /project | /snapshot/project | |
| process.cwd() | /project | /deploy | suppose the app is called ... |
| process.execPath | /usr/bin/nodejs | /deploy/app-x64 | app-x64 and run in /deploy |
| process.argv0 | /usr/bin/nodejs | /deploy/app-x64 | |
| process.argv1 | /project/app.js | /snapshot/project/app.js | |
| process.pkg.entrypoint | undefined | /snapshot/project/app.js | |
| process.pkg.defaultEntrypoint | undefined | /snapshot/project/app.js | |
| require.main.filename | /project/app.js | /snapshot/project/app.js |
- 由于前面资源路径引用的问题所以可能需要把某些脚本资源加载到二进制中
"pkg": { "scripts": "build/**/*.js", "assets": "views/**/*" }- 技术预演时应该更谨慎一点
收获
- 以后自己写node小工具不需要再依赖本机的node环境了直接使用安装包也是可以的
