wepack 之 dependency tree
最近状态特别不好，工作上做了一个短期不会产生收益的项目，加上最近老被质疑，有点怀疑人生了……
其实，我在公司里，写的是一个叫 wepack 的轮子，就是将微信小程序，一键打包成 spa
说来轻巧，市面上也有一些竞品，比如 taro，但……
我最初的冥思雏形，是很美好的
case => 数据结构
如题，如果只是编译一些文件，然后 casebycase 的修改 ast，那么这个轮子就会很愚蠢，事实上，taro 也吃了这个大亏，taro3 也完全放弃了编译路线
但是如果我们能找到一个数据结构，去抽象，概括业务 case，如果真的可以找到，我们将彻底摆脱 casebycase 的处境
实际上，几乎所有的轮子都是这么做的
比如 webapck 的dependency graph，rollup 的 module graph
，parcel 的bundle tree
所有的打包工具，套路都是一样的，说白了就是构建一张图（或树），如果一个不够，那就构建两个
也就是说，wepack 作为微信打包器，它理应非常非常简单地，只做一件事
那就是我也构造一棵树
漫漫建树路
于是，我就开始做梦冥思，这颗树，长啥样，然后写了很多个版本代码
因为微信小程序是个多页面应用，我一开始企图将每个 page 构建一颗小树，然后最终再用微前端的 server 跑起来
事实上这个思路完全可行，我马上就写了一个很 ok 的 demo 并封装了组件和 api
但和我想象中的 一树走天下
差太远了
所以我开始想办法大重构，我一定要用一棵树彻底概括整个小程序多页
Asset {
type: root
path: 'E:\\wepack\demo\app.json',
siblings: Map[ Asset, Asset, Asset ]，
parent: Asset
dependences: Map[ Asset ],
isComponent: false,
generator: ()=>{},
parser:()=>{}
}
抄袭 parcel，将每个文件都抽象为 asset，每个 asset 都对应自己的 parser 和 generator，还包含了这个 asset 的基本信息
碰到循环依赖，则依赖应该上移到他们共同的父亲中
像 rollup 这种只需要处理 js 的轮子，它可能就只有一个 js 的事，parcel 和 rollup 更进一步，除了 js 还有 css 等，单位变成了 asset
小程序比较坑的是，它的单位不只是 asset，它其实是这样的
[ App ] [ Page Page ] [ Component Compnent Component ] [ Asset Asset Asset Asset ]
别提有多坑爹了，真特么鬼才，所以
我。不。同。意。
我希望将它们全部高度抽象为 asset，但这也是卡我最久的地方没有之一，我还在冥思中
小程序标准
今天 w3c 的一个公告，大致上说的是百度，阿里的程序员联合搞了一个小程序标准
说实话打心底里我觉得不可取，我在写 wepack 的过程中，感觉微信小程序很多设计上的问题，可以说完全继承了 web 发展以来所有的缺点
小程序底层双线程的架构我还是很看好的，但它用户层的这一整套，真的一点都不高明，这种东西成为了标准简直是灾难
再者说，之所以要搞 wepack，将微信小程序转译成其他端
本质上也是为了无论如何，保住微信，其他小程序嘛，可有可无
这玩意真的没办法，微信就是标准，再辣鸡也是标准
总结
基佬名言：数据结构乃造论之道
说实话，这就是我写这么多轮子，唯一悟透的真谛
国内 90% 的造轮师还停留在 casebycase 的阶段，这种轮子是非常可怕的，祸害业务线同学罢疗
其实这是一个鸡和蛋的问题，先有鸡再有蛋还是先有蛋再有鸡
现有业务，再有数据结构和算法，还是先积累数据结构，再应用到合适的场景上
我主张后者，但前提是积累，必须积累足够的认知才行
以上，这就是我最近的一些困惑和思考……
我最近被知乎大 v 喷的挺多的，我希望大家都能理性对待这些事，我回答的那些问题，基本上没什么营养，无非就是有人邀请了，我就去鸡同鸭讲一波
而且，我写文章就是用来放顶图的，我写回答也是专门用来招基的，这是我的个人爱好
所以你们懂了吧，我为什么不乐意去掘金发文章，就是因为掘金的顶图不够大！！！
以上，差不多就这些啦，我今天继续做梦冥思去
About The Author
