這是一篇轉自雲謙公眾號的文章，個人覺得比較有意思的項目，轉給大家看看
昨天上午，螞蟻金服插件化的企業級前端框架 —— Umi 3 正式發佈；而 dumi 作為 Umi 3 生態的中的一部分，也將正式和大家見面！
顯然，這個命名已經透露了它和 Umi 的關係。dumi（嘟米）是基於 Umi 打造、為組件開發場景而生的文檔工具，用大實話講，dumi 就是可以用來寫文檔、官網和組件庫 Demo 的 Umi。
一直以來，Umi 都在前端應用研發領域深耕、蛻變，如今已愈發成熟和強大；而在組件庫研發領域，縱然我們曾推出了組件庫開發、打包工具 father，但在組件庫開發的過程中卻經常面臨編譯構建速度慢、報錯提示不友好、用 mdx 編寫的組件庫 Demo『只能看不能用』、想打造一個帶 Demo 的組件庫官網成本極高等現實問題，dumi 正是為了解決它們而來！
dumi 究竟能力幾何？
讓組件庫研發即刻開始
通常我們準備開發一個組件的，首先要面臨的並非打包的問題，而是如何對這樣一個組件進行調試：
為了把這樣一段代碼跑起來，我們需要準備 webpack、babel、TypeScript…會發現和研發前端應用時的準備工作重合度極高；而有了 dumi，我們只需要像未來即將使用這個組
此時只需要執行 dumi dev 命令，將會看到一個漂亮的組件庫文檔，而這個調試的 Demo 也鑲嵌其中：
眼前的組件庫文檔和 Demo 都是由 Umi 驅動，這意味著，Umi 具備的所有研發優勢我們都可以照單全收！有了 dumi，使得我們的注意力可以專注在組件庫研發細節上。
讓 Demo 好寫、又好用
dumi 在寫 Demo 這件事上有著自己的理念——開發者應該像用戶一樣寫 Demo。一個 Demo，對生產端和消費端都無比重要，開發者作為生產端，需要寫得爽、易維護；用戶作為消費端，需要『開箱即用』。
先說開發者。用 mdx 寫過 Demo 的朋友應該都能回憶起嵌入 State 組件姿勢十分別扭、以及時常被超過 100 行的 Demo 支配的恐懼；在打造 dumi 時，我們曾問自己：用戶會在 Markdown 中寫代碼嗎，既然不會，開發者又為什麼要呢？所以，dumi 提供了一種新的 Demo 形式——外部 Demo：
這種新的 Demo 類型使得開發者可以像用戶一樣利用編輯器的 Code Snippets、ESLint、prettier 等強大功能，再大的 Demo 都能輕鬆維護。只要 Demo 超過 30 行，dumi 都建議在外部進行編寫，世間如此美好，又何苦在 Markdown 文件中折磨自己。
再說用戶側。用戶其實就關心一個問題：你這個 Demo 跑得是挺好，但我能不能直接拷貝過去用？為了讓消費端能開箱即用，dumi 是這麼做的：
首先，無論是任何形式的 Demo，包括外部引入的 Demo，用戶都可以在文檔界面查看到真實的源代碼，且都可以選擇拷貝或者到 codesandbox.io 中試運行。
其次，dumi 會建議開發者在生產 Demo 時像真實用戶一樣去做：
這樣一來，就可以確保用戶所看到的 Demo 就是『開箱即用』的，Demo 也真正做到了能看、也能用。
適合『全年齡』段組件庫
任何一個組件庫都有長大的夢想，待它長大後，也許就成了 UI 框架。但長大了也無需擔心衣服不再合身，在組件庫弱冠之年，只需要將 dumi 配置中的 mode 配置項修改為 site，再添加一些文案配置，我們的組件庫文檔就會立即蛻變為組件庫官網，就像這樣：
是的，dumi 基於 Umi 3 打造，Umi 3 的官網基於 dumi 搭建，Umi 生態中又新添一名成員。
最後一個問題，組件開發、編寫 Demo 和文檔搭建都解決了，打包咋整？打包仍然推薦使用 father-build，與 dumi 一起，為我們組成全流程的組件庫開發工具鏈。
dumi 需要你
dumi 最初叫 father-doc，很榮幸就算沒有做過任何推廣，此前也有許多社區的夥伴參與到了 father-doc 的建設中（歡迎遷移到 dumi）；即便從 father-doc 發佈第一個 alpha 版開始、到改名為 dumi 發佈正式版的今天，dumi 誕生也不過百日出頭，仍然是個『寶寶』。
而且我們未來還有許多的想法計劃將組件開發這件事做得更深，例如將 dumi 的 Demo 生產端和 Umi UI 的資產消費鏈路打通、為移動端組件開發打造移動端模式等等，倘若我們志同道合，真誠地邀請你和我們一起將 dumi 變得更好：https://github.com/umijs/dumi
閱讀更多 IT拾荒老人 的文章
