與一些傳言相反，Lodash依然活躍，并正在邁向Lodash 5的發布！

Lodash 是那些為 JavaScript 提供便利功能的實用程序庫之一，它使編程變得更加輕松。許多開發者使用它來簡化對象和數組的處理。

它也是一個像 Moment.js那樣被捕獲得措手不及的庫。由于沒有模塊化，它從一些項目中被丟棄，因為當你加載5MB的分析工具時，每多1kB的負擔都太大了。

我偶爾使用 Lodash，因為它很有用，并且我發現它很有幫助。但驚訝地發現了Daniel Roe的這條推文：

必須讀兩次，因為僅僅瀏覽這條推文會讓你相信 Lodash 已經死亡。

實際上，Daniel 寫道在他發那條推文時沒有新的問題反饋。

但你可以從推文中感受到對 Lodash 的一些反感，因為它的措辭暗示著 Lodash 已經死亡。

在隨后的推文中，他澄清說沒有問題反饋可能是為了準備發布Lodash 5：

為什么我們會看到關于這個流行庫的如此模糊的推文？

我發現的是，原計劃在2021年發布 Lodash 5。

然而，現在是2023年，Lodash 5 的發布已經延遲了兩年。該版本的更改清單非常重要，主要側重于減小大小和模塊化，這些問題使得Lodash在一些團隊中逐漸沉沒。

所以，這個路線圖非常明確，當Lodash 5發布時，它將能夠再次展現它的真正用途。

我不知道為什么它會延遲。但有時這種情況確實會發生。沒什么大不了的。沒有理由不喜歡它。

然后，作者偶然發現了這個關于省略函數的主題。Omit 函數是刪除對象不必要屬性的一種方法。它的用處在于可以一次刪除多個屬性，還可以刪除深層屬性，例如 car.tires.size。

為了準備這些對意外數據過敏的API端點的數據，這非常方便。

但是，根據路線圖，Lodash 5 將取消這一功能。看起來對于一些人來說，這真的很重要。但是，五年前，這成為了設計決策的一部分，開發者被告知他們對此沒有發言權：

并說明原因：

它必須引入所有屬性（繼承的和自己的可枚舉字符串鍵屬性和符號），然后排除少量屬性。另一方面，_.pick 或 _.pickBy 是顯式的。只需選擇你想要的內容，無需大費周章。

我不知道這是不是反感的來源，但肯定有一些開發者不喜歡這個實用程序庫決定他們應該如何編碼。

羅伯特-登普西（Robert Dempsey）撰寫了一篇很棒的文章，對 omit 功能的所有可能替代方案進行了分析，得出如下結論：

如果你需要省略扁平路徑， 建議安裝Lodash 4+單獨用于省略功能，同時使用Lodash 5+進行其他操作。

Robert 所做的研究得出的結論確實很有根據。這讓我們得出的結論是使用pick，或pickBy，或者在Lodash 5發布時安裝兩個版本的Lodash。

盡管我們知道選擇屬性與刪除它們不同。因為對于大型對象，選擇是逆生產的。

總之，一些開發者，一些忠實的Lodash開發者，將不得不安裝兩個版本，因為一個設計決策。

我還了解到，omit 功能的運行速度很慢，這可能是刪除該功能的原因。

Robert 所做的研究顯示了一些有前途的替代方案。但也明確表示，這個功能對于人們來說是有用的。所以，即使它不是超級快，對于人們來說也足夠了。

當我處理一個數據時，我不太關心它多用了1毫秒，因為我知道調用API的時間都要花費500毫秒。??

另一方面，在某些情況下可能會太慢，但這就是性能測試的任務。

不過，作者也理解當今方正公司規則的設計決定。在這種情況下，因為有人可能會錯誤地使用一個函數而放棄一個庫，或者干脆放棄這個函數，都比解釋如何正確使用它要容易得多。

作者也理解這個決定可能是基于需要優化庫在所有情況下的運行速度和推廣最佳實踐，同時與實用性保持良好的平衡。

說了這么多，這只說明在受歡迎的庫周圍做決策是多么的棘手。不能讓每個人都滿意。

作者個人會保留這個功能，并盡量提高其速度，同時在文檔中添加一些說明。

無論如何，事實上，Lodash團隊實際上使用了“Issue bankruptcy”標簽來描述已關閉的問題。

Lodash仍然活躍，有一天我們會看到Lodash 5，這是許多開發者期待的東西。