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