之前做的 NPM 都是命令工具类的,从没发过组件类的。最近正好用到之前写过的某个功能,于是把几年前写的一个库翻新了下,做成 NPM 包分享。
组件很简单,就是从一个字节流( stream )中读取固定格式的数据,如 uint32 、uint16 、text 等等。网上有不少这种库。不过之前想到一个巧妙的方案,性能可以大幅高,于是自己写了一个。由于懒得写文档,一直没发布。最近重构了遍,准备分享下。
库名原本叫 FastReader ,测试和演示中都用了这名字,而且包名至今都未注册。没想到发布时才发现这个名字不能用,原来已经有个 fast-reader 的包(看起来早已不维护)。NPM 现在为了安全性,连相似的名字都不让用了。。。提示可以用 @username/package 的格式,但觉得太长不美观。打算改成 QuickReader ,但索性用更短的名字算了,SReader ( Stream Reader )。
之前想到的巧妙的方案,是这个项目的亮点,就是用一种特殊的语法减少 await 的调用量 —— 不涉及 I/O 时纯同步执行,只有必须时才执行 await ,从而提高性能。类似这样:
const result = reader.bytes(10) ?? await A
因为当时原生支持 await 没多久,出于兼容性很多时候是用翻译后的语法糖实现 await 的,因此开销较大。当然现在的性能已大幅提高了。不过比同步逻辑还是慢百倍左右( Chrome 开着控制台会慢几千倍,可能和调试器有关),测试细节可参考 github 。
组件原本同时支持 ESM 和 CJS ,但考虑 ESM 已是主流,而且很多开源库现在只支持 ESM ,于是把 CJS 兼容部分去了。不知就目前是否合理。
另外写 jest 测试时也踩了不少坑。jest 目前对 esm 的支持还是实验性的,甚至还需加 node 启动参数。加上测试本身用 ts 编写,还需配置 ts-jest 参数,折腾很久(主要卡在 node-fetch 组件,定义总是报错)。最后虽然可以,但 ci 测试时较低版本的 node 仍报语法错误。于是测试案例最终仍未用 esm 。
当然最头疼的就是写文档,由于平时几乎不写英语文档,快退化到初中水平了,干脆用谷歌翻译。感觉难以短时间恢复了。。。
希望有更好的建议!
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.