闭包:--namespace Foo不包括Foo.Bar和相关问题 [英] Closure: --namespace Foo does not include Foo.Bar, and related issues

问题描述

我有一个相当大的库，其中包含需要公开的大量API.实际上，我想展示整个过程.有很多命名空间，例如:

I have a rather big library with a significant set of APIs that I need to expose. In fact, I'd like to expose the whole thing. There is a lot of namespacing going on, like:

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

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

基本上，我想做的是确保用户可以访问整个命名空间.我在这方面遇到了很多麻烦，而我对封闭完全陌生，所以我想请教一下.

Basically, what I would like to do is make sure that the user can access that whole namespace. I have had a whole bunch of trouble with this, and I'm totally new to closure, so I thought I'd ask for some input.

首先，我需要closurebuilder.py来将文件的完整列表发送给closure编译器.似乎不支持此功能:--namespace Foo不包含Foo.Bar. --input仅允许单个文件，而不允许目录.我也不能直接将文件列表直接发送到闭包编译器，因为我的代码还需要"goog.assers"之类的东西，因此我确实需要解析器.

First, I need closurebuilder.py to send the full list of files to the closure compiler. This doesn't seem supported: --namespace Foo does not include Foo.Bar. --input only allows a single file, not a directory. Nor can I simply send my list of files to the closure compiler directly, because my code is also requiring things like "goog.assers", so I do need the resolver.

事实上，我唯一能看到的解决方案是拥有一个FooLibrary.ExposeAPI JS文件，该文件具有@require的所有内容.肯定不对吗?

In fact, the only solution I can see is having a FooLibrary.ExposeAPI JS file that @require's everything. Surely that can't be right?

这是我的主要问题.

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

However, later the closure compiler, with ADVANCED_OPTIMIZATIONS on, will optimize all these names away. Now I can fix that by adding "@export" all over the place, which I am not happy about, but should work. I suppose it would also be valid to use an extern here. Or I could simply disable advanced optimizations.

我显然不能做的是说导出FooLibrary.*".那没有道理吗?

What I can't do, apparently, is say "export FooLibrary.*". Wouldn't that make sense?

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

Finally, for working in source mode, I need to do goog.require() for every namespace I am using. This is merely an inconvenience, though I am mentioning because it sort of related to my trouble above. I would prefer to be able to do:

goog.requireRecursively('FooLibrary')

goog.requireRecursively('FooLibrary')

以便同时提取所有子命名空间；因此，使用我的库的编译版本时，只需一个命令即可重新创建我所拥有的环境.

in order to pull all the child namespaces as well; thus, recreating with a single command the environment that I have when I am using the compiled version of my library.

我觉得我可能对某些事情有误解，或者应该如何使用Closure.我会对其他基于Closure的库感兴趣，以了解它们如何解决此问题.

I feel like I am possibly misunderstanding some things, or how Closure is supposed to be used. I'd be interested in looking at other Closure-based libraries to see how they solve this.

推荐答案

您发现Closure-compiler的构建更多是针对最终用户的，而不是针对库作者的.

You are discovering that Closure-compiler is built more for the end consumer and not as much for the library author.

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

If you are exporting basically everything, then you would be better off with SIMPLE_OPTIMIZATIONS. I would still highly encourage you to maintain compatibility of your library with ADVANCED_OPTIMIZATIONS so that users can compile the library source with their project.

首先，我需要closurebuilder.py来将文件的完整列表发送给closure编译器. ...

First, I need closurebuilder.py to send the full list of files to the closure compiler. ...

事实上，我唯一能看到的解决方案是拥有一个FooLibrary.ExposeAPI JS文件，该文件具有@require的所有内容.肯定不对吗?

In fact, the only solution I can see is having a FooLibrary.ExposeAPI JS file that @require's everything. Surely that can't be right?

您将需要指定源文件夹的--root并指定文件依赖关系树的叶节点的名称空间.现在不推荐使用的 CalcDeps.py 脚本可能会让您好运.我仍然将其用于某些项目.

You would need to specify an --root of your source folder and specify the namespaces of the leaf nodes of your file dependency tree. You may have better luck with the now deprecated CalcDeps.py script. I still use it for some projects.

我显然不能做的是说导出FooLibrary.*".那没有道理吗?

What I can't do, apparently, is say "export FooLibrary.*". Wouldn't that make sense?

您不能这样做，因为它仅根据最终用途才有意义.作为库编写者，您希望导出所有内容，但是也许库的使用者希望包含源(未编译)版本并消除更多无效代码.图书馆作者被困在SIMPLE和ADVANCED优化级别之间的中间地带.

You can't do that because it only makes sense based on the final usage. You as the library writer wish to export everything, but perhaps a consumer of your library wishes to include the source (uncompiled) version and have more dead code elimination. Library authors are stuck in a kind of middle ground between SIMPLE and ADVANCED optimization levels.

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

What I have done for this case is maintain a separate exports file for my namespace that exports everything. When compiling a standalone version of my library for distribution, the exports file is included in the compilation. However I can still include the library source (without the exports) into a project and get full dead code elimination. The work/payoff balance of this though must be weighed against just using SIMPLE_OPTIMIZATIONS for the standalone library.

我的 GeolocationMarker库提供了此策略的示例.

My GeolocationMarker library has an example of this strategy.

这篇关于闭包:--namespace Foo不包括Foo.Bar和相关问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！