爲何咱們開發 San 項目時要用 CLI？

導讀：本文是 San CLI 的使用和原理的第一篇，主要介紹 San CLI 的初衷和使用，下一篇介紹具體的實現原理。

1、什麼是 CLI

CLI，是命令行界面（command-line interface ）的英文縮寫，命令行界面是在圖形用戶界面獲得普及以前使用最爲普遍的用戶界面。

咱們就不看圖形用戶界面和命令行界面的定義了，直接舉兩個例子直觀些。

這是圖形用戶界面：

這是命令行界面：

雖然命令行界面沒有圖形用戶界面使用普遍，但後者並不能取代前者，緣由這裏列舉一些：

• 遠程操做。若是咱們要遠程操做一臺服務器，並且不用命令行界面，那麼，咱們就得先來個遠程桌面鏈接，這顯然比較麻煩，或者，咱們能夠跑到那臺服務器面前給它裝個顯示器，固然，服務器不能離咱們太遠。
• 自動化。若是要用圖形化界面執行一些自動化流程，那就得用按鍵精靈來錄製操做
• 計算資源。圖形化界面須要的計算資源遠比命令行界面須要的計算資源多。

因此，有時咱們仍是須要 CLI 的。

咱們瞭解了 CLI 後，那 San CLI 又是什麼？

顧名思義，San CLI 是 San 的 CLI 。簡單來講，它是一個內置 Webpack 的命令行工具，當咱們在開發 San 項目時，它能幫助咱們省時省力。具體它是怎麼幫助咱們省時省力的，文章後邊會講到。

2、爲何要作 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！」

3、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）的文章，敬請期待。

4、怎麼本身定製功能

雖然 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-*') 便可。

5、最後

感謝你閱讀到了這裏，以上即是《爲何咱們開發 San 項目時要用 CLI？》的所有內容。

San CLI 除了以上介紹的的功能外，還有其它許多功能，好比打包分析、性能分析、自定義項目腳手架、Markdown 建站等等，不一而足，牆裂推薦你體驗體驗！

咱們下期《 San CLI 的實現原理》再見！

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

---

百度架構師

百度官方技術公衆號上線啦！

技術乾貨 · 行業資訊 · 線上沙龍 · 行業大會

招聘信息 · 內推信息 · 技術書籍 · 百度周邊

歡迎各位同窗關注！