這是團隊成員 Eddie Monge Jr 的一則貼文
重點摘錄：因為我是負責人。哈哈，開玩笑的。/app 應只能用於你的檔案，而非第三方程式庫。
對於將 bower_components 資料夾移至 /app 資料夾外部的決定已造成一些疑問與討論。
Matija (@silvenon) 精闢地整理了一些想法：
- 我希望
/app資料夾能用於使用者產生的素材。 - 由於是外部相依性，我覺得將它們放置在外部位置會較為理想。位於
node_modules旁。 - 由於你總是必須忽略
bower_components，因此很難在終端機中執行任何需要掃描所有檔案的指令（例如目錄樹）。
以下針對這些理由逐點說明。
使用者產生檔案
我希望
/app資料夾能用於使用者產生的素材。
有些人會在 /app 資料夾中編輯檔案，然後奇怪為何他們變動的部分會在執行 bower update/install 時消失。不僅是初學者，也包括一些應該更了解的人。他們認為：「哦，它在 /app 資料夾中，因此不用擔心就能隨意編輯。」這是這次變更希望實現的主要預期結果。
外部相依性
由於是外部相依性，我覺得將它們放置在外部位置會較為理想。位於
node_modules旁。
這是促成這次變更最大的單一原因。/app 應專用於使用者的網站/應用程式檔案，重點在於使用者。它不應專用於外部或第三方檔案。工具作者有責任讓將檔案放置在其他位置這件事對最終使用者而言完全無感（甚至透明）。讓工具處理複雜性，並提供使用者友善的工作流程。
這種範例已存在於 Ruby on Rails 中。我不是說 RoR 是值得效仿的好範例，但它夠普及，足以為業界預期提供參考。它也在 @yeoman/generator-angular 產生器中沿用了好一段時間，於此同時，並沒有人提出問題或抱怨。有些人試圖透過公關請求將它移回 /app 資料夾，因為他們認為它應該在這裡，但當有人指出它的運作方式時，他們通常會對變更感到滿意。
工具
由於你總是必須忽略
bower_components，因此很難在終端機中執行任何需要掃描所有檔案的指令（例如目錄樹）。
當 /app 資料夾內沒有外部程式庫時，便於執行全域搜尋。然而，反駁的說法是：
如果你的命令列工具提供你不需要的資料，我會建議你適當地使用它們 - Peter Müller。
這是一個有效的觀點。排除這些檔案很容易，只需設定一個篩選器即可。但這與工具應該遠離使用者的觀點一致。 Bower 是另一個工具，將它的檔案放入使用者檔案中並非遠離其道，而是增加了複雜性。
缺點
沒有什麼是完美的（或幾乎沒有），因此應該提到一些缺點。
- 需要建構/服務系統才能運作（例如官方 Yeoman 建構器產生的系統）。
反駁論點：如果需要 Sass/Coffee/Autoprefixer/等其他工具，那麼可能無論如何都需要一個建構系統。如果不是這樣，或如果需要純平面網站，那麼grunt/gulp/任何建構網站並使用輸出檔案。 Yeoman 應該是起點，而不是唯一的建構系統/工作流程。
- 需要更多配置複雜性。
反駁論點：Sass 不需要設定嗎？資產圖表不要求一些複雜性嗎？在初始設定中的複雜性並非壞事，因為一旦配置完成，它通常不會有太大改變或在之後經常改變。這些工具也可以變得更聰明，用於找出問題，因此可能不需要設定（慣例優於設定）。
結論
希望提供了一些令人信服的理由來進行變更，並讓一些（即使不是全部）反對者信服變更的明智之處。如果不是，那麼這個變更並不是做事的唯一方法。如果個別建構器想要以不同方式做事，那是可以接受的，如果不是鼓勵的話。嘗試新事物是變更發生並且有時可以帶來更好的做事方法。有時嘗試不同的方法會帶你回到原始方法，並進一步加強為什麼它一開始就是這樣的方法。