[@nuxt/components] ディレクトリ整理がらみ

[mcdmaster]

改善詳細 / Details of Improvement

• こちら、あるいは #5404 あたりにある、コンポーネント・ディレクトリの構造化に向けた議論の助けになるかもしれない @nuxt/components についての気づきです。メモがてらに書いてみました
• なお、上記イシューや PR では、インポートの完全自動化を目指す @nuxt/components のメリットを尊重しつつも、我々が書くコードの視認性や可読性の向上のために明示的に import 句を書く必要があるという点にも言及されています。原則、私もその方針に賛成です
• とはいえ、こと選択と集中という意味では、おおよそ完全に共通なものは @nuxt/components のような仕組みで隠匿化するのもアリと、個人的には考えています

スクリーンショット / Screenshot

スクショではないですけれども、今、 @nuxt/components を使い下記のような実験をしています。

• チャート系で特にリファレンスされやすい vue ファイルや（components/AppLink.vue などを想定）、複数個所での実装が認められる ScaleLoader (vue-spinner) のインポートを、 一か所にまとめる。まとめ先は nuxt.config.ts を想定
• nuxt.config.ts への集中が叶わないときは、特にチャート系は装飾的アピアランスの役に立つコンポーネントの定義場所として layouts/default.vue の使用を検討する
• それでもなお、様々な制約条件のために layouts/default.vue の使用が叶わないときは、せめて一階層上にあるアプリでのコンポーネント定義を試みる（comonents/ScrollableChart.vue などを想定）

期待する見せ方・挙動 / Expected behavior

• 残念ながら、以下で私がポストしたようなエラーを報告する羽目になっている現状です https://github.com/nuxt/components/issues/195
• ロジックを直すか、あるいはもしかしたら eslint の特殊ルール（？）で逃げられないか、考え中です
• 既に @nuxt/components は nuxt 本体（？）にもオーソライズされている 立場でありながら、vue 本体とルールが矛盾するときの解決策が示されていないとしたら、個人的には承服できません
• ご参考 https://nuxtjs.org/blog/improve-your-developer-experience-with-nuxt-components/

動作環境・ブラウザ / Environment

• macOS / Windows / Linux / iOS / Android
• Chrome / Safari / Firefox / Edge / Internet Explorer