0

我有一个相当大的库，其中包含大量需要公开的 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。我有兴趣查看其他基于闭包的库，看看它们是如何解决这个问题的。

4

1 回答 1

2

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

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

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

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

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

显然，我不能说“导出 FooLibrary.*”。那没有意义吗？

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

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

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

于 2013-08-28T18:26:59.947 回答