>[danger] **棄用提醒：** > *由于看云對于免費用戶的限制愈發嚴苛，本文檔已經遷移至語雀。本文檔將不做維護。* > **語雀地址**：[https://www.yuque.com/a632079/nodebb](https://www.yuque.com/a632079/nodebb) ***** # 開發 NodeBB 開發其實是一種比較繁瑣的事情。 **你很可能會遇到如下的問題:** 1. 難調試 2. 文檔殘缺 3. Hook 不全 4. Node.js 本身自己存在的錯誤消息問題（比如:回調堆棧無法幫你定位到錯誤） ## 難調試 ### **為什么說 NodeBB 插件難調試?** #### **1. 本地測試比較繁瑣** 盡管我們推薦使用 諸如：`npm link` , `yarn link`, `pnpm link` 之類的鏈接方式調試應用， 但是顯然這種方式不適合全部插件。 最典型的例子就是 `SSO` 插件， 由于這類插件的要求比較苛刻， 很可能要求你必須在生產環境測試。 這時 `link` 不再易用， 轉而只能使用 `npm i git-packages` 這類方式進行調試。這種情況下，每次對插件進行更改， 必須修改版本號才能正常更新， 調試起來十分麻煩。 > **注:** SSO 方案下， 盡管本地可以調試。 但對于新手可能要求較高， 需要配置本地 web 環境， 以及 hosts 域名 至 127.0.0.1。 故， 我們將新手習慣于在生產環境測試 SSO 的情況作為本點的案例。 #### **2. 報錯機制不合理** 在 NodeBB v1.7.x, `csrf_invalid` 是其最難以定位的錯誤之一。這種錯誤， 小到 `config.json` 配置錯誤可能引起， 大到插件 JS 回調錯誤， 客戶端 JS 編譯錯誤引起。我們對于這種情況， 只能 `./nodebb reset -p` 禁用所有插件， 然后一一啟用， 最后確定問題插件， 進行修復。在整個修復過程中， 也只能是逐句測試， 無法快速定位到問題位置。 還有另一個典型: 往 `adminHeader` 添加 **名稱** , 添加插件路由。 訪問地址，終端日記顯示空路由，無報錯信息。這種情況同樣也很難調試。常常無意間引起，又在逐行測試時修復。很難找到問題的根源（請確保你已執行 `./nodeb build`， 讓你的插件模板編譯進去） 編譯器的設計也不是十分合理。有時，你看到編譯器成功編譯，但訪問卻發現社區功能異常。排查后，發現`nodebb.min.js` 里的內容為 `undefined.`。這是什么問題呢？ 其實解決的方法很簡單: **不要使用ES6 / 2015 中定義的語法**。 當時我在書寫這個文章的時候， 花費了 2 天時間才知道壓縮器并不支持 ES6 語法。當知道問題的時候，真是哭笑不得。  >[warning] **NodeBB 1.8.x 之后， 不再使用 uglify-js, 轉而使用 uglify-es。 這意味著所有符合 ES2015 標準的 JS 語法都可以正常使用了。** ## 文檔殘缺 **為什么說 NodeBB 文檔殘缺呢？** 這是一個插件的例子:   看到這些代碼，你覺得怎么樣？ 是不是有點兒頭疼？前面怎么一大堆 `module.parent.require()`， 他們的作用是啥呀？  沒錯，這些就是 NodeBB 庫。是不是在想， 那還不容易， 庫嘛，看文檔抄著用就行。 但是，很不幸，能告訴你這些庫的作用的文檔——并不存在。那么怎么認識他們呢？很簡單，只需要閱讀 NodeBB 源碼即可: https://github.com/NodeBB/NodeBB （手動滑稽） 庫有兩類：一類是核心庫(也就是程序后端使用的)，一類是前端庫（用于 Web 頁面的 js 庫） * 核心庫 : `/src` * 前端庫（公共庫） : `/public/src` 其實，在開發中——上面都不算難點，都是看源碼就能明白的事。 下一環節，理解 NodeBB 中的 Hook 的參數，是你另一個比較艱巨的挑戰。 Hook 提供的了兩個參數：params ， callback 。前者傳參給你，后者用于回調(這種 hook設計 類似于 Express 的 middleware)。 但是，很無奈， NodeBB 給你的 Hook，表面上你只能看到類似于這樣的..(如下圖)  對于第一次使用的 Hook，你需要手動輸出這些參數的內容。才能了解到， 到底參數傳入了什么數據，好做下一步開發。 于是第一個插件， 一開始就出現了大片調試：`console.log(xxx)`（我也是這么過來的) > P.S 有時候就算把參數打印出來了，也不知道那個內容能干嘛（手動滑稽）。 > 解決方法：多斷點，多測試 (無奈) ## Hook 不全 **為什么說 Hook 不全?** 目前 NodeBB Hook List 提供的是 NodeBB 開發團隊認為開發者可能需要的 Hook 。 在實際應用中，很可能會發現你有很多想法，但現有的 Hook 無法為你提供幫助。 比如:  想要在這兩個地方插入些內容....但目前還無 Hook 可以直接實現。 > 目前解決方案 : 使用 Client Script 插入標簽來解決 。 再比如:  依然沒有 Hook 能快速解決問題。 如果必須要實現的話， 依舊需要依靠 Client Script 來定位這個框 以便添加你自定義的列表。 但， NodeBB 開發團隊并不是一個固執的團隊， 如果您需要的 Hook 確實是能夠改善大部分開發者的開發體驗， 或者能解決當前的一些問題的， 他們會十分樂意為你實現。（記得向提交 issue 申請 Hook 哦） ### NodeBB 錯誤消息缺陷 **為什么說 Node.js 錯誤消息有問題？** 這個問題，可以參考 T.J 對于 這個問題的討論。 大致的討論核心是， Node.js 在某些情況下會造成錯誤堆棧丟失或者錯誤定位。 造成難以調試的問題。 一個典型的例子:  這是在 `1.8.2` 進行編寫某插件時， 編譯時錯誤的截圖。 由于錯誤堆棧沒有準確告知我們出錯位置， 所以我們就認為錯誤堆棧已經丟失。 在這種情況下， 有堆棧其實和堆棧沒什么區別不是嗎？ 通常會造成堆棧丟失的情況無非這么幾種: **流(Stream)處理**(字節流，讀寫流等）**套接字(Socket)處理** (其實本質上還是流處理) **回調鏈過長** 盡管 Node.js 經歷多次迭代， 社區也在盡力完善對于這種丟失的處理。很可惜，這種問題依舊存在 (上面的例子， 就是曾經的 LTS 版本 v8.x 觸發的) 由于沒有什么妥善的解決方案，我們只能在編寫時小心小心再小心。我們始終相信，只需要細心，這個問題可能永遠都不會觸發。 >[info] **利用 ES 6 的 Promise 可以幫助你更好得處理回調鏈過長錯誤丟失的問題** > 在 NodeBB 中很多造成丟失堆棧的情況就是回調鏈過長。 令人欣喜的是， 目前 NodeBB 開始逐步向 ES2015/ES6 遷移了。 ## 準備開發 能看到這里，我想都是有一定能力的開發者了。對于上面的問題，都已經有自己想法了。我們很歡迎你加入 NodeBB 的開發者大家庭！NodeBB 目前還是一個比較小眾的群體，所以有這些缺陷也不足為奇。讓我們直面面對這些缺陷，共同塑就 NodeBB 的美好明天吧！  >[info] 編寫: a632079 維護: PA Team 審核: PA Team 最后更新: 2019.12.09