Vscode: ファイルのネスト

fyi @bpasero

このための最も理想的なシナリオは、親ファイルと同じテキストで始まり、拡張子を除いたものが次のようにネストされることです。

File1.cs
--- File1.File2.cs
--- File1.File3.cs
------ File1.File3.File4.cs

現時点では計画はありません。 これを再考するまで締めくくります。

これは、大規模なプロジェクトにとって重要な機能です。 Angularプロジェクトにasp.netvNextを使用していますが、構造を自動的に（名前を付けて）フォローしています。

--app.component.ts
----app.component.ts.sass
----app.component.ts.html
--login.component.ts
----login.component.ts.sass
----login.component.ts.html

VS Code Explorerで、次のようになりました。

--app.component.ts
--app.component.ts.sass
--app.component.ts.html
--login.component.ts
--login.component.ts.sass
--login.component.ts.html

コンポーネントごとにフォルダーを作成することは、Angularプロジェクトにとって悪い解決策です（参照を変更する必要があります）。

VS Codeに移行するには、この機能が必要です。

同意します。少なくともts + js +マップファイル（たとえば、webstormのように）

ts + js + map + styleのファイルネストがあると便利です。

現在、.jsファイルと.mapファイルを非表示にしているため、これらのファイルをチェックするのが面倒です。 ts + cssだけでも、サイドバーは膨満感を感じます。

同意するこのようなファイルのネストを希望します（特にng2の場合）

HTML
--css
--ts
-など..。

これを再考してください！ これはとても重要な問題です。

生成されたファイルがワークスペースを乱雑にする場合が非常に多くあります。 Typescript！ あなたも使うTypescript！ 代表的な例です。 またはLESS / SASS-> css。 または翡翠-> HTML

生成されたファイルを条件付きで非表示にするオプションがあります。 例えば：

"files.exclude": {
    "**/*.js": {"when": "$(basename).ts"}
}

これと同じプリンシパルをcssファイルとマップファイルに適用できます。

そして、私はそのオプションを使用しています。 私が見たいときに問題が発生します
隠しファイル。 また、隠しファイルが実際にあるかどうかも明確ではありません
そこで（世代が機能している...）、フォルダを開くようになります
ファイルもグループ化されていないエクスプローラーでは...別のことはそれです
私の同僚の何人かは、ファイルの半分が表示されないことに満足していません
プロジェクトと私たちはチーム全体に同じ設定を使用したいと思います。

何らかの理由で、他のほとんどの編集者は、この機能が十分に役立つと考えました
それを実装して、なぜvscodeではないのか。

これは実際には複雑な機能ではないことに注意してください。 私
1日でできることは間違いありません。 （私はプルをすることを考えていました
リクエストしますが、周りのアーキテクチャにいくつかの小さな変更が必要になる場合があります
FileStat）

2016年9月25日（日曜日）には、アンドリュー・シーハン[email protected]
書きました：

生成されたファイルを条件付きで非表示にするオプションがあります。 例えば：

"files.exclude"：{
"* _ /_。js"：{"when"： "$（basename）.ts"}
}

これと同じプリンシパルをcssファイルとマップファイルに適用できます。

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/Microsoft/vscode/issues/6328#issuecomment -249392536、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ABzUP4LXESXZpGtY1iFZJmmy9J10k4-Uks5qta2DgaJpZM4IdUnr
。

+1

仕事をするかもしれない拡張機能はありますか？

なぜこれは閉鎖されているのですか？ それは実装されておらず、素晴らしい機能になるでしょう。

@uxsoft

何らかの理由で、他のほとんどの編集者は、この機能が十分に役立つと考えました
それを実装して、なぜvscodeではないのか。

おそらく、人々が実際のビジュアルスタジオを使用する理由が必要なためです:-)

これは閉じられてはならず、再開されるべきでした。 その間に重複が存在する可能性がありますが。

@stevencl @chrisdias @seanmcbreen @egamma fyiファイルエクスプローラーを論理ビューに変換する場合は、PMのステアリングとガイドが必要です。 最初のPRは、 @ playerxによってhttps://github.com/Microsoft/vscode/pull/13754で作成されました。

現時点での私の2セント：ユーザーが解決したいシナリオの解決策を考える必要があります。ルートファイルの下の同じレベルで同様のファイルを表示することをサポートするだけでは不十分だと感じています。 VSのソリューションエクスプローラーとして強力なものが必要な場合があります。

@bpasero 、

N1。 ファイルエクスプローラーを論理ビューに変える
例：fileA（ "directoryX / fileA"）を、directoryYに配置されているfileBにリンクできます。

N2。 よりエレガントな方法で実際のファイルを表示するためのファイルエクスプローラーのサポートを提供し、開発者にこの機能を有効にする機能を提供します。例：

機能N1と機能N2は同じではありません。ここでは非常に重要な部分であり、お互いをカバーしていません。

ありがとう

@playerxこの問題の説明は

VSとは別に、私たち自身のプロジェクトでは、生成されたすべてのMAPファイルとJSファイルをTSファイルと同じレベルではなくoutフォルダーに配置しています。同じことを行うプロジェクトは、他にもあると思います。 私のポイントは、これらのファイルが同じレベルにある場合と同じように、TSファイルの下にそれらのファイルをネストすることを期待しているということです。

私にとって、ネストとは、同じ拡張子を持つファイルをグループ化することではなく、論理的に一緒に属するファイル（別名「派生リソース」）を一緒に表示することです。 それは理にかなっていますか？

@ playerxN2ははるかに良く見えます。 Angular 2 cliユーザーの場合、これにはその命名規則は必要ありません。 たぶん、ファイルを隠す構成のように、いくつかの構成可能なパターンがあるかもしれません。

Angular2 cliは、次のようなファイルを作成します。

my.component.ts
my.component.html
my.component.scss / css / less

@mbeckenbach良い例、ありがとう

@bpaseroは、生成されたファイルをTSファイルの下にネストするのが良い例です。

皆さんにお願いしたいのですが、私たちが日常生活で使用する可能性のあるすべての実用的な例をここに入れて（理論的にはお願いしません）、その例に基づいて解決策を作りましょう。

質問をしましょう：
Explorerを「よりスマート」にして、ファイル構造の実際の画像をよりエレガントな方法で視覚化するにはどうすればよいですか？

@bpasero okey？ 私はまだ機能N1と機能N2を混ぜないようにしています。

シナリオ1：
前：

my.component.ts
my.component.html
my.component.scss
my.component.spec.ts

後（オプション1）：

my.component.ts
- my.component.html
- my.component.scss
- my.component.spec.ts

後（オプション2）：

my.component.ts
- my.component.html
- my.component.scss
my.component.spec.ts

後（オプション3）：

my.component.html
- my.component.ts
- my.component.scss
my.component.spec.ts

シナリオ2：シナリオ2：
前：

webpack.config.js
webpack.config.commin.js
webpack.config.dev.js
webpack.config.prod.js

後：

webpack.config.js
- webpack.config.commin.js
- webpack.config.dev.js
- webpack.config.prod.js

@playerx 1つの追加：次のファイルも生成します：my.component.spec.ts

デモプロジェクトの単体テストを行わないため、スペックファイルを非表示にしました。 :-)

おかげで、更新されたシナリオ1、オプションの後に使用することを選択するオプションを選択してください

シナリオ1オプション1は、私の意見に最も適しています。

1. Angular 2コンポーネントは、htmlファイルなしで存在できます（インラインテンプレート）
2. Angularチームがいつかより多くのパーツを複数のファイルに抽出することを決定した場合、たとえばmy.component.animations.tsのような追加のファイル名を許可します

シナリオ1、オプション1 ftw！ angle2の命名規則のために+1

@seveves私は間違いなくこの機能が欲しいのですが、

@ aluanhaddad-ここで話題から外れることはありませんが、シナリオで指定された4つのファイルのより適切な命名規則の例はありますか？

すべてのファイルは、拡張子（+ .specファイル）の外側で同じ名前が付けられていますが、これは明らかにangular2固有ではありません。 提起された問題は、同様の名前のファイルを持つ拡張機能の優先順位は何であるかということです。これは、グループ化するプライマリと見なされます。

このシナリオ（クライアント側のタイプ）では、優先順位はTS、JS、HTML、[スタイルタイプ]になると思います。 あなたは常にTSまたはJSファイルを持っているでしょうが、必ずしもテンプレートやスタイリングである必要はありません

これは本当にきれいでしょう！

@playerxは2016年10月15日にコメントしました•編集しました

提案のために：

N1。 ファイルエクスプローラーを論理ビューに変える
例：fileA（ "directoryX / fileA"）を、ディレクトリに配置されているfileBにリンクできます。

これは現在のOSで利用できると確信しています。 Windowsは現在、いくつかのリリースで「ジャンクション」をサポートしており、MKLINKコマンドもサポートしています。

それを考えると、N1オプションの実際の必要性はわかりません。拡張に基づくネストについて、cielのコメント（2016年5月13日にコメント）をお勧めします。

多かれ少なかれ次のような構成可能なルールセットを使用するのはどうですか。

"*.component.ts": [  
   "$(basename).component.html",  
   "$(basename).component.spec.ts",  
   "$(basename).component.js",  
   "$(basename).component.js.map",  
   "$(basename).component.spec.js",  
   "$(basename).component.spec.js.map"
]

別のオプションは、代わりに正規表現パターンを使用することです。

これにより、パターンで指定された順序でパターンに一致するファイルがネストされます。 これにより、さまざまな構成オプションが開かれ、Angular 2の規則（ts / js / htmlに限定されない）に限定されず、予測可能性と一貫性が提供されます。

Visual Studioのようにソリューションビューを導入すると、VSCodeが不必要に複雑になり、軽量の編集エクスペリエンスが失われると思います。

@ aluanhaddad-ここで話題から外れることはありませんが、シナリオで指定された4つのファイルのより適切な命名規則の例はありますか？

本当に、論理的な観点からはあまり変わらないでしょう

my.component.html
- my.component.ts
- my.component.scss
my.component.spec.ts

になります

my.html
- my.ts
- my.scss
my.spec.ts

😆
それは血まみれのように明らかなので、それはコンポーネントです...

私はJohnPapaのAngular2の命名規則に反対していました。 私は、コンポーネント、パイプ、サービス、モジュール、およびその他の冗長なナンセンスの彼の命名に反対します。 彼は、Grunt構成を使用して、IIFEでラップされたモジュール、コントローラー、サービス、およびディレクティブを手動でバンドルしていたときに、Angular 1のこれらの規則を思いつきました（これらはすべて、当時はまともなアイデアでした）。 バンドルやその他のGruntタスクが最初にすべての.moduleファイルをロードできるようにして、コントローラーやサービスなどを登録したスクリプトがロード時に爆発しないようにするだけで十分でした。

つまり、彼のAngular 1スタイルガイドは他のすべての点でほぼ完璧であり、これらのシナリオは当時は適切でしたが、彼のAngular 2スタイルガイド（公式のもの）はひどいものです。 それでは、本質的に醜いもののためにエレガントなスタイルガイドを書くことができるのは誰ですか？

ファイルの入れ子は、現代の開発、特にWeb開発では必須だと思います...

お願いします、お願いします...それをサポートすることを検討してください。

ここで本当に必要なのは、物理エクスプローラーの横にあるカスタム構成の論理ビューシステムのようです。

構造のあるプロジェクトがあると想像してみましょう（意図的に複雑になっています）：

- app
    - logic
        - helpers
            - {helper}.ts
            - {helper}.spec.ts
        - component-logic
            - {component-name}.ts
            - {component-name}.spec.ts
        - viewmodels
            - {viewmodel-name}.ts
            - {viewmodel-name}.spec.ts
    - views
        - {viewmodel-name}.html 
        - {shared-view-name}.html
    - styles
        - {some-common-style-file}.scss
        - {viewmodel-name}.scss
        - {shared-view-name}.html

ファイルをグループ化する方法とファイルを表示する方法を定義できるロジックエクスプローラーが必要です。 グループがネストされている可能性があるため、フォルダー構造に関係のないビューが表示されることになります。 このような論理ビュー構成を想像してみましょう。

{
    "name": "Components",
      "root": "Defines groups to be displayed on the top of the tree",
    "root": ["viewmodelsDirectory", "helpersDirectory"],
    "groups": [{
        "name": "viewmodelsDirectory",
        "displayAs": "viewmodels",
        "groups": ["viewmodel"]
    }, {
        "name": "helpersDirectory",
        "displayAs": "viewmodels",
        "groups": ["helper"]
    }, {
        "name": "viewmodel",
          "headGroup": "Which file is on the top of the group. If omitted then this group displays as directory",
        "headGroup": "viewmodel",
        "pattern": "app\/viewmodel\/(*+)\.html",

          "files": "For each path that match pattern we build a file group",
        "files": [{
            "name": "viewmodel",
              "displayAs": "Pattern explaining how to display this entry. Might accept placeholders like {fileName}, {filesGroupName}, {fileNameWithExtension}, {Extension}",
            "displayAs": "{fileName}",
            "pattern": "app\/viewmodels\/\1\.ts",
            "optional": false
        }, {
            "name": "logic",
            "displayAs": "{fileGroupName}",
            "pattern": "app\/logic\/component-logic\/\1-logic\.ts",
            "optional": false
        }, {
            "name": "view",
            "displayAs": "{fileGroupName}",
            "pattern": "app\/views\/\1\.html",
            "optional": false
        }, {
            "name": "style",
            "displayAs": "{fileGroupName}",
            "pattern": "app\/styles\/\1\.csss",
            "optional": true
        }]
    }, {
        "name": "helper",
        "headGroup": "helper",
        "pattern": "app\/logic\/helpers\/(*+)\.ts",
        "files": [{
            "name": "helper",
            "displayAs": "{fileName}",
            "pattern": "app\/viewmodels\/\1\.ts",
            "optional": false
        }]
    }]
}

このビュー内で、ファイルは次のように表示されます。

- viewmodels
    - {viewmodel-name}
        - view
        - style
        - logic
- helpers
    - {helper}

現在の例では、スペックファイルは完全に非表示になっていることに注意してください。 ユーザーがコードに集中できるようにするために作られています。 このような場合、ユーザーは個別の論理ビューを使用して、好みの方法で単体テストを表示できます。 ワークスペース、ユーザー、および拡張機能レベルで構成可能である必要があります。 ユーザーは、インターフェイスとキーボードショートカットの両方からビューをすばやく切り替えることができるはずです。

これは単なるドラフトですが、アイデアが明確に示されていることを願っています。

私はまだこれがうまくいくことを本当に望んでいます。それは組織にとって非常に重要です。

これは、アウレリアにもますます当てはまります。 Angular2 +と非常によく似た構造。 （構成可能な）ファイルのネストを追加すると、平均的なプロジェクトの1つで、折りたたまれた子を含む完全に拡張されたsrcフォルダーの長さが約2/3に短縮されます。

@ RichiCoder1はい、ありがたいことに、Aureliaは論理的で非冗長な命名規則を使用しています:)
aureliavscode拡張機能とそのOpen-Related-Fileコマンドを確認しましたか。 ネスティングとはあまり関係ありませんが、非常に便利です。

また、1回の名前変更操作でグループの名前を変更したいと思います。

これは、巨大な角度のあるアプリで作業を開始するときに非常に重要になります。これを検討してvscodeを導入してください。すでに持っている場合は、そうでない場合は、vsでのファイルネストについて同様のエクスペリエンスをもたらします。

男、これは本当に私が取り組んでいるAngularアプリケーションをそれほど雑然と鈍くするでしょう。 皆さんが真剣にこれを検討していることを心から願っています。

別の号で言ったように..

私がこれを望んでいる最大の理由は、私が多くの類似した名前のファイルを一緒に持っているAngularのためです。

/app
.../home.ts
.../home.component.ts
.../home.template.html
.../home.styles.scss
.../home.component.spec.ts
.../nav.ts
.../nav.component.ts
.../nav.component.spec.ts
.../nav.template.html
.../nav.styles.scss

それらをネストできれば、それは素晴らしいことです。

コマンド/メディエーターパターンも実行するので、次のようなファイルになります...

/src/
.../Identity/
....../CreateUserRequest.cs
....../CreateUserRequest.Handler.cs
....../ConfirmUserExistsRequest.cs
....../ConfirmUserExistsRequest.Handler.cs
....../ConfirmUserValidationRequest.cs
....../ConfirmUserValidationRequest.Handler.cs

それはかなり冗長になり、この機能はちょうど私の一日を作るでしょう。

これが私がまだWebStormを使用している唯一の理由です...

はい、私たちも。

2017年6月2日には、午前10時10分で、MigFerreira [email protected]書きました：

これが私がまだWebStormを使用している唯一の理由です...

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信するか、GitHubで表示するか、スレッドをミュートしてください。

ばかげた質問：誰かがスクリーンショットをどのように見えるか提供できますか？ その背後にある意味が想像できません。

ああ、大丈夫、ありがとう。

これは今や私たちにとって最大の欠けている機能になっています。 この機能がないために使用しない同僚がいます。 非常に多くのファイルが同じような名前を持っているときに、特定のファイルを見つけようとすると、それは本当に苦痛です。 コンポーネント（Angular）ごとにサブフォルダーを追加しようとしましたが、これは理想的なソリューションではなく、機能（およびサブ機能）フォルダーの下にあるすべてのコンポーネントを一覧表示するだけに戻りました。

私はTypeScriptとAngularを大規模なDojoプロジェクトに導入しています。この機能は、今後数か月以内に私たちのチームのVSCodeユーザーにとって非常に重要になると言えます。

私は現在Angularプロジェクトに取り組んでおり、関連ファイルをグループ化できることは、すでに優れた製品への優れた追加になるでしょう。 Angularプロジェクトが成長するにつれて、ナビゲートするのが難しくなり、現在、生産性が妨げられています。

＃13754から繰り返し：

IMO、最も洗練された解決策は、それをプロジェクトに任せることです。 .vscode/settings.jsonまたは多分project.json 。 ファイル除外構文のようなものを使用してください。 これにより、プロジェクトごとまたはフォルダーごとのカスタマイズが可能になります。 フレームワーク/ツールメンテナー、VSCode、またはサードパーティは、特定のワークフローのパターンセットを配布できます。

このように、VSCodeは何も想定せず、誰にも問題を引き起こしません。 ネストの可能性のある候補を検出し、「ネストする必要のあるファイルがあるようです。これらのデフォルトのネストプロファイルの1つを適用しますか？」というアラートをポップアップ表示できます。

開発者が論理的な入れ子を必要とする場合は、それを使用できます。 彼らがそれを望まないのなら、彼らはただ設定を追加しません。

撮影するのにmy-component.A.B下にmy-component.ts （AngularJS 2）：

"files.nest": {
    "**/*.*.*": {"when": "$(basename).ts"}
}

my-component.ts下でmy-component.dev.tsキャプチャする場合：

"files.nest": {
    "**/*.*.ts": {"when": "$(basename).ts"}
}

または、生成されたファイルの場合（ファイルがdist/生成されるAureliaナビゲーションスケルトンを使用）：

// TypeScript => ES5
"files.nest": {
    "dist/src/**/*.js": {"when": "src/$(dir)/$(basename).ts"}
}

// ESNext => ES5
"files.nest": {
    "dist/src/**/*.js": {"when": "src/$(dir)/$(basename).js"}
}

// Less => CSS
"files.nest": {
    "dist/src/**/*.css": {"when": "src/$(dir)/$(basename).less"}
}

// Mappings
"files.nest": {
    "dist/src/**/*.map": {"when": "src/$(dir)/$(basename)"}
}

このように明確に定義された構文を使用すると、過度に複雑でない限り、必要なネストスキームを追加できます。 最後の例は、gulpによるパスの処理に基づいています（ $(path) =最初のグロブで始まるパス）。

これが考慮されているかどうかについて、いくつかの情報やフィードバックが欲しいです。 現在のところ、含まれている機能になるまで、AngularまたはAurelia開発者にVSCodeを使用することはありません。

@threedaysmore VSCodeチームが実際にそれを検討しているという兆候はありません（のように、それはバックログの終わりに落ちています）。 PR＃13754はそれに対処していますが、少なくとも一時的に@playerxがそれを削除したように見えます。

より最新のPRを作成しました：＃32061。 いくつかのもの（つまりツリーモデル）の処理にバグがあるため、助けを求めています。

+1

+1

+1

この機能に興味があることを示す方法がわかりません。 +1は、スレッドをスパムする（そして人々はそれに親指を立てる）ので、あまり良い方法ではないようです。 単に私の興味を示すために、githubの問題に+1または「この機能が大好き」を与えるための推奨される方法は何ですか？

この機能の重要性を示す/高めるために、最初の作者のコメントに親指を立てるだけです

@bpaseroは私のプルリクエスト＃

メンテナや他の誰かがこれを拡張することはできますか？ または、これをプルリクエストまたは拡張機能として実装する方法についてのガイダンスを提供しますか？

@ firelizzard18私はこの機能を本当に一生懸命にしたかったので、それに取り組んでしばらく時間を費やし、同じフィードバックを得ました。 彼らがこの機能を望まない理由はいくつかあると思いますが、彼らは私たちに教えてくれません:)

@bpasero
この機能は、（寄稿者からの）あなたからのより多くのガイダンスに値すると思います。それをどのように行うことができるか、そしてご覧のとおり、それを実現するために時間を費やすことができる人々がいます。

VSCodeでもファイルをネストできると便利です。
最近、Angularのサポート/統合が改善されたため、ASP.NETCoreアプリのAngular /フロントエンドプログラミング用にVS2017からVSCodeに変更しました。 それははるかにうまく機能しますが、私はファイルのネストが本当に難しいのを見逃しています。 :-(

VS Codeにファイルのネスト機能を追加するか、他の人に拡張子を開発する可能性を与えてください！

https://blogs.msdn.microsoft.com/webdev/2018/02/07/file-nesting-in-solution-explorer/
また
https://marketplace.visualstudio.com/items?itemName=MadsKristensen.FileNesting

@bpaseroチームからこれに関する最新情報を入手できるかどうか

ReactコミュニティとTypeScriptコミュニティには強力なユースケースがあり、開発者の感情は一貫して前向きです（個人的にもこれを確認したいと思います）。 再度、感謝します

@develleoper彼らは彼らの期待をかなり明確にしたと思います。 彼らはそれが受け入れられるように完全にカスタマイズ可能であることを望んでいます。 ファイルエクスプローラーを完全に制御できないものを許可することは意味がありません。 トリッキーな部分は、IDEの構造が物理的な構造とは完全に異なる場合でも、ファイルの作成/移動を許可する必要があることです。 また、複数のビューを切り替えることができると期待していると思います（たとえば、ファイルコンテキストと単体テストコンテキストを設定できます。テストを1つに記述してから、別のビューに切り替えて満足させます）。

彼らはユースケースを知っていると確信していますが、ロードマップを見ると、彼らの計画はこれよりもはるかに野心的で有用であることがわかるかもしれません。そのため、彼らはこれをコミュニティに残すことにしました。 。

私はあなたがそれを試してみるのを歓迎していると思います-Micro $ oftでの素晴らしいキャリアの機会は勇敢なものを待っています;）

"Micro $ oft" LUL-経験が限られた10代の若者がこのスレッドをまったくフォローしていないことに驚いています。

_Anyway _、 @ develleoper-彼ら（Microsoft）は最近、拡張機能メーカーが独自のパネルを側面に追加できるようにする機能を追加しました。そのため、すぐにリリースされると、拡張機能メーカーによっては、物理的なファイルツリーではなく論理的なファイルツリーを表示する拡張機能が作成される可能性があります。 。

@waynebloss IMO、この機能は、新しいパネルを必要とする潜在的な拡張機能として残してはなりません。 このアプローチでは、現在のすべての機能を使用してファイルツリーを再実装するだけでなく、追加される将来の機能を使用してファイルツリーを更新する必要があります。 はい、現在のファイルツリーコードを拡張機能にフォークすることはできますが、それによって将来の機能更新を追跡するメンテナンスの負担が軽減されるわけではありません。

少なくとも、ファイルツリー自体は、これを実装するのに十分な拡張ポイントを付与できます。 （それを追加し、それをこの機能に利用するための拡張機能を構築することは、とにかく初期の作業が少なくなる可能性があります。）

@RoyTinkerは同意しました-ファイルのネストが正式にサポートされるまでは、新しいパネルが回避策になると思っていました。

@Wayofthesin私はあなたが何をしようとしているのか全く@playerxがプルリクエストを行い、「いいえ」と言われました。 私は彼のプルリクエストをフォークし、その時点で最新のマスターブランチにマージし、いくつかの調整を行い、それを送信しました。 そして「いいえ」と言われました。

したがって、コミュニティがこれを望んでおり、開発者がコミュニティからの貢献を受け入れることに関心がないことは明らかです。

@develleoper＆他の人が、私はS PR @bpasero「@playerx上のコメントは、」私たちにVSCodeチームはこれで行きたい場所について多くのことを教えてくれと思う： https://github.com/Microsoft/vscode/pull/13754

彼のコメントから、私は@bpaseroを理解してい

• ある種の論理的なビューを必要とするすべてのグループに対応する包括的なアプローチを望んでいます
• ファイルのネストを（物理的なファイルシステムビューではなく）論理ビューと見なします
• 論理ビューは、物理的なファイルシステムビューから分離する必要があると考えています

私の意見では、ファイルのネストは論理的なビューの変更ですが、ファイルの非表示も変更されます。これは現在ファイルツリーでサポートされており、設定で構成できます。 ファイルのネストは、それらのファイルを表示する方法を提供することを除いて、ファイルの非表示の単なる別の形式であるように私には思えます。

余談ですが、Atomはツリービューパッケージを介したファイルのネストをサポートするようになりました。https：//github.com/atom/tree-view/issues/572を参照して

@ firelizzard18プルリクエストを見ました。 私は自分の考えをコメントしました。 ＃32061。

@RoyTinkerは彼らが何を期待しているのかかなりよくコメントしました。 PRが作成されていることについて話すことはできますが、私が見る限り、 @ bpaseroからの最初の期待さえ

VSとは別に、私たち自身のプロジェクトでは、生成されたすべてのMAPファイルとJSファイルを、TSファイルと同じレベルではなく、outフォルダーに配置しています。同じことを行うプロジェクトは、他にもあると思います。 私のポイントは、これらのファイルが同じレベルにある場合と同じように、TSファイルの下にそれらのファイルをネストすることを期待しているということです。

追加として、次のように追加します。ファイルエクスプローラーの時点で仮想エクスプローラーを考えないでください。 誰かがエクスポートされたオブジェクトをtypescriptファイルの下にネストしたいと思うかもしれません。

なぜ彼らはPRを受け入れなかったのだろうと思います。 彼らは既存のコードにパッチを当てることには興味がありません。 彼らは、構成可能であるだけでなく拡張可能な柔軟なソリューションを探しています。 彼らはそれ自体については考えていないようですが、彼らは自分たちが望んでいないことをほとんど知っています。

私が見ている問題は、なぜ彼らがPRを受け入れないのかを推測しようとしていることであり、明確な答えとガイダンスがありません。 みんなが作ったコメントはすべて、 @ bpaseroがそれについてどう思っているかをあなたが解釈したもの

非常に多くの会話があり、貢献者からの沈黙が続いているので、それは製品自体には良くないと思います。

@Wayofthesinは、頭の上に釘を打つ@playerx：我々は両方の@bpaseroは、より多くの私たちが提供しているが、@bpaseroが移動する場所、それを明確にするために十分なフィードバックを提供するために失敗したものよりも何かを望んでいるという事実を明確にしています。 私の場合、 @ bpaseroは非常に漠然としたコメントで私のPRを@playerxの場合、 @ bpaseroは「現在、ゲーム終了中

私のPRは進行中の作業でした。 前進する方法について、開発者からのガイダンスが必要でした。 代わりに、私は不可解な応答を受け取り、PRを閉じました。

私のコメントあなたは私のPRのあなたのレビューで参照、私は'（の欠如）との@playerxの一般性の問題をのアプローチを@bpaseroに対処するため

冗談だ。 気分を少し上げたかった。 これを調べてください。 この種のプロジェクトビューを操作するのは非常に困難です。 それは難しいことではありませんが、非効率的です。

+1、同意します。この機能は、wechatミニアプリの開発にも非常に役立ちます

これは難しいですか？ 約200万人のJavaCommunityメンバーが、この機能をできるだけ早く必要としています。 お願いします....！！！

VS Codeは、ツリービューでの仮想ファイルのネストをある程度サポートしているようです。 バージョン1.29の変更ログには、次の点が含まれています。

これは、ファイルのグループ化の基盤が作成されたことを示しているようです。

@MortenChristiansen mmm ...同じ機能ではないようです」

提案として、Visual Studio 2017には、 .filenesting.json構成ファイルを介したファイルのネスト機能があります。 おそらく、構成ファイルに関して同様の何かをVSCodeに実装できます。

• https://blogs.msdn.microsoft.com/webdev/2018/02/07/file-nesting-in-solution-explorer/

例として：

{
  "help": "https://go.microsoft.com/fwlink/?linkid=866610",
  "root": true,

  "dependentFileProviders": {
    "add": {
      "addedExtension": {},
      "pathSegment": {
        "add": {
          ".*": [
            ".js",
            ".css",
            ".html",
            ".htm",
            ".less",
            ".scss",
            ".coffee",
            ".iced",
            ".config",
            ".cs",
            ".vb",
            ".json"
          ]
        }
      },
      "extensionToExtension": {
        "add": {
          ".js": [
            ".coffee",
            ".iced",
            ".ts",
            ".tsx",
            ".jsx",
            ".vue"
          ],
          ".css": [
            ".less",
            ".scss",
            ".sass",
            ".styl",
            ".vue"
          ],
          ".html": [
            ".md",
            ".mdown",
            ".markdown",
            ".mdwn"
          ],
          ".map": [
            ".js",
            ".css"
          ],
          ".svgz": [
            ".svg"
          ],
          ".designer.cs": [
            ".resx"
          ],
          ".cs.d.ts": [
            ".cs"
          ],
          ".ts": [
            ".vue"
          ],
          ".scss": [
            ".vue"
          ],
          ".sass": [
            ".vue"
          ]
        }
      },
      "fileToFile": {
        "add": {
          ".bowerrc": [
            "bower.json"
          ],
          ".npmrc": [
            "package.json"
          ],
          "npm-shrinkwrap.json": [
            "package.json"
          ],
          "yarn.lock": [
            "package.json"
          ],
          ".yarnclean": [
            "package.json"
          ],
          ".yarnignore": [
            "package.json"
          ],
          ".yarn-integrity": [
            "package.json"
          ],
          ".yarnrc": [
            "package.json"
          ]
        }
      },
      "fileSuffixToExtension": {
        "add": {
          "-vsdoc.js": [
            ".js"
          ]
        }
      },
      "allExtensions": {
        "add": {
          ".*": [
            ".tt"
          ]
        }
      }
    }
  }
}

バンプ🏗

dartで自動生成されたファイルにも適しています。

これは、Salesforce拡張機能にも役立ちます。 私たちのプロジェクトには、すべてのコードファイルに関連付けられた*.meta.xmlファイルがあるため、ファイルツリーの長さが2倍になります。 そのメタデータファイルをソースファイルの下に置きたいと思います。

ネスティング機能に関するユーザーの要件/ニーズを収集することは問題ではないと思います。
それを実装することは問題ではないと思います。 たぶん、いくつかの寄付は公式リリースでそれをより速く実装するのに役立つでしょうか？

私のファイルを見つめて、
Typescript、Web、およびスタイルが高く積み重ねられています。
入れ子にするといいでしょう。

すみません。 彼らはこれにまったく興味を持っていないようです。

男、これも見たいです。

奇妙な-この機能の動作は非常に明確に定義されており、明らかに非常に必要とされています。

+1カムオンみんな

これは起こっていないので、私はおそらく問題を閉じます。

@isidornは、彼らがそれに興味がなく、それをやろうとしていないことを明らかにしました。 残念です。 これが私が今VSCを使うのを妨げるすべてです。 Angularアプリケーションは、ファイルをネストしないと非常に冗長で面倒です。

私は今のところまだWebStormで立ち往生していると思います。

この問題をオープンにしておくことをお勧めします。近い将来、これに対処する可能性があります。

@isidornは、「それほど近い将来ではない」と

2019年、何か新しい人はいますか？

Java開発者として、これが私がvscodeに完全に移行するのを妨げる主な原因です。

私のJavaプロジェクトでは、Javaパッケージの名前空間の空のディレクトリが、エクスプローラーで使用可能なスペースの半分（またはそれ以上）を占めています。 エクスプローラーでは常に上下にスクロールする必要があります。これは、開発の反復ごとに何度もスクロールする必要がある場合、時間のかかる作業です。 Java開発用の多くのIDEは、これらの空のディレクトリを1つのパッケージ名にまとめ、開発者がパッケージ構造全体を簡単に確認できるようにします。

これは、vscodeで実装することは可能ですが、他のより優先度の高いタスクのために優先順位が付けられていないものですか？ または、基盤となるvscodeアーキテクチャの制限により、これを実装することはできませんか？

これを実行するための拡張機能はありますか？ とても必要な機能です！

3年以上オープンしています...彼らがやろうとしているようには見えません...今すぐwebstormをインストールしています...

これと、それらが対処されると思われるいくつかの非常に基本的なものを貼り付けてインデントすることは、フリーウェアとオープンソースで得られるものかもしれません。 あまり良くない...ゲームにスキンがないので。

はい-他の点では優れた開発チームからの非常に残念な反応（または欠如）。

カスタムネストを作成しましたが、プルリクエストがマージされません。 VSコードチームには他の計画があり、コードのその部分に変更を加えたくないためです。 私にとってこの機能も重要なので、カスタムのVs Codeビルド（拡張機能ストアが機能します）を作成しました。試してみることができますhttps://github.com/floatas/vscode/releases/tag/1.37これがどのように進行するかを確認します問題は、VsCodium（アップデーターを使用した自動ビルド）に似たものを作成することを検討していますが、変更を加えたものです。

この構成をsettings.jsonに追加するだけです。

    "files.nesting.enabled": true,
    "files.nesting.rules": {
        "(?<basename>.*)\\.ts$": [
            "$(basename)\\.spec\\.ts$",
        ],
        "(?<basename>.*)\\.html$": [
            "$(basename)\\.css$",
            "$(basename)\\.scss$"
        ]
    },

ネストを有効にする場合は、VsCodeRestartが必要です。

@floatasコードをありがとう！ 拡張機能を作成することについてどう思いますか？

@ e-belair残念ながら、拡張機能を作成することはできません。 この機能のAPIは利用できません。

ファイルのネスト機能はとても素敵です！ これが起こることを願っています:)

@floatas PRはどこにありますか？

@ tariqporter ＃72160

@floatas （https://github.com/microsoft/vscode/issues/6328#issuecomment-524030094）

VSコードチームには他の計画があり、コードのその部分に変更を加えたくないためです。

これは＃41627になります。これは、ツリービューの書き換えの一部として最初に処理されます。これにより、後で実装しやすくなる可能性があります。

VS Codeは素晴らしいと思いますが、これは欠けている基本的な機能です。

それも楽しみにしています

それが必要

これに関する更新があるかどうかだけ興味がありますか？ ツリービューをクリーンアップする必要があるのは素晴らしいことです！

Blazorアプリでこの機能を使用しているという理由だけで、引き続きVS forMacを使用しています。 なぜチームからの抵抗が多いのですか？

これを可能にするために必要な拡張APIの実装を追跡するための問題はありますか？

4年後、この問題に進展はありませんか？ oO.。
これは正直に言うと気が遠くなるようなものです...

私が使用したIDEで、これを何らかの形でサポートしていないものは考えられません。また、これが役に立たないプラットフォームでのプロジェクトも考えられません... oO.。これは、これがどのIDEでも与えられたものだと私が思ったところまでです...推測しないでください...

チームは人々を競争相手に押しやろうとしているだけですか？...
WebStormをVSCodeに置き換えたかったのですが、それは実現していないと思います。 そして、VSやIDEAを置き換えることはできません：S .. ..

しかたがない...

@jeme開発者への嫌がらせが何らかの影響を与えると思いますか？ 私がメンテナーだったとしたら、敵対的なコメントは絶対に無視します。 害虫だけでなく実際に建設的になりたい場合は、「この機能は私にとって非常に重要であり、このツールを採用することを妨げています」を試してください。

@ firelizzard18すると、何かが

ここのコメントを読んでみると、あなたが言うように振る舞う人がたくさんいるので、聞いてもらう必要があります。

そして、あなたは敵対的であることは物事を変えるだろうと思いますか？

私が言っているのは、優れたビジネスパーソンは、メッセージがどのように伝わってくるかを気にしないということです。 したがって、これらのコメントを無視すると、あなたは良いビジネスパーソンにはなりません。 あなたがテクノロジー会社のカスタマーサポートラインで働いたことがあるなら、あなたはこれを理解するでしょう。

最後に、私の全体的な結末は、あなたがそれを読んだ場合、どちらにせよ、それは良い（前のコメントが良い）または良くない（あなたが講義しているコメントによって）問題ではない、彼らが彼らのためにそれをするつもりはないということでしたゲームにスキンがないのはフリーウェアです。 本当に論点であり、彼らはチケットを閉じる必要があります。

この問題がまだ解決されていない理由について不満を言うのではなく、コメントセクションを可能な解決策と洞察に集中させることはできますか？ この問題の影響を伝える方法は、問題の説明に投票することです。

ありがとう

これにはオープンPRがあります（＃13754）...
誰かが正式にフォークを宣言し、WindowsアップルとLinux用のバイナリを備えた基本的な静的サイトをセットアップする場合...おそらく数千の角度のある開発者が一晩でそれに襲い掛かるでしょう、そしてどこかに小さな寄付ボタンがあればあなたもお金を稼ぐことができます努力のために。
私は個人的にこの機能を今は必要としませんが、VSCodeはMITライセンスの下にあり、コミュニティは本当に機能を望んでおり、コミュニティの一部のメンバーはこの機能の実装に非常に熱心に取り組んでいます。
そう...

たぶん彼らも＃75181を修正することができます！ エクスプローラーパネルを表示するだけでは、ファイルタブは開かれません。

@BrunnerLivioあなたはあまりにも面白いと不平を言うことについて不平を言います;）。 これは、誰かが自分の不快感、必要性、または投票をどのように伝えたかについて、誰かが自分の道徳的行動を他の誰かに修正または強制したかったために始まりました。 あなたは同じことをしています。 繰り返しになりますが、この問題がどこにも起こらないのはフリーウェアです。 それは4年も経っていません。 誰もが「彼ら」について話している。これはフリーウェアだ。 彼らはこのフォーラムの人々であり、約1年前に私が気付いたものです。 そして、私はこの機能強化を行うための時間があまりにも多く、むしろIDEにお金を払うことを望んでいます。これは私がwebstormで行うことです。

個人的には持っていて良かったと思いますが、誰も面倒なことはしません
基本的に無料であることがわかっているので、誰かがサービスレベルアグリーメントを保持したり、サポートにお金を払ったりしているわけではありません。 「顧客」という言葉は購入した製品を意味するので

したがって、代替案は

1. ソースをフォークし、機能を追加し、プルリクエストを発行して、それを含めるように依頼する人
2. 別のオプションとして、Visual Studio 2019コミュニティを試してみてください。これも無料です（ただし、オープンソースではありません）。
3. 追加されるまで他のものを使用してください

私が思うもう一つの選択肢：

独自のサイドバーボタンとパネルを使用してエクスプローラツリーを模倣する拡張機能を構築し、それを使用します。

そして、私はそうしました。

PT。、2020年7月2日、午前2時15użytkownikHecatron [email protected]
napisał：

個人的には持っていればいいと思いますが、誰も面倒なことはしません
その上
基本的に無料だと知っているので、誰かが持っているわけではありません
サービスレベルアグリーメントまたはサポートのためのお金の支払いに。 言葉以来
「顧客」とは、購入した製品を意味します

したがって、代替案は

1. ソースをフォークし、機能を追加し、プルを発行する誰か
   リクエストして、それを含めるように依頼します
2. 別のオプションとして、Visual Studio2019コミュニティを試してみてください。
   入れ子があるので無料（ただしオープンソースではない）
3. 追加されるまで他のものを使用してください

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/microsoft/vscode/issues/6328?email_source=notifications&email_token=ACJ4R34R3CWQNAAMHTCOP2TRBSY3TA5CNFSM4CDVJHV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW
または購読を解除する
https://github.com/notifications/unsubscribe-auth/ACJ4R3YUKMXFVOO5NSXSQ6DRBSY3TANCNFSM4CDVJHVQ
。

これのいくつかの進歩！ vscodeでは非常に必要だと思います!!

VS Codeは無料の製品であり、VisualStudioのフルバージョンは有料の製品です

@GeorgeTaraziあなたのコメントに基づいて、

誰もあなたの話題から外れた意見について通知を受け続けたいとは思わない。 たぶん、リポジトリのメンテナは、今のところこの問題に関する議論をロックすることを検討する必要があります。

個人的には、Visual Studio 2019 Community（無料）エディションは、私が行う必要のあるすべてのことに対して十分であることがわかりました。
過去の古いPro / Enterpriseバージョンと比較。
これは、たとえばJavaの代わりにオープンソースとしてdotnetをプッシュしようとしているMSの観点から見ると、理にかなっています。
それでも、ビジネスの観点からStudio 2019を使用するには、ライセンスが必要です。

ユースケースは異なりますが、Studio2019とVSCodeの両方を使用しています。 VScodeはpythonが好きで、Studio2019はdotnetが好きです。
オープンソースなどに取り組んでいる場合はVSCode。
コンパイラは、少なくともdotnetについては、別の外部ツールであるため、likley共有されていません。
また、両方とも異なる言語で書かれています。VSCode-Javascript、Studio 2019はおそらくC＃とCPPの組み合わせです。

機能がまだ移植されていない理由はエーテルだと思います

1. 彼らは、拡張機能に関連するものや最初に必要な依存関係など、他の機能を最初に実装することを目指しています
2. 異なるチーム、異なるレベルのリソース
3. ゼロから作成する必要があり、異なる言語間でコピー＆ペーストすることはできません。

@georgebatalinski私はあなたが言っていることのほとんどに同意します。 ただし、ビジュアルコードは、ビジュアルスタジオよりもAngularに役立つと思います。具体的には、フロントエンドスパの開発者にとってより使いやすいものになりました。 私は90年代からVS製品を使用しているので、おそらくあなたより年上です;）私はQbasicでさえvb日までさかのぼります。 私は個人的に私にうんざりしています、私にそれを無料でください。 特にこの追加機能を取得するためのビジュアルコードにお金を払ってうれしいです。 しかし、私はまだVCを使用していません。これは、この機能が私の目には大規模なアプリに必要なだけだと感じているためです。

この機能は実装されますか？
ワークスペースを乱雑にする生成されたファイルがたくさんあるので、Webプロジェクトで作業するときに非常に便利だと思います（ただし、それらを確認する必要がある場合があるため、非表示にすることは解決策ではありません）。

それを無効/有効にする選択をユーザーに任せて、どの拡張機能がそれをトリガーするかを選択してみませんか？！ :-)
実装はとても簡単なようです...。

@ funder7すぐにはありません。 開発者は、VS Codeがどのように機能するかについて、異なるイデオロギー的な見方をしていることを表明しているため、これは必ずしも優先事項ではありません。

@tmarkovskiに感謝します。現在、これを使用して、生成されたファイルを削除していますrm -f *.js *.map ...ちなみに、この機能をIntelliJ Ideaで発見したので、複雑なプロジェクトで作業するときに非常に便利です。
それが開発者のアプリの見方にない場合は、少なくともデフォルトでは無効のままにしておきますが、エンドユーザーには有効にするオプションを残します。
私にとってこの種の機能がセカンダリソフトウェアとお気に入りのソフトウェアの違いを生むので、私はアイデアについて言及しました。

実はこれが

        "**/*.js": {
            "when": "$(basename).ts"
        },

生成されたファイルを非表示にしますが、その後消えて、その存在に気づきません：/

ソフトウェアの世界では永遠である4年以上経ちましたが、これを実装する計画はまだありませんか？ これは、巨大なファイルツリー構造をスキャンする際の精神的な負荷を軽減することにより、生産性を大幅に向上させます。 エクスプローラーに追加のファイルが表示されることなく、Typescriptインターフェイスファイルを個別に作成できます。

この機能の進歩はありますか？

この機能の進歩はありますか？

重複する問題は先週vscodeチームのメンバーによってクローズされたため、彼らはそれを認識していますが、無視することを選択しています。
理由を知るのに本当に苦労しています。

理由を知るのに本当に苦労しています。

それは彼らにとって優先事項ではないからです。 チームとして、彼らは他のものを優先することに決めました。 あなたは彼らの決定に反対することができますが、この「 OMGwhhhhhy 」の泣き言はすべて不快で無意味です。

それは彼らにとって優先事項ではないからです。 チームとして、彼らは他のものを優先することに決めました。 あなたは彼らの決定に反対することができますが、この「OMG_whhhhhy_」の泣き言はすべて不快で無意味です。

私にとって、開発者が別の開発者が自分のコードをどのように記述しなければならないかを決定するのは無意味です。 そのため、アプリケーションには通常、環境を好きなように設定できる「設定」ビューがあります。 私たちは一日中仕事の目的で使用されるツールについて話しているので、ファイルリストをより読みやすくする機能を求めることは私には愚かではないようです。

機能を求めるユーザーはVSCodeがどのように改善されるかであり、おそらく十分な数の人々がこの機能を求めると、それは実際に起こります。 しかし、不平を言うことは無意味です。

大規模なワークスペース向けの機能が必要です。

私は最近これをもう一度見ています、私が集めることができるものから、過去にいくつかのプルリクエストがありましたが、それほど遠くはありませんでした

• https://github.com/microsoft/vscode/pull/13754
• https://blog.floatas.net/blog/visual%20studio%20code%20file%20nesting/

しかし、私はここで見たものに基づいて、これを拡張機能として実装できるはずだと考え始めています。

• https://code.visualstudio.com/api/extension-guides/tree-view
• https://github.com/fernandoescolar/vscode-solution-explorer

vscodeの他の拡張機能をいくつか調べましたが、何も見つかりませんでした
必要なのは、デフォルトのファイルエクスプローラーウィンドウと同じものを表示できる拡張機能を作成することですが、ネストが追加されています。理想的には、Visual Studio 2019で既に使用されている.filenesting.jsonファイルの読み取りがサポートされています（コード）

• https://docs.microsoft.com/en-us/visualstudio/ide/file-nesting-solution-explorer?view=vs-2019

javascriptは私の母国語ではないので、自分で何かできるかどうかはわかりません
これを行うのに十分な拡張APIが公開されていると思いますが、少なくとも左側の別のエクスプローラータブにあります

こんにちは@grbd 、この開発の「フック」は、ファイルエクスプローラーがフォルダーを処理するポイントになると思います。これは、ネストされたファイルがどのように表示されるかを示します。 次に、この動作をディレクトリだけでなくファイルに拡張する必要があります。
新しい表示モードに含めるファイル拡張子を指定するために、設定を追加すると便利です。
私はvscode用に何も開発したことがないので、他の情報を提供することはできません...拡張機能を開発することは良い考えのようですが、十分に使用およびテストされたら、メインアプリケーションのソースコードに移動される可能性があります。

出発点として、私はおそらくvscode-solution-explorerを見て、それをコピー/貼り付けします
メインのファイルエクスプローラーと同様のサブディレクトリにファイルを表示する際に、すでに同様のことを行っているためです。
違いは、ファイルのネストではなく、VStudio2019のビューをエミュレートすることを目的としていることです。

どのファイル拡張子を含めるかを指示するための設定は、前述の.filenesting.json、またはその他のjson関連ファイルのようなものになります。

理由を知るのに本当に苦労しています。

それは彼らにとって優先事項ではないからです。 チームとして、彼らは他のものを優先することに決めました。 あなたは彼らの決定に反対することができますが、この「OMG_whhhhhy_」の泣き言はすべて不快で無意味です。

あなたはあなたが_機能要求_の問題に直面していることに気づいていますよね？ あなたは他のどこにでもいるでしょうが、これはそれについて要求して話すための_実際の_正しい場所です（それは無意味な泣き言ではありません）。 人々が幸せでそれを必要としないと彼らが考えるならば、それは決して優先事項ではありません。

「仮想フォルダー」が必要な理由を説明します。makefileを介して構成されたCコードベースを使用していますが、変更するリスクはありません。 ただし、コードは混乱しており、同じ問題を維持するために他のコードベースがあります。

正気を維持するために、仮想ディレクトリにファイルを仮想的に配置する必要があります。これは、Code :: BLocks、Programmers Notepad（ええ）で実行できます。 しかし、VSCodeには参加できません。

これは、多くの組織で一般的な、フォルダ内のファイルの整理方法を制御できない人にとっては必須です。 これは「より美しくする」ことではありません。

結果：VSCodeを使用すると生産性が大幅に低下します。 使用できればいいのですが、ワークフローが遅くなります。

チームが考えを変えてくれることを願っています。技術的には可能ですが、プラグインで処理するべきではないと思います。 私はそのようなコアニーズをプラグインプロバイダーに依存したくありません。壊れるかもしれない何かに時間を投資します。

これは優先事項ではないことを理解しています。より多くのユーザーがVSCodeを使用して生産性を高められるようにしたい場合は、将来的に検討するようお願いしています。

@grbdお手伝いしたいのですが、これは大変な作業のようです。時間があれば
今日のマスターに一致するようにカスタムファイルネストフォークを更新しました。 誰かがファイルのネストの開始点を必要とする場合は、それを試すためにバイナリも追加しました。
https://github.com/floatas/vscode