对于Web组件，这是一个很大的问题; Web组件的承诺是，它们应该是任何人都可以使用和运行的通用可重用组件;最终能够创建和重新混合Web组件以构建自己的应用程序并使用现有的应用程序。
但是，如何实现这样一个愿景的最大问题是：
我们有应用创意，我们为应用创建了一个回购，我们在app repo中创建了Web组件
我们有一个应用程序的想法，我们为应用程序创建了一个github组织，我们为每个Web组件创建一个repo
选项1似乎可以减少最多的开销，但会增加碎片数量，降低可发现性，并阻碍新的贡献者加入（因为他们现在面对的是整个应用程序，而不仅仅是Web组件）
选项2似乎会增加开销，但会减少碎片数量，同时提高Web组件的可发现性以及贡献者启动和运行Web组件的能力，因为维护人员团队可以保持相同网络组件在一起。
然而。选项1虽然增加了碎片，但似乎随着时间的推移更好地迎合了Web组件的发展，而选项2会看到许多不赞成使用的组件，有利于在开发过程中后期开发的更好的组件。 / p>
然而。然而，上述情况可能与社区同意弃用比公司分散更好的事实相抵消。例如。最好有a，b和c，web组件，c是最新的。比拥有，company1-a，company2-a，company3-a，所有这些都得到维护。
那么在实现Web组件的同时实现它们的良好平衡的同时，实现Web组件承诺的方法是什么？
答案 0 :(得分：6)
您应该从组件级别而不是应用级别考虑它。如果您的应用功能非常有用，则可能会将其纳入组件中。此时，作者是否可以选择将该组件提供给其他人。对于某些情况，共享组件没有意义（例如，它们是特定于应用程序的）。对于应该可共享的组件，Polymer团队会接受您的＃2。
如果您look at Polymer's org，则每个组件都在一个单独的仓库中。这个想法是用户可以轻松安装单个元素，点菜：
bower install Polymer/core-ajax
获取您需要的是Web组件的一个承诺。
高粒度需要付出代价：开销。作为组件作者，这是我们愿意承担的事情。 IMO，消费者的灵活性大大超过了我们作为作者所承担的维护。
请记住，大多数人不会创造数百个元素。他们只会创造一些。对于供应商而言，创建聚合一组组件的shell repo并不是非常困难。例如，所有ou core-elements都可以使用单个Bower命令安装：
bower install Polymer/core-elements
Bower为我们管理依赖关系。每个组件repo都维护自己的依赖项列表。