闭包：--namespace Foo 不包含 Foo.Bar，以及相关问题

Question

我有一个相当大的库，其中包含大量需要公开的 API。事实上，我想揭露整个事情。有很多命名空间，例如：

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

基本上，我想做的是确保用户可以访问整个命名空间。我遇到了一大堆麻烦，而且我对关闭完全陌生，所以我想我会征求一些意见。

首先，我需要closurebuilder.py 将完整的文件列表发送到闭包编译器。这似乎不受支持：--namespace Foo 不包括 Foo.Bar。 --input 只允许单个文件，而不是目录。我也不能简单地将我的文件列表直接发送到闭包编译器，因为我的代码也需要像“goog.assers”这样的东西，所以我确实需要解析器。

事实上，我能看到的唯一解决方案是拥有一个 FooLibrary.ExposeAPI JS 文件，@require 是一切。这肯定不对吧？

这是我的主要问题。

但是，稍后关闭 ADVANCED_OPTIMIZATIONS 的闭包编译器将优化所有这些名称。现在我可以通过在整个地方添加“@export”来解决这个问题，我对此并不满意，但应该可以。我想在这里使用 extern 也是有效的。或者我可以简单地禁用高级优化。

显然，我不能说“导出 FooLibrary.*”。这不是有道理吗？

最后，为了在源代码模式下工作，我需要为我正在使用的每个命名空间执行goog.require()。这只是一个不便，尽管我提到它是因为它与我上面的麻烦有关。我希望能够做到：

goog.requireRecursively('FooLibrary')

为了拉取所有子命名空间；因此，使用单个命令重新创建我在使用库的编译版本时所拥有的环境。

我觉得我可能误解了一些事情，或者应该如何使用 Closure。我有兴趣查看其他基于闭包的库，看看它们是如何解决这个问题的。

Answer 1

您发现 Closure-compiler 更多地是为最终消费者构建的，而不是为库作者构建的。

如果您基本上要导出所有内容，那么使用 SIMPLE_OPTIMIZATIONS 会更好。我仍然强烈建议您保持库与 ADVANCED_OPTIMIZATIONS 的兼容性，以便用户可以使用他们的项目编译库源代码。

首先，我需要closurebuilder.py 将完整的文件列表发送到闭包编译器。 ...

事实上，我能看到的唯一解决方案是拥有一个 FooLibrary.ExposeAPI JS 文件，@require 是一切。这肯定不对吧？

您需要指定源文件夹的--root 并指定文件依赖关系树的叶节点的命名空间。现在已弃用的 CalcDeps.py 脚本可能会让您的运气更好。我仍然在一些项目中使用它。

显然，我不能说“导出 FooLibrary.*”。这不是有道理吗？

您不能这样做，因为它仅根据最终使用情况才有意义。作为库编写者，您希望导出所有内容，但您的库的使用者可能希望包含源（未编译）版本并消除更多死代码。库作者陷入了一种介于简单和高级优化级别之间的中间地带。

我为这个案例所做的是为我的命名空间维护一个单独的导出文件，该文件导出所有内容。在编译我的库的独立版本以进行分发时，导出文件包含在编译中。但是，我仍然可以将库源（没有导出）包含到项目中并完全消除死代码。但是，必须权衡仅使用 SIMPLE_OPTIMIZATIONS 独立库的工作/收益平衡。

我的GeolocationMarker library 有一个这种策略的例子。