これはチームメンバー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フォルダは、ユーザーのウェブアプリ/サイトファイル用であり、ユーザーが重要です。外部ファイルやサードパーティのファイル用ではありません。ファイルが別の場所に配置されていることをエンドユーザーにとって完全に問題なく（そして透過的ですらある）ようにするのは、ツールの作成者の責任です。ツールに複雑さを処理させ、ユーザーに簡単なワークフローを提供します。
Ruby on Railsにも、すでにこのようなパラダイムが存在しています。RoRが良い例だと言っているわけではありませんが、コミュニティが期待するものであると言うには十分な人気があります。Angularジェネレーターでもしばらく前からこの方法を採用しており、長年にわたって問題や苦情はありませんでした。一部の人は、それがそこに存在するべきだと考えて/appフォルダに移動するプルリクエスト（PR）を送信しようとしますが、それがどのように機能するかを説明すると、一般的に変更に満足しているようです。
ツール
すべてのファイルを参照するターミナルコマンド（`tree`など）を実行するのが困難です。常に`bower_components`を除外する必要があるためです。
外部ライブラリが混在していない場合、/appフォルダでグローバル検索が容易になります。ただし、それに対する反論として
コマンドラインツールから不要なデータを取得する場合、適切に使用するべきです - Peter Müller
これは妥当な点です。これらのファイルを除外するフィルターを設定するのは簡単です。しかし、これは、ツールがユーザーの邪魔にならないようにする点と関連しています。Bowerは別のツールであり、ユーザーのファイルにそのファイルを配置することは、邪魔にならないのではなく、複雑さを増しているのです。
欠点
完璧なものはない（ほとんどない）ため、いくつかの欠点も言及する必要があります。
- ビルド/サーブシステムが必要になります（公式Yeomanジェネレーターによって生成されたものなど）。
反論：Sass/Coffee/Autoprefixer/その他が必要な場合は、おそらくビルドシステムも必要です。そうでない場合、または純粋なフラットサイトが必要な場合は、grunt/gulp/その他のビルドでサイトを構築し、出力されたファイルを使用します。Yeomanは出発点であり、万能のビルドシステム/ワークフローではありません。
- より複雑な構成が必要になります。
反論：Sassにもある程度のセットアップが必要ではありませんか？アセットグラフにもある程度の複雑さが必要ではありませんか？初期設定の複雑さは問題ありません。一度設定すれば、その後はあまり変更されることがないからです。ツールをより賢くして、物事を理解できるようにすれば、構成が不要になる場合もあります（慣習による設定）。
結論
変更のための説得力のある理由をいくつか提供し、反対派の多く、あるいはすべての人を説得できたことを願っています。そうでない場合でも、これは物事を行う唯一の方法ではありません。個々のジェネレーターが異なる方法で物事をしたい場合は、受け入れ可能であり、推奨されることさえあります。新しいことを試みることによって変化が起こり、より良い方法につながることがあります。時には、異なる方法を試みることで元の方法に戻り、それがなぜその方法であったのかをさらに強化することになります。