背景
最近有个工作了4年的前端朋友跟我诉苦说他最近去到一个小公司，虽然开发很自由，但是效率却很低。细聊之后才知道，原来他们公司前端既没有成文的规范，也没有常用的开发模板，每次领导要开发新项目，之前的同事都是从老项目拷贝过来然后将业务代码删了，留下个能请求、有路由、有菜单的架子，虽然这样也能勉强开发，但是突然有一天领导要他维护几个项目，而他拉下代码发现这几个项目都是用不同的框架和UI组件库写的。他说他光是配环境、看文档都头晕了，还要赶需求，各个项目切来切去，被搞得激情全无。
更可怕的是，由于最近公司降本导致很多后台开始参与前端项目的开发，部分项目发布生产出现了Bug，他作为专职前端自然少不了背锅，其实他也想做好code review 怎奈精力有限，总有漏网之码。而出现问题的地方大部分都是因为框架部分改错了导致的。
因此这位朋友为了防止这种背锅的事再次发生，他决定对公司前端做一次大变革！他说他这次想做一个脚手架，类似vue-cli那种，能拉模板，能有规范，统一框架等等，我说那你做呗。他说他只有思路，没有做过，都不知道怎么开始......
正文
脚手架，这个名词相信很多人都会联想到建房子时搭建的排栅，而它在前端开发里有点类似于项目骨架，帮我们抽离了非业务的部分，让我们开发更专注于业务代码，提高开发效率。尤其是框架、架构、UI库、开发规范的等 这些都是公司开发过程中沉淀的宝贵经验，如果能自动化生成项目模板集成了已有的开发沉淀，那还愁摸鱼时间不够吗？ 确实，谁都知道脚手架很好，很多人也想开发一个自己的脚手架，偷偷懒，争取更多的摸鱼时间，但是要怎么开始呢？
其实我们不妨站着巨人的肩膀上去了解一下 终端是怎么识别命令的，比如我们拿熟悉的Vue脚手架
vue-cli来说，一开始我们是不是要执行
npm install -g @vue/cli那不用说@vue/cli一定是放在了npm上做托管的，但是npm install -g这一句代码到底做了什么呢？
我的理解 它主要做了两件事
1.识别install 命令 这是下载依赖
2.将@vue/cli下到全局node_modules中 并在bin目录下增加与@vue/cli相关的软链接
有点类似执行力npm link
它怎么知道@vue/cli是用什么命令开头 比如vue create ?进一步理解那肯定是有什么地方开始了Node,那是哪里呢？稍微了解一点的人都应该想到了 没错 就是项目中的package.json,它里面有个属性bin 这里我们可以声明自己的脚手架命令 并指定命令的软链接文件
哈哈，扯远了。我们应该先想想我们的脚手架应该具备什么能力 然后才具体到代码层面
那么一个基本的脚手架应该具备什么能力呢？我以为
1.它应该能被npm install
2.它应该能被Node执行
3.它应该能接收终端命令
4.它应该能跟使用者终端互动，比如你问我答
5.它应该能生成或远程拉取各种项目模板
那么具体到代码层面 该如何开始呢？
那当然是到代码仓库啦。
感兴趣的同学,请移步
easy-u-cli: 一款小巧的前端脚手架，可用于实际开发
或者直接
npm install -g easy-u-cli期待你的打ko哟