Polymer Web组件应该放在哪里？

对于我来说，这是一个关于Web组件的大问题；Web组件的承诺是，它们是通用的可重用组件，任何人都可以使用；最终能够创建和重新混合web组件，构建自己的应用程序，并接受现有的应用程序

然而，如何实现这样一个愿景是一个大问题，例如：

我们有一个应用程序的想法，我们为应用程序创建一个repo，我们在应用程序repo中创建web组件

我们有一个应用程序的想法，我们为应用程序创建一个github组织，我们为每个web组件创建一个repo

选项1似乎可以减少大部分开销，但会增加碎片数量，降低可发现性，并阻碍新贡献者加入（因为他们现在面临的是整个应用程序，而不仅仅是web组件）

选项2似乎会增加开销，但会减少碎片的数量，同时提高web组件的可发现性和贡献者启动并运行web组件的能力，因为一组维护人员可以一起维护相同的web组件

不过。选项1虽然增加了碎片化，但它似乎更好地适应了web组件随时间的演变，而选项2则会看到大量弃用的组件，支持在开发过程中开发更好的组件

不过。然而，社区一致的反对要比公司分裂好，这一事实可能与上述观点相悖。例如，最好使用a、b和c，web组件中c是最新的。而不是拥有，1-a公司，2-a公司，3-a公司，所有这些公司都得到维护

那么，在实现web组件的同时，如何在实现它们之间找到一个良好的平衡点呢？

决定哪些组件应该是可重用的 您应该从组件级别而不是应用程序级别来考虑它。如果你有有用的应用程序功能，它很可能会被分解成一个组件。在这一点上，是否将组件提供给其他人是作者的选择。在某些情况下，共享组件是没有意义的（例如，它们特定于应用程序）。对于应该共享的组件，聚合物团队支持您的#2

每个组件一份回购协议 如果您愿意，每个组成部分都在单独的回购协议中。其理念是用户可以轻松安装单个元素，按单点：

bower install Polymer/core-ajax

获得您所需要的是web组件的一个承诺

高粒度的权衡：开销 高粒度带来的代价是：开销。作为组件作者，这是我们愿意承担的。在我看来，消费者的灵活性远远超过了我们作为作者所承担的维护

从多个repo创建组件集 请记住，大多数人不会创建数百个元素。他们只会创造一些。对于供应商来说，创建一个聚合一组组件的shell repo并不十分困难。例如，可以使用单个Bower命令安装所有ou：

bower install Polymer/core-elements

---

依赖项由Bower为我们管理。每个组件repo都维护自己的依赖项列表

感谢您的回复，这很有趣，因为这似乎高度依赖bower和bower的约束（每个bower套餐的回购协议）。当使用另一个包管理器（例如component.io或npm，或者不使用包管理器而直接使用html导入）时，您将很有兴趣了解这种方法的不同之处。