現在對于前端框架的定義越來越廣泛了，在前端工程化中的某一個環節的特定方案，都可泛稱為一個前端框架。konos 是一個插件化的前端框架基座，如果你對 umi 有所了解的話，可以把它當作一個沒有任何功能的 umi core 基座。konos 提供了一些簡單的接口，方便用戶擴展和編寫 cli 服務。比如想寫一個 'yarn create app' 用于初始化項目的話，只需要：然后執行 'npx konos init cli' 就可以完成一個和用戶交互后生成腳手架的工作。
這個需求最初來自靈犀開發平臺的靈蜂框架需求，它需要將部分模塊通過產物包的方式提供給用戶，而部分模塊以源碼的方式提供，然后需要在開發的時候將所有的模塊串通，因為不同模塊之間存在業務關聯和鑒權。所以再編寫這個框架的時候，我就想這么特殊的需求，放到 alita 里面不是很合理，而且和業務性關聯性太強了，最終可能需要將這個框架交付到業務開發人員的手里維護。就需要這個框架的可擴展性極強，上手難度極低。所以將核心的功能抽離成 konos，將業務性綁定的放到腳手架本地的 scripts 中，但是同時將他映射為本地的可執行命令。（這個不在本次的分享內容中）
這就完成了一個 hj 框架，你可以使用 hj xxx 的命令來啟動對應的 cli 服務，比如內置的 hj inits config，可以在當前項目生成 hj 框架的配置文件。以下舉幾個例子來展示如何基于 konos 編寫一個部門級別的前端框架：可能你剛開始不知道需要加什么配置，你可以在你需要的時候再回來添加，這里我為了后續描述的連續性，先在這里全部列出了，我這次需要使用的配置。因為部分模塊是以產物包的方式提供給用戶，所以就需要一個上傳和下載的云端，如果有服務器提供，你可以根據上傳和下載的接口來完成這個流程，我這里為了演示方便，就用 npmjs 作為我的云端。這個要考慮到對接的模塊是以什么框架構建的，但是正常的產物包是放在 'dist' 或者 'build'，所以我們默認去找這兩個目錄，當然也提供配置給用戶指定，就是上面添加的 'outputPath':找到構建產物包之后，其實很簡單，只要新建一個 'package.json'，然后使用 'npm publish' 就可以把包發布到 npm 上。新建文件 src/commands/publish.ts前面說到上傳非常簡單，只需要執行 'npm publish' 就可以，那下載是不是只要執行 'npm install' 就可以呢？其實這要看和我們的需求是否符合了，'npm install' 會將子包放到 'node_modules' 文件夾下，然后所安裝的模塊也需要編寫在項目的 package.json 文件中，但是這個包顯然與我們正在開發的項目無關，并且放到 'node_modules' 之后也很“難”找到，當然通過包名查找也不是很難，但是如果后續還需要預覽，做文件代理顯然是一個大問題。所以我們需要編寫一個特定的 'npm install' 來完成我們的需求，這要求我們對于 npm 的執行有一定的了解，這里不做過多的展開。簡而言之就是下載-解壓的過程。npm 除了根據 package.json 執行 'install' 之外還可以使用通過執行 'npm pack repo@version' 將指定的包下載到本地文件，當然了，需要注意的是下載的執行目錄要避免是一個 npm 包，因為 'npm pack' 也用來將當前項目做一個打包壓縮，你可以簡單的理解為執行 'npm publish' 的時候，其實是先執行了 'pack' 再上傳。你可以在任意空文件夾下嘗試一下，比如執行 'npm pack xiaohuoni@0.0.1'，將會在當前文件夾下得到 'xiaohuoni-0.0.1.tgz' 文件，然后使用解壓工具打開它就能得到和 'npm install xiaohuoni@0.0.1' 一樣的內容，只是存放路徑不一樣而已。因此我們需要做的只是簡單的解壓文件操作，將文件解壓到它對應的包名的目錄下，使用 linux 命令就可以完成：由于 linux 命令在 window 上需要打開 git 提供的命令行工具才能正確執行，所以我們使用 node 包 'tar' 來完成。為了加快每次執行安裝的過程，我們可以加一個簡易的緩存機制，如果本地已經存在對應的 'tgz' 包，就使用本地的包而不再從 npm 上下載。關于需要指定安裝的模塊，我們通過增加一個配置 'dependencies' 來完成：dependencies 使用和 package.json 中的 dependencies 配置一致，這對于前端人員來說，零理解成本。上面我們提到文件將被解壓到對應包名的目錄下，比如 '@lingxi-assets/demo' 默認的解壓路徑是 '/build/demo'，模塊相互之間存在關聯性，所以這個文件結構，可能會遇到需要靈活配置的時候，因此我們增加一個配置 'paths' 用來指定包名對應的解壓路徑。'@lingxi-assets/demo' 最終會被解壓到 '/build/hello' 目錄。新建文件 src/commands/install.ts
至此這個需求就都完成了，下面，我再舉一個前端框架常見的需求舉例，我們再框架構建之后，總會在本地打開，看看構建產物是否都正確生成，不管構建環節的腳本和測試做的多么完善，這也算是一種人工的兜底行為，我們常用的就是 'cd build && serve' 這會在本地 3000 端口啟動一個 server 服務，能代理映射到 build 目錄，因此我們可以方便的訪問 'build/index.html' 文件來驗證產物。但是常常遇到一個問題，本地開發使用 proxy 作為代理，中轉了請求，但是在 build 之后 proxy 可能就無效了，因此我們現在的需求就是，在 build 之后，如何繼續使用 proxy 配置。其實我們可以簡單的寫一個命令，如 'hj preview'。其實就是一個 express 中間件，需要的數據，我們可以通過增加兩個配置 'proxy' 'nginx'來指定。根據上面的配置，我們就可以實現，當訪問首頁的時候，自動代理到 'demo' 目錄，當請求以 '/server' 開頭的路徑會被中轉到目標服務器，所以只要 proxy 配置與開發時使用的 proxy 配置一致，nginx 配置與部署時使用的 nginx 對應，就可以在本地更好的還原云端的部署情況。這在調試驗證的時候，非常好用。新建文件 src/commands/preview.ts
不知道細心的你有沒有發現，上面實現的三個功能，每個功能實現代碼行數都沒超過 100 行，其中還包括空行和必要的模版代碼。這在使用 konos 之前是比較難做到的，畢竟簡單的 cli 的命令行配置也要寫不少的代碼。另外文件其實可以放在任意的目錄下，模版腳手架為了邏輯上能更好的管理項目，因此區分了 'commands' 'config' 'generators' 'inits' 這幾個文件夾，你可以完全按照你的個人喜好來重新組織文件結構，只需要最終在 'src/preset.ts' 文件中，使用上你編寫的文件即可。
假如把 'umi' 'alita' 'fish-x' 這樣的通用框架稱為公司級前端框架的話，那基于 konos 的產物，就是部門級的前端框架了，它擁有更高的客制化和超高的純凈度，但同時也代表著它沒有附帶任何的功能實現，每一步要做什么都需要開發者自己實現，所以如果是常規的前端需求，最好還是選用公司級的前端框架，畢竟框架給的足夠多。不過好在 konos 開發人員僅僅需要掌握一點點的 node 和 express 知識。當然你也可以把部門級框架當作公司級框架的功能補充，以 konos 的靈活性完全可以兼容所有的前端框架。