我有一个相当大的库，其中包含一系列我需要公开的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也是有效的。或者我可以简单地禁用高级优化。
显然，我不能做的是“export FooLibrary。*”。这有道理吗？
最后，对于在源模式下工作，我需要为我正在使用的每个命名空间执行goog.require()。这只是一个不便，虽然我提到因为它与我上面的麻烦有关。我更愿意这样做：
goog.requireRecursively（ 'FooLibrary'）
以便拉出所有子命名空间;因此，使用单个命令重新创建我使用库的编译版本时所具有的环境。
我觉得我可能误解了一些事情，或者应该如何使用Closure。我有兴趣看看其他基于Closure的库，看看他们如何解决这个问题。
答案 0 :(得分：2)
您发现Closure编译器是为最终消费者构建的，而不是为库作者构建的。
如果你基本上都在出口所有东西，那么你最好使用SIMPLE_OPTIMIZATIONS。我仍然强烈建议您保持库与ADVANCED_OPTIMIZATIONS的兼容性，以便用户可以使用他们的项目编译库源。
首先，我需要closurebuilder.py将完整的文件列表发送到闭包编译器。 ...
事实上，我能看到的唯一解决方案是拥有一个FooLibrary.ExposeAPI JS文件，@ require是一切。当然这不可能是对的吗？
您需要指定源文件夹的--root并指定文件依赖关系树的叶节点的命名空间。对于现已弃用的CalcDeps.py脚本，您可能会有更好的运气。我仍然将它用于某些项目。
显然，我不能做的是“export FooLibrary。*”。这有道理吗？
你不能这样做，因为它只根据最终用法才有意义。您作为图书馆作者希望导出所有内容，但也许您的图书馆的消费者希望包含源（未编译）版本并消除更多死代码。图书馆作者在SIMPLE和ADVANCED优化级别之间处于中间地位。
我为此案例所做的是为我的命名空间维护一个单独的导出文件，导出所有内容。在编译我的库的独立版本以进行分发时，导出文件包含在编译中。但是，我仍然可以将库源（没有导出）包含到项目中，并获得完整的死代码消除。必须权衡这个工作/支付余额，而不是仅使用单独库的SIMPLE_OPTIMIZATIONS。
我的GeolocationMarker library就是这个策略的一个例子。