项目个性化配置策略

[hoperyy]

一般来说，脚手架和项目目录是父子关系，如果脚手架和业务代码分离，脚手架不参与业务逻辑，专注于打包等功能，自然是极好的。但这时会引入另一个问题：如果一个脚手架对接多个业务，如何满足业务的多样化需求？

一种方式是脚手架设定开放一些可供配置的 API，通过读取业务代码中的配置文件支持多样化的需求。

这种方式有一个缺点，就是 API 数量是有限的，不够灵活，如果开发者有新的需求，需要脚手架支持才行。

还有一种方式，为开发者暴露脚手架的各个生命周期，提供事件，开发者可在该事件中获取脚手架运行环境，并灵活处理各种情况。

这种方式的优点是灵活性强，几乎可以满足所有灵活性方面的需求，但缺点就是过于灵活而不够直观，上手难度大。

第三种方式就是结合上面两种方案：提供有限的 API 满足大部分灵活性的需求、同时暴露脚手架声明周期和环境为开发者提供灵活配置的功能。

目前公司使用的脚手架就是第三种，可维护性和使用灵活度都很高。