Commit Graph
2 Commits
Author SHA1 Message Date
what efb3141734 feat(esm): Vendor 把装好的 npm 包连同依赖摊平成单文件
解决的是「脚本要用第三方库,但目标机器上没有 node」。

npm 真正干的活是解析依赖树——读 semver 范围、查注册表定版本、递归、处理冲突。
这步绕不开,得在有 node 的机器上做一次。但做完之后依赖树就是死数据了,用
esbuild 摊平成一个文件,发布物里只带那一个就够:

    qs         v6.16.0   打进  47 个文件 -> 73.6 KB   (原 19 个包 1.7 MB)
    es-toolkit v1.52.0   打进 219 个文件 -> 51.9 KB

产物是最小的 node_modules 布局,脚本照常 import,写法完全不变。

两个实现细节:

  - 入口不能直接写包名,esbuild 的 EntryPoints 是文件路径。所以造一段转发
    源码当 stdin 入口,包名放进 import,才走正常的 node_modules 解析。
  - 转发源码里写 export { default } 时,只有具名导出的包会报错(ESM 原生的
    很多是这样),退回去用只带具名导出的版本重打一次。

打包目标从 Loader 里提成了共用常量:摊平出来的库必须跟脚本同一档,
否则库能打出脚本引擎跑不了的语法。

零依赖的包不用这个——直接下 tarball 解开就行,README 里记了命令。
2026-09-07 09:54:18 +08:00
what c2ce37ad2d docs: README 与执行流程、生命周期两篇
README 分四段:脚本怎么写、Go 侧怎么调、安全边界与可靠性、性能。
docs/call-flow.md 讲源码怎么变成可执行的、一次调用经过哪些环节;
docs/lifecycle.md 讲 Engine / Script / VM / Instance / 作用域各活多久。

性能一节的每一行都标了对应的基准名,数字过时了可以自己重跑。原来有一张
「循环里访问 Go 对象」的表没有对应的基准测试,数字无法复现,换成了
Benchmark绑定_* 的实测结果。内存那张表仍是手工测的,已在旁边注明。

挑第三方库那节记了两条实测结论:esbuild 的 target 只降级语法、不补全局
对象,所以库只要用了 structuredClone 或定时器就是运行期才炸;CommonJS
包摇不动,同一组功能 lodash 打出 419 KB 而 es-toolkit 只要 7 KB。
2026-09-05 22:13:57 +08:00