导读：本文是 San CLI 的应用和原理的第一篇，次要介绍 San CLI 的初衷和应用，下一篇介绍具体的实现原理。

一、什么是 CLI

CLI，是命令行界面（command-line interface）的英文缩写，命令行界面是在图形用户界面失去遍及之前应用最为宽泛的用户界面。

咱们就不看图形用户界面和命令行界面的定义了，间接举两个例子直观些。

这是图形用户界面：

这是命令行界面：

尽管命令行界面没有图形用户界面应用宽泛，但后者并不能取代前者，起因这里列举一些：

• 近程操作。如果咱们要近程操作一台服务器，而且不必命令行界面，那么，咱们就得先来个远程桌面连贯，这显然比拟麻烦，或者，咱们能够跑到那台服务器背后给它装个显示器，当然，服务器不能离咱们太远。
• 自动化。如果要用图形化界面执行一些自动化流程，那就得用按键精灵来录制操作
• 计算资源。图形化界面须要的计算资源远比命令行界面须要的计算资源多。

所以，有时咱们还是须要 CLI 的。

咱们理解了 CLI 后，那 San CLI 又是什么？

顾名思义，San CLI 是 San 的 CLI。简略来说，它是一个内置 Webpack 的命令行工具，当咱们在开发 San 我的项目时，它能帮忙咱们省时省力。具体它是怎么帮忙咱们省时省力的，文章后边会讲到。

二、为什么要做 CLI

1. 「生产工具晋升生产力」

CLI 是前端开发的生产工具，晋升 CLI 的体验能够间接晋升咱们的生产力，这是咱们的第一需要。

San CLI 从我的项目的创立、开发、调试、上线研发全流程动手，别离提供对应的解决方案，晋升研发体验和开发效率。

除此之外，CLI 作为开发过程中接触最多的工具，咱们的指标是以它为根底，做一套前端工程化集成解决方案，将我的项目和团队的最佳实际融入到 CLI 中，同时对立并且标准化我的项目，以便只须要降级 CLI 就能够实现解决方案在我的项目之间的迁徙。

举例说明：如果咱们团队通过实践证明某一个计划可行，那么咱们能够封装到 CLI 的某个命令中，或者公布对应的插件，通过扭转打包参数来让我的项目反对这种解决方案，比方 PWA、modern mode 等。

1. 「I have a dream！」

而咱们更巨大的指标是：把 San CLI 做成一套可定制的前端工程化集成解决方案，让大家能够忘了 Webpack，间接通过执行 San CLI 提供的命令行命令来开发。

「Yes，We Can！」

三、San CLI 有什么性能

接下来，咱们将从开发一个新我的项目的全流程，即我的项目的创立、本地开发、调试、打包上线这 4 个环节，来介绍 San CLI 的性能。

1. 创立：通过脚手架标准化我的项目

首先是我的项目的创立。咱们在命令行里执行 san init xxx，就会创立一个名为 xxx 的文件夹，而后在里边初始化一个 san 我的项目。

为了不便咱们之后开发，在初始化的过程中，命令行会询问咱们一些问题，咱们对这些问题的答复将决定最终初始化进去的我的项目是什么样子的。

咱们来看看初始化的理论过程。

能够看到，有一个正告，这个正告是因为咱们在执行初始化我的项目命令时没有指定脚手架模板，于是 San CLI 应用默认的脚手架模板来初始化。默认的脚手架模板就能够满足大多数状况，所以忽视这个正告就行。如果咱们遇到了须要另外指定脚手架模板的状况，比方咱们想用咱们自定义的脚手架模板，能够移步 San CLI 官网文档查看该怎么做，这里咱们只介绍最罕用的局部。

当初咱们来看下命令行问咱们的这些问题别离都是什么意思。

• 项目名称：这个名称会用于 package.json 里的 name 字段的值，以及 README.md，默认应用我的项目所在文件夹的名称作为项目名称，在这里也就是 xxx。
• 我的项目形容：用于 package.json 里的 description 字段的值。
• 作者：用于 package.json 里的 author 字段的值，以及初始化时生成的文件的头部正文。
• 抉择模板引擎：有 2 个可选项，一个是图中的“Smarty”，另一个是“纯 HTML”，也就是不必模板引擎。如果咱们不理解模板引擎或者不晓得该选什么，那就选“纯 HTML”。
• 是否装置 ESLint：ESlint 的作用是查看编码标准。
• 抉择 ESLint 配置：如果咱们上一步批准了装置 ESLint，才会有这一步。这一步有 3 个可选项，@ecomfe/eslint-config、Standard、Airbnb，选咱们喜爱的就行，百度外部个别是用 @ecomfe/eslint-config。
• 是否装置 ESLint 的 lint-staged：如果咱们之前抉择了装置 ESLint，才会有这一步。如果装置，那么，之后咱们在开发中执行 git commit 的时候，会对改变的文件进行编码标准查看，查看不通过就无奈实现 git commit。出于对高质量的代码的谋求，倡议装置。有的人可能会放心有的状况的确不须要查看代码标准怎么办，比方把远古期间的代码从一个库迁徙到另一个库，很简略，只须要给 git commit 命令加上 --no-verify 就能够跳过查看了。
• 装置 demo 示例：如果咱们对用 san 开发不相熟，倡议装置，这样咱们开发时就能够参照 demo 了。
• 抉择示例代码类型：如果咱们上一步批准了装置 demo 示例，才会有这一步。这一步有 2 个可选项，“san-store”和“normal”。如果咱们不晓得本人是否须要用 san-store，那就不必。
• 抉择 CSS 预处理器：有 3 个可选项，less、Sass、stylus，选咱们喜爱的。
• 是否装置依赖，这里可装可不装，这里不装的话之后能够本人装。

最终初始化进去的我的项目看上去是上面这样的：

Hands up：当初咱们团队我的项目中的组件每次创立目录构造也是相似的，所以能够做成脚手架而后应用 san init 来装置

1. 开发：local server、mock

创立完我的项目，就到了开发阶段。在开发阶段，须要调试页面，那咱们能够在命令行里我的项目目录执行 san serve。

执行完之后，命令行会输入一个 URL 和一个二维码，如下图所示：

拜访这个 URL 或者扫描这个二维码，就能够看到咱们正在开发中的页面了，如下图所示：

咱们批改代码后，页面会实时地响应咱们的批改，十分不便。

Hands up：对于 smarty 咱们提供了 hulk-mock-server 来做 local server，另外它也集成了接口 mock 性能，能够对接相似 YAPI 之类的 API 治理平台。

1. 部署：生产环境打包和近程部署

开发实现后，如果须要部署到其它的机器上，比方部署到 QA 的机器好让 QA 测试，这时就要用到生产环境的打包。

生产打包也很简略，在命令行里我的项目目录执行 san build 就行。

执行完之后，咱们能够在命令行里看到打包后果的信息，包含产出的文件所在门路、文件大小等，如下图所示：

打包好了就该部署了，San CLI 当然也反对了，咱们通过执行 san build --remote <remote-name> 就能够将生产环境的编译产出间接近程部署到指标机器。

不过在执行这个命令前，须要进行相应的环境配置以及参数配置，详见 San CLI 官网文档：https://ecomfe.github.io/san-cli/#/deployment。

1. 其余性能

1）查看 Webpack 内置信息

有时咱们可能对打包的后果不称心，那就能够通过在命令行里我的项目目录执行 san inspect 来查看 Webpack 所有的内置信息了，如下图所示：

如果只想打印局部内置信息，也是能够的，只须要在执行命令时加上想要查看的内置信息对应的参数即可，比方加上 --rules 或 --rule postcss。

2）图形用户界面

尽管咱们名字叫命令行界面（CLI），然而咱们也提供了图形用户界面以不便不同习惯的开发者。

只有在命令行执行 san ui 就能够关上 San CLI 的图形用户界面了，如下图所示：

该图形用户界面不只是把在命令行里也能做到的性能图形化了，它还提供了命令行不具备的性能，比方治理我的项目、浏览新闻等，值得一试，后续咱们会有专门介绍该图形用户界面（即 San CLI UI）的文章，敬请期待。

四、怎么本人定制性能

尽管 San CLI 自身的性能曾经笼罩了绝大多数的用 San 开发时的场景，然而如果咱们想要定制化的性能，也没问题！

咱们能够通过编写插件来扩大 San CLI 的性能，自定义解决方案。

针对 CLI 的应用场景，咱们将 San CLI 的插件设计成了两类：

• Command 插件：命令行插件，用于增加自定义命令，增加完之后咱们就能够执行 san your_command_name 这样的自定义命令；
• Service 插件：当咱们想要定制的性能须要用到内置 Webpack 配置 或 san.config.js 里的配置时，就抉择开发 Service 插件而不是 Command 插件。

接下来咱们以理论的例子别离看下具体怎么自定义 Command 插件和 Service 插件，通过简略例子，了解下两种插件的不同用处。

1. Command 插件

咱们打算给 San CLI 扩大一个 hello 的命令，成果是当咱们执行 san hello --name 百度 后，命令行会输入 百度，你好呀！。

首先在我的项目根目录创立一个名为 san-command-hello.js 文件，内容如下：

exports.command =’hello’;exports.builder ={name:{ type:’string’}};exports.desc =’ 激情地向给定对象打招呼 ’;exports.handler= argv =>{console.log(${argv.name}，你好呀！);};

• exports.command：定义命令的名字，这里咱们给定义为了 hello；
• exports.builder：定义命令承受的参数和参数类型，这里咱们定义命令承受字符串类型的 name 参数；
• exports.desc：定义命令的形容，即咱们在命令行输出 san hello --help 后的输入，这里咱们给定义为了 激情地向给定打招呼对象；
• exports.handler：定义输出命令后的处理器函数，这里咱们通过处理器函数的 argv 参数拿到了命令承受的 name 参数，而后用它拼接了一个字符串，最初输入这个字符串。

而后在我的项目的 package.json 文件中增加如下配置：

至此，就功败垂成了，来看看执行成果：

嗯，令人满意。

另外，咱们还能够把咱们自定义的命令作为 npm 包公布进来，在这个例子中就是公布 san-command-hello.js 文件，并且遵循 san-cli-command-<whatever-you-like> 的命名形式，比方 san-cli-command-hello，那么，咱们就能够在其它我的项目中间接通过装置这个 npm 包来引入这个自定义命令了。

2. Service 插件

咱们看完了怎么自定义 Command 插件，接下来就来看怎么自定义 Service 插件。

咱们打算自定义一个 Service 插件用于获取网站的入口文件。

首先还是在我的项目根目录，创立一个名为 san-cli-plugin-get-entry.js 文件，内容如下：

Service 插件的 apply 函数承受三个参数：

• api：是 PluginAPI 实例，会提供一些 API，详见 San CLI 官网文档；
• projectOptions：是 san.config.js 里的解决后的我的项目配置；
• options：是我的项目引入插件时传入的参数。

而后在我的项目的 san.config.js 文件中增加如下配置：

plugins是一个 Service 插件数组，外面的每一个 Service 插件又是一个数组，数组第一项是插件的门路，数组第二项是传入插件的参数。

对于 Service 插件的执行机会：当 Service 实例化之时，会顺次将 Service 插件进行注册执行。那 Service 什么时候实例化？咱们能够简略认为当咱们输出 san init、san build 等命令时 Service 会实例化。

至此，又功败垂成了，也来看看执行成果：

能够看到，当初执行 san build 比之前执行多了两行输入，这两行输入就是咱们自定义的 Service 插件产生的成果。

嗯，再次令人满意。

当然，和 Command 插件一样，咱们也能够把咱们自定义的 Service 插件作为 npm 包公布进来，为了不便别人找到咱们的优良 Service 插件，倡议依照 san-cli-plugin-* 来命名。当引入一个 npm 包模式的 Service 插件时，只需把原来的插件门路 './san-cli-plugin-get-entry.js' 换成 require('san-cli-plugin-*') 即可。

五、最初

感激你浏览到了这里，以上便是《为什么咱们开发 San 我的项目时要用 CLI？》的全部内容。

San CLI 除了以上介绍的的性能外，还有其它许多性能，比方打包剖析、性能剖析、自定义我的项目脚手架、Markdown 建站等等，不一而足，墙裂 举荐你体验体验！

咱们下期《San CLI 的实现原理》再见！

原文链接：https://mp.weixin.qq.com/s/R9hE5wdCkDQTZEKwQ4DiFQ

百度架构师

百度官网技术公众号上线啦！

技术干货 · 行业资讯 · 线上沙龙 · 行业大会

招聘信息 · 内推信息 · 技术书籍 · 百度周边

欢送各位同学关注！