首先,我要说明的一点是,我在项目的前期是有使用composer的,那时候我觉得一个新项目不使用Composer那就是开倒车。但是其实不是这样的,Composer是一种依赖的管理手段,它的主要功能并不是作为一个引导程序去使用,而我恰恰就是将其作为引导程序使用,因此迷失了方向……
最初TarBlog项目仅有一个主要依赖,就是illuminate/database,它是从Laravel中剥离出来的数据库组件。我一直很中意这个组件的设计,但是当时水平不足,无法用自己的语言复现其行为,因此直接作为依赖引入到了项目中。到后来,我发现只引入这个组件太浪费了,因为它带来了很多额外的无用文件,因此打算充分利用,想搞一个类似于Lumen的框架内核。当然,这个野心没有实现,调试起来过于麻烦,而且体积也越来越大,我发现这是没有意义的。
回归本质,做这个博客程序的目的其实并不是去做成一个大型框架,而是做一个相对定制化且轻量级的博客程序。到了今天,我可以说定制化基本上已经完成(想对于我而言);而轻量化,目前仍然在努力,因为一些前端组件确实也没法一下子用更轻量的东西去代替,但是代码层面上基本是轻量化的。
说到这里,其实我不再使用Composer的原因基本上已经都阐明了,我再补充和总结一下:
- Composer带来太多无用依赖,导致占用体积大
- Composer的自动引入机制其实是PHP自动引入机制的扩展,是可以自己实现的
- Composer对于我的插件机制来说是噩梦,非常影响开发者定制插件的灵活性
- Composer在虚拟主机上基本无法使用,还要本地安装好依赖再打包到虚拟主机上,麻烦
- Composer很影响我整个安装流程,去掉它我的安装流程设计会更加轻松
这些也只是一些原因,一些更深层次的原因我暂时不提,但是我相信这些问题已经足够让我弃用Composer。
不过,这不代表我讨厌Composer,对于Composer管理比较大的项目我还是很欢迎的,因为本身就不考虑体积的问题,而且Composer安装依赖非常方便,可以不用去一一找官方网站下载依赖,更新卸载也不需要手动操作文件。我的另一个项目NewIDC就是通过Composer管理的,框架使用Laravel,因为这个项目比较庞大,所以直接用现成框架很省事。
项目要不要使用Composer,主要还是考虑到项目规模,如果不大且用不到太多依赖,建议还是“原始”一点,这样可以掌控全局;项目规模大,则用Composer更好,用到的依赖越多,越能体现Composer的价值。最后,不要把Composer单纯地当作一个自动引入插件,没必要!