这是团队成员 Eddie Monge Jr 的一篇帖子
tl;dr 因为我说了算。哈哈，开玩笑的。 /app 应该用于您的文件，而不是第三方库。
关于将 bower_components 文件夹移出 /app 文件夹的决定，已经有一些疑问和讨论。
Matija (silvenon)很好地总结了一些想法
- 我希望
/app文件夹用于用户生成的内容 - 作为外部依赖项，我觉得将它们放在外部更好。在 node_modules 旁边
- 很难在终端中运行任何遍历所有文件的命令（例如 tree），因为您总是必须忽略 bower_components
以下是这些原因逐点说明，并附带一些解释。
用户生成的文件
我希望
/app文件夹用于用户生成的内容
有些人会编辑 /app 文件夹中的文件，然后想知道为什么在执行 bower update/install 时他们的更改会消失。不仅是初学者，还有那些应该知道得更多的人。他们认为“哦，它在 /app 文件夹中，所以我可以自由编辑它，而不用担心”。这就是此更改想要实现的主要预期。
外部依赖项
作为外部依赖项，我觉得将它们放在外部更好。在 node_modules 旁边
这是进行此更改的最大的原因。 /app 应该用于用户的 Web 应用程序/网站文件，重点是用户。它不应该用于外部或第三方文件。工具作者有责任使将文件放在其他位置对最终用户完全无痛（甚至透明）。让工具处理复杂性，并为用户提供简单的流程。
Ruby on Rails 中已经存在这种范例。并不是说 RoR 是一个好的遵循示例，但它足够流行，可以说明这是社区期望看到的。它也已经在 Angular 生成器 中存在一段时间了，而且很长时间以来都没有出现过问题或投诉。有些人试图提交 PR（拉取请求）将其移到 /app 文件夹中，因为他们认为它应该在那里，但是当指出它是如何工作时，他们通常似乎对更改感到满意。
工具
很难在终端中运行任何遍历所有文件的命令（例如 tree），因为您总是必须忽略 bower_components
当 /app 文件夹没有被外部库弄乱时，更容易在其中进行全局搜索。尽管与此相反的是
如果您的命令行工具为您提供了不需要的数据，我会说您应该正确使用它们 - Peter Müller
这是一个有效的观点。设置一个过滤器来排除这些文件很容易。但这与工具应该避开用户这一观点是一致的。Bower 是另一个工具，让它将文件放在用户文件中并不是避开用户，而是在增加复杂性。
缺点
没有什么是完美的（好吧，几乎没有），所以应该提到一些缺点。
- 需要构建/服务系统才能工作（例如官方 Yeoman 生成器生成的系统）。
反驳：如果需要 Sass/Coffee/Autoprefixer/任何其他内容，那么可能也需要构建系统。如果不是，或者如果需要纯平面站点，那么 grunt/gulp/任何构建 站点并使用输出文件。Yeoman 应该是一个起点，而不是最终的构建系统/工作流程。
- 需要更多配置复杂性。
反驳：Sass 不需要一些设置吗？asset-graph 不需要一些复杂性吗？初始设置中的复杂性并不好，因为一旦配置完成，它通常不会在以后发生太大或频繁的更改。也可以让工具更智能地找出问题所在，因此可能甚至不需要配置（约定优于配置）。
结论
希望已经为更改提供了一些令人信服的原因，并说服了一些（如果不是全部）反对者相信更改的明智性。如果不是，那么这种更改并不是唯一的做事方式。如果某个单独的生成器想要以不同的方式做事，这是可以接受的，如果不是鼓励的话。尝试新事物是变化发生的方式，有时会导致更好的做事方式。有时尝试不同的方法会让你回到最初的方法，并进一步强化它最初是那样的原因。