hexo 又成了技术流的玩具
2019-02-28
其实写这篇文章,心情不太痛快。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 出来的项目应该也会受影响才对啊。
好吧,不折腾了。下次再遇到,所有缓存,全部清理得了。