熱血漢誌 - 技術新鮮人到技術經理人，必懂的事

npm i fail - 查不出原因的處理方式 經歷許多次的 npm 安裝問題，目前有幾種不同的解法。 npm cache issue 可能因為 npm 下載的時候，或者因為連線問題導致模組並沒有完整被安裝，但是 npm 的檢查機制就是只要存在就會跳過安裝步驟，因此當遇到安裝完成，但是執行卻無法的時候，可以嘗試著 rm -rf node_modules # install again npm i 如果是在中間就遇到 fail 的狀態，有可能是因為之前連線問題，並沒有將模組安裝成功，但是資料已經存在 npm cache 資料夾裡面，以往都需要找出這個環境設定，環境路徑才能進行移除，不過現在透過 npm cache 可以簡單做到這件事情 npm cache clean rm -rf node_modules npm i npm version issue 另外一種會再安裝的時候跳出錯誤，會顯示為 npm 版本不符合，或者是 node 版本不符合，這個時候就需要進行安裝更新，最簡單方式就是升級 npm . npm i -g npm 缺少套件 通常最常見的就是有些模組需要透過 gcc, g++ 這是最常見的缺少模組問題，以 mac 環境來說直接透過 brew 就可以安裝完成。 brew install gcc brew install g++ # install again npm i 記憶體不足 最後一種就是屬於記憶體不足的狀態，這通常會很難檢查，實際上 npm 也會跳出錯誤，現在的錯誤資訊都已經比較明顯， npm ERR! node v4.4.1 npm ERR! npm v3.8.6 npm ERR! code ENOMEM npm ERR! errno ENOMEM npm ERR! syscall spawn npm ERR! spawn ENOMEM 如果遇到這種狀況，請重新調整記憶體分配，如果是採用 vps, 就看能不能夠 scale up ，讓機器的記憶體提升，就可以解決問題。 後記 以上都是踩過的雷，以及在嘗試許多 node.js 專案時會遇到的問題，我們也經常在摸索中，不過從摸索以及找到答案的過程都繞了許多遠路，希望透過分享可以讓大家更瞭解 npm 錯誤時可以怎麼處理。

JavaScript 物件中快速檢查屬性 在我們一般使用 function 或者呼叫某些 api 的時候特別需要去驗證，某些值是否已經存在，或者使用者有沒有忘記傳入哪些數值進來。 為了要做這件事情，通常我們會寫一堆 if 去判斷每個值有沒有出現問題。 if(!formData.name){ return reject("Parameter 'name' is required"); } if(!formData.size){ return reject("Parameter 'size' is required"); } if(!formData.sizeUnit){ return reject("Parameter 'sizeUnit' is required"); } if(!formData.width){ return reject("Parameter 'width' is required"); } 實際上透過 lodash 可以讓這件事情非常快速完成。 let _ = import 'lodash'; let result = _.has(object, ['name', 'size', 'sizeUnit', 'width']); if (result) return reject("Parameter is not correct"); 後記 雖然說並不是太困難的程式，但是透過套件真的可以讓程式碼短少一點，讓我們程式透過 import / require 將模組載入，讓程式碼更短。 short code is best code

Express.js 的黑歷史及 Express 未來 4/5 更新 ， 根據讀者回饋，目前 IBM 已將 Express 及相關所有權轉移到 Node.js 基金會手中，讓 Node.js 社群能夠投入資源。 https://nodejs.org/en/blog/announcements/foundation-express-news/ Express.js （以下簡稱為 Express）相信如果有在開發 node.js 程式的人肯定不陌生，幾乎是開發 Web 應用上手的第一堂課程，而 Express 至今已經四年左右的時間，幾乎是從 Node.js 0.4 版本時期就開始有（憑藉著印象，如果有錯請大家指正），當然這當中必定要讚嘆一下，神人 - TJ （拱手作揖）。 而在 Node.js 與 io.js 的戰爭時期， TJ 也宣布將 express 釋出，最後是轉換到 StrongLoop 公司底下，全權交給 StrongLoop （包含網域名稱， Express.js 以及 github reps 的所有權），當然這中間 TJ 肯定有協調些什麼，以及與其他 contributor 。 使用 Express 不可不知的人物， Douglas Wilson ，他是在 TJ　離開 Express 幾乎所有 reivew, issue, merge 都會經過 Doug 的手中 但是燃火線在於 Express.js 4 -> 5 的這段時間， StrongLoop 被 IBM 買走，但是也因為 Express 是一個很龐大的生態系統，以及對於 node.js web 開發是一個影響許多的 open source project ，而在這段時間中， Douglas Wilson 因為某些事情憤而離開 Express 組織中。 這才真正引爆了大家對於 StrongLoop, 及 IBM 的不滿。 黑歷史重點回顧 TJ 將 Express 名字及所有內容轉移到 StrongLoop StrongLoop 並沒有指定或者對於 Express 有任何大量持續性維護 只有 Douglas Wilson 及其他志願者持續維持整個 Express 專案的進度 StrongLoop 在這之後宣稱自己有所有權管理 Express ，