我想写一个前端开发工具（二）:不单单是个脚手架

　　我最开始的想法是搭一套工程环境，本也是很正常不过的事情，可是随着用的多了，就会发现几个问题：

　　一、架构与业务耦合：刚写完的时候的确是结构分明，都是架构代码，还没写业务，可是随着慢慢的交给不一样的人穿插维护，好多架构代码就会被加入好多的业务逻辑，一旦想动一动架构，就会发想藕合在一块儿的代码已经很难再拆分开了。

　　二、很差移植：我第一次写完后，下一个项目又要从老项目中去把非业务的东西复用出来，可是过了很久我本身都很难分清哪些是非业务的架构代码，况且是新的项目不必定是我来写，既没有时间每一个人搭一套工程（没时间，也不利于架构统一），不能每一个人复用的时候在把我叫过去。

　　三、不能快速上手：刚刚提到的问题就提到在快节奏的工程迭代中，咱们必须面临交叉维护、新人入职、老员工离职等一系列问题，快速的上手显得相对重要。既然想快速上手，就要有一套统一的项目配置，而且这个配置只暴露出少许的命令。维护这个配置要与业务分离。

第一步：首先它要是一个“脚手架”

　　基于上面的需求，个人第一步是先写一套配置，而后把它作成脚手架。我首先想到的是参考vue－cli的思路：可以初始化出我想要的工程目录，里面有个人工程配置。vue－cli的作法是经过初始化命令拷贝出一份基本的工程，而后经过npm script中命令完成开发、打包的操做来实现一个单页面应用。咱们第一步就能够模仿这个思路。

　　上一篇文章中介绍过，个人前端工具经过发布到npm平台后再全局安装，终端运行命令 $ coodev XXX 是能够读取到这个XXX的，换句话说就是我打算开发个人工具中的第一个命令（功能）： $ coodev init 。考虑到之后要有不止一个命令，我打算写一个map。简单来讲就是每个职务模块暴露一个render方法，这个map作一个命令字符和render()的映射。

　　我不浪费时间直接介绍第一个功能：init

　　一个脚手架是什么，就是把一套写好的项目配置的项目模板从一个维护的地方拷贝到项目文件夹下，这样就能够维护脚手架解藕，每一次init都应该拿到最新迭代的项目模板。换句话说就是，你要信有一套配置（我建议在单开一个git仓库维护这个项目模板）。个人模板放在https://github.com/grARM/coodev-temp-normal

　　任务已经简化到写一个工程配置了，只要提炼之前的项目积累，考验的就是前端工程化的基本功了，可是我接下来简单介绍一下我几个注意事项：

　　一、不要过于细致，不带业务，可分化多模板：

　　　　以前每次搭建一个项目的时候可能会为了开发的便利，耦合了很多与项目相关的业务逻辑，而咱们这一次要作的是通用模板，就不能带有业务逻辑。所以咱们要找到细致与通用中间的一个“度”。骨架应该仅仅包含开发、编译、打包等逻辑。固然也不能为了通用就写的不多，每个通用模板是为了处理一类业务的，好比PC前台、WAP前台、后台admin、专题页等。我不打算一个模板“同吃”全部类别的项目，相反咱们划定类别后，一个模板若是不能兼容，就用多个模板来对应，但要保证提供统一的接口工咱们的开发工具“调遣其余任务”。

　　二、统一接口

　　　　刚刚提到多模板的管理问题，虽然有不一样的模板，可是一些基本命令好比编译、打包上线都应该交给个人工具统一管理。好比我有一条命令 $ coodev dev 这条命令是监听源码目录下的文件修改，即时编译。那么咱们每个模板的都应该达到这个功能，要么都采用相似的工程目录结构，要么各自准备一个文件供dev调用。我才用了后者，缘由是这样可让哥哥模板配置更灵活。

　　三、独立文件导出，对应多平台，无缝对接

　　　　咱们虽然是一个前端工具，但要考虑server端的配合，毕竟你要在server渲染。若是server是nodeJS，就至关于同一种引擎渲染。可是每每大多数公司采用JAVA或PHP的server。渲染引擎通常是JSP、smarty等不一样的引擎。为了和原有项目无缝对接。咱们的编译结果应该是导出对应的*.jsp、*.php或*.vm等文件。对应js、css应该合并压缩。最好是在模板中预留一个配置文件，目的是对应适配server端的目录结构。

　　四、模板的独立维护

　　　　模板是个人前端工具的一部分，虽然说很重要，但不影响工具的主体逻辑。我比较建议将模板的维护放在另外一个git仓库，再开发好模板后同步到工具中，或工具本身去github上拉取。

　　

第二步：“不只仅”是一个脚手架

　　刚刚说到做为第一步的脚手架，来完成项目的初始化。做为脚手架来讲，任务已经完成了。咱们的工具要在整个项目中对项目进行控制，单纯的初始化、拷贝模板是不够的。以前用过一些脚手架，一些就没有其余命令了，另外一写好一点的大多吧命令定义在npm scripts 中，这样每每控制的是当前目录下的文件。这样脚手架工具的生存周期就结束了，工具就对项目没有了控制权。若是将一些命令的控制权交给咱们的工具。这样咱们还能够更多的整合一些资源，好比一条命令能够对两个仓库下操做，也能够编译、打包、同步上线仓库等一键执行。

　　除了以前的初始化，咱们还能够作些什么呢？

　　一、编译、打包、输出

　　二、本地服务

　　三、mock调试

　　四、本地渲染

第三步：有了雏形，咱们来体验一下

　　目前个人coodev提供了几条基础命令，全局安装coodev后 $ sodu cnpm install coodev -g 在咱们的开发目录下运行 $ coodev init 初始化目录后在安装依赖 $ cnpm install 后期考虑直接将安装依赖整合到 init 命令中，真正作到coodev统一控制。

　　接着运行 $ coodev dev 启动开发模式即时编译，和 $ coodev start 启动本地服务，用于开发调试。也能够复合命令 $ coodev dev start 同时启动两个任务。

　　更多的命令能够在安装后经过命令 $ coodev -help 来查看。

总结： 

　　一个工具的基本雏形已经设计完成，总结一下咱们工具的初步规划的至关于“脚手架 plus”。咱们的思路很明确：在完成脚手架的前提下，加入更多的实用功能，让咱们的工具能够完成整个前端开发的各个阶段。咱们作的一切，实为了在前端开发的每个阶段能够不依赖于server的开发环境，能够很快的展开工做，不用等待接口的提供。而最终又能够无缝对接

　　最终实现切图期间的分工协做、共用组件复用、架构上的先后分离。下一篇文章会针对一个模板介绍这些目标是如何实现的。