wepack 之 dependency tree

halo，大家好，我是西天小如来 132，米娜好久不贱，真的好久好久

最近状态特别不好，工作上做了一个短期不会产生收益的项目，加上最近老被质疑，有点怀疑人生了……

其实，我在公司里，写的是一个叫 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 喷的挺多的，我希望大家都能理性对待这些事，我回答的那些问题，基本上没什么营养，无非就是有人邀请了，我就去鸡同鸭讲一波

而且，我写文章就是用来放顶图的，我写回答也是专门用来招基的，这是我的个人爱好

所以你们懂了吧，我为什么不乐意去掘金发文章，就是因为掘金的顶图不够大！！！

以上，差不多就这些啦，我今天继续做梦冥思去