构建（思）一个下游仓库

最近正在准备重构博客，非常喜欢 shirone 的 markdown 处理器封装和插件设计，不过它内置的大多数功能我都感觉有点用不上😢，于是想做一个精简版的下游仓库，只保留我需要的 markdown 核心。

这次尝试不算成功，甚至可以说几乎失败。部分模块耦合很深，我始终没找到一种优雅的方式把想要的逻辑剥出来。

理想很丰满

作为下游，我预想的工作是：

同步上游变更
提取必要的源代码
修改部分源代码
重新构建、分发

前提是：我所需要的逻辑可以完全干净地拆出来，不需要太多 patch。第 2、3 步似乎没有什么特定时序，我自己实践起来几乎完全混合在了一起。

现实很骨感

同步源代码

这一步非常坚定地选了 git submodule，这大概是更早之前就想尝试的功能，至于当初为什么想试……嗯，想不起来了。现在我能想到的好处：

可以固定追踪某一修订(revision)
可以通过 git patch 管理变更
同步流程足够简单

这几条虽然是临时想的，不过的确算是优点。

修改然后提取捡到源代码

修改

因为对上游仓库做了一些修改，为了实现可重现我通过 git patch 进行管理补丁，简单写了一个 make-patch.sh 脚本将 diff 作为源代码管理起来。实现也不复杂，可以使用 git diff 获取到 submodule 的变更，简单来说就是这样：cd $SUBMOD && git ls-files -m -z | xargs -0 git diff -- > $PATCH。

修改方案几乎也是很确定的，但提取方案实验了好几个版本：

symlink

在反复读了几遍关键代码后，我选了几个入口文件，然后分析了一下依赖文件，将这些文件全部软链接到本仓库源代码文件夹，简单修改后发现这样不能被 npm pack 正确打包，npm pack 在收集文件时似乎忽略掉软链接。

复制

复制的方案选用的工具是 rsync，在我给定 pattern 后由 LLM 写了 extract-source.sh 脚本。结果实验，复制方案是符合预期的通过了 npm pack 的测试。

构建❓

可见我在上边实验了 npm pack，也就是说我已经觉得几乎成功了。关键的 markdown processor 也被提取了出来，我也做了一个小的 playground，拿到了正确的 markup 结构，基础目标算是达成。渲染后发现了没有 style 的处理，所以提取的这部分逻辑是不够完整的，重新翻查上游代码读到处理 style 的部分，说实话设计的蛮巧妙的，不过怎么将其提取并重新应用又是另一说。

LLM 笑传🤖

在经过我简单检查之后，发现缺失了这一部分逻辑后，再次求助 LLM。在它分析一通后，写出一个力大砖飞的 js 脚本：从几个入口文件出发，匹配源代码里所有的 import 语句和表达式，自行构建依赖树并复制。

提取脚本能跑，结果也基本符合预期，并且额外指出了一些难以处理的依赖。但这太面向过程 (?) 了，一点也不优雅，甚至不如我拟定 pattern 然后复制出来，我不太喜欢这样的解法。所以就先这样吧，让我们休息一下。

分发⌛

TBD