其实写这篇文章，心情不太痛快。hexo 是我找了好久才确定下来，能用 markdown 写 blog 的系统。之前试过的如 jekyll 太复杂，而且定制化程度太低，不灵活。刚开始用 hexo 的时候发现它简直是尤物，轻便简洁，扩展性还不错，官方收录了很多 plugins，足够码农用了。

结果没过几年，hexo 也快成了技术流的玩具。

问题一。npm 依赖存在缺陷

首先是 "hexo@3.8.0" 某个依赖 "hexo-fs@0.2.2"，后者依赖 "chokidar@1.2.7"，而 chokidar 又依赖 "fsevents@1.1.3"。好了，最后这个 "fsevents@1.1.3" 是被 deprecated 的版本，包含原生库，已经不存在 binary 下载，从源码编译也会报错。错误的大意是跟 node 的版本不兼容。

下面我把这个关系链重新理一下。

graph LR;
    A["hexo@3.8.0"]-->B["hexo-fs@0.2.2"];
    B-->C["chokidar@1.2.7"];
    C-->D["fsevents@1.1.3"];
    D-->E["(HELL)"];

除了上面的问题以外，大量已经停更的 plugins 依赖的 "hexo-cli@1.0.3" 等旧库，也多对 "fsevents@1.1.3" 存在间接依赖。

用一句话来说后果，在 MacOS 下，用 hexo-cli new + npm i 的方式，根本安装不上 hexo。

问题二。插件的停更、老化

像上面提到的，停更的插件，其间接依赖的第三方库若是被废弃，插件本身也就不可用了。这是一种情况。

第二种情况，hexo 本身在发展，某些停更的第三方插件没有跟着做适配，结果是 hexo 的使用体验受到了影响。

第三种情况，最常见的。哪怕是官网列表中的插件，质量也是有高有低，对那些技术不灵光的用户实在麻烦。

解决方法

针对安装不上的问题。我也不知道怎么解决 :( 我用撞大运的办法，hexo-cli new 一个项目以后，手动修改 package.json，将 "hexo@3.8.0" 这个依赖指向自己 fork 的 hexo repo，这个 forked repo 里面已经修改了 hexo-fs 是指向一个 forked hexo-cli repo。最后在这个 forked hero-cli repo 里面，把对 chokidar 的引用上升到 "chokidar@1.7.0" 以后。

挺复杂的，对吧。不懂点开发，还真办不了。

针对插件停更、老化的问题，只有一个办法，就是自己 fork 做二次开发。项目的依赖中直接写上自己的 git repo。

别问我有没有现成的。我也很无奈。

PS：这就是 npm 生态带来的问题。left_pad 事件发生后，有人说 nodejs 程序员懒到『 连最简单的代码都不想写』，只想引用。我不太赞同这个评论的态度，不过 npm 社区的程序员的确是把代码复用做到比较极致的地步。

UPDATE(2019-02-28)

发现在新 new 的项目里面，"hexo@3.8.0" 的发布版好像是依赖的 "hexo-fs@0.2.3"，已经升级到间接依赖 "fsevents@1.2.7"。

挺无语的。真的。还有点懵圈，没太搞懂。

昨天我可是 rm -rf ./node_modules/* && npm i 操作的，按说缓存应该没影响才对。如果是 npm 自己的 cache（我设置到了 ~/.npm/cache 目录），新 new 出来的项目应该也会受影响才对啊。

好吧，不折腾了。下次再遇到，所有缓存，全部清理得了。