关闭： - 命名空间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有这个策略的例子。