關閉： - 命名空間Foo不包括Foo.Bar和相關問題

Question

我有一個相當大的庫，其中包含一組重要的API，我需要公開它們。事實上，我想揭露一切。這裏是怎麼回事了很多命名空間，如：

FooLibrary.Bar FooLibrary.Qux.Rumps FooLibrary.Qux.Scrooge ..

基本上，我想要做的是確保在用戶可以訪問整個名稱空間。我在這方面遇到了很多麻煩，而且我完全不熟悉閉包，所以我想我會要求一些輸入。

首先，我需要closbuilder.py將完整的文件列表發送給閉包編譯器。這似乎並不支持：--namespace Foo不包含Foo.Bar。 - 輸入只允許一個文件，而不是一個目錄。我也不能直接將我的文件列表發送給閉包編譯器，因爲我的代碼也需要諸如「goog.assers」之類的東西，所以我確實需要解析器。

實際上，我能看到的唯一解決方案是擁有一個FooLibrary.ExposeAPI JS文件，它需要所有的東西。當然，這不可能是正確的？

這是我的主要問題。

但是，稍後，使用ADVANCED_OPTIMIZATIONS的閉包編譯器將優化所有這些名稱。現在我可以通過在所有地方添加「@export」來解決這個問題，我不喜歡它，但應該可以工作。我想在這裏使用extern也是有效的。或者我可以簡單地禁用高級優化。

我不能做的顯然是說「export FooLibrary。*」。這不合理嗎？

最後，爲了在源模式下工作，我需要爲我使用的每個名稱空間執行goog.require()。這只是一個不便之處，雖然我提到了，因爲它與我上面的麻煩有關。我寧願能夠做到：

goog.requireRecursively（「FooLibrary」）

爲了把所有的孩子命名空間爲好;因此，使用單個命令重新創建當我使用我的庫的編譯版本時所具有的環境。

我覺得我可能會誤解一些事情，或者應該如何使用Closure。我有興趣查看其他基於Closure的庫來了解它們如何解決這個問題。

Answer 1

您在發現Closure編譯器是爲最終用戶構建的，而不是爲圖書館作者編寫的。

如果您正在導出基本所有內容，那麼使用SIMPLE_OPTIMIZATIONS會更好。我仍然強烈建議您保持庫與ADVANCED_OPTIMIZATIONS的兼容性，以便用戶可以使用他們的項目編譯庫源代碼。

首先，我需要closbuilder.py將完整的文件列表發送給閉包編譯器。 ...

實際上，我可以看到的唯一解決方案是擁有一個FooLibrary.ExposeAPI JS文件，它是@ require的一切。當然，這不可能是正確的？

您需要指定源文件夾的--root並指定文件依賴關係樹的葉節點的命名空間。對於現在已棄用的CalcDeps.py腳本，您可能會有更好的運氣。我仍然在一些項目中使用它。

我不能做的顯然是說「export FooLibrary。*」。這不合理嗎？

你不能這樣做，因爲它只是基於最終用法纔有意義。您作爲圖書館作者希望導出所有內容，但是您的圖書館的使用者可能希望包含源代碼（未編譯）的版本，並刪除更多的代碼。圖書館作者被困在SIMPLE和ADVANCED優化級別之間的中間地帶。

我爲這種情況所做的事情是爲我的命名空間維護一個單獨的導出文件，用於導出所有內容。編譯用於分發的獨立版本的庫時，導出文件包含在編譯中。不過，我仍然可以將庫源代碼（不包括導出）包含到項目中，並且可以完全清除死代碼。這一點的工作/收益平衡必須權衡使用獨立庫的SIMPLE_OPTIMIZATIONS。我的GeolocationMarker library有這個策略的例子。