Vscode: 文件嵌套

仅供参考@bpassero

最理想的情况是，任何以与父文件相同的文本开头的内容（减去扩展名）都会嵌套，如下所示；

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

暂时没有计划。 关闭，直到我们重新考虑这一点。

这是大型项目的重要功能。 我正在为 Angular 项目使用 asp.net vNext，现在我自动遵循以下结构（通过命名）：

--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
- 等等 ...

请重新考虑这个！ 这是一个如此重要的问题。

在很多情况下，生成的文件只会使工作区变得混乱。 打字稿！ 您也使用的打字稿！ 是一个典型的例子。 或 LESS/SASS -> css。 或玉 -> Html

可以选择有条件地隐藏生成的文件。 例如：

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

同样的原则可以应用于您的 css 和 map 文件。

我正在使用该选项。 当我想看到
隐藏文件。 也不清楚隐藏文件是否真的
那里（一代正在工作......），这让我打开文件夹
在文件也没有分组的资源管理器中......另一件事是
我的一些同事对看不到其中的一半文件感到不舒服
项目，我们希望对整个团队使用相同的设置。

出于某种原因，大多数其他编辑认为此功能足够有用
实现它，为什么不 vs 代码。

我想指出，这真的不是一个复杂的功能。 我是
很确定它可以在一天内完成。 （我正在考虑拉
请求，但它可能需要对周围的架构进行一些小的更改
文件状态）

2016 年 9 月 25 日，星期日，Andrew Sheehan通知@ github.com
写道：

可以选择有条件地隐藏生成的文件。 例如：

“文件。排除”：{
"*_/_.js": {"when": "$(basename).ts"}
}

同样的原则可以应用于您的 css 和 map 文件。

—
您收到此消息是因为您发表了评论。
直接回复本邮件，在GitHub上查看
https://github.com/Microsoft/vscode/issues/6328#issuecomment -249392536，
或静音线程
https://github.com/notifications/unsubscribe-auth/ABzUP4LXESXZpGtY1iFZJmmy9J10k4-Uks5qta2DgaJpZM4IdUnr
.

+1

任何可以完成这项工作的扩展程序？

为什么这是关闭的？ 它没有实现，将是一个很棒的功能。

@uxsoft

出于某种原因，大多数其他编辑认为此功能足够有用
实现它，为什么不 vs 代码。

也许是因为他们需要一个理由让人们使用真正的视觉工作室:-)

这应该没有关闭，重新开放。 虽然同时可能存在重复项。

@stevencl @chrisdias @seanmcbreen @egamma fyi如果我们想将文件资源管理器转换为逻辑视图，我们需要一些 PM 指导和指导。 @playerx在https://github.com/Microsoft/vscode/pull/13754 中创建了一个初始 PR

我现在的 2 美分：我们应该为用户想要解决的场景考虑一个解决方案，我的感觉是仅支持在根文件下显示相同级别的类似文件是不够的。 人们可能想要一些强大的东西作为 VS 中的解决方案浏览器。

@bpassero ，我很抱歉，但您提出的问题不正确。 有两种不同类型的功能：

N1。 将文件浏览器变成逻辑视图
示例：您可以将文件 A ("directoryX/fileA") 链接到放在目录 Y 中的文件 B

N2。 提供文件浏览器支持以更优雅的方式显示真实文件，并让开发人员能够启用此功能，例如：

Feature N1 和Feature N2 不一样，这里是非常重要的部分，它们不相互覆盖。

谢谢

@playerx我提出了解决方案资源管理器，因为此问题的描述引用了 Visual Studio 2015，据我所知，只有解决方案资源管理器。

独立于 VS，我们自己的项目将所有生成的 MAP 和 JS 文件放入out文件夹中，与 TS 文件不在同一级别，我相信还有其他项目也这样做。 我的观点是，我希望将这些文件嵌套在 TS 文件下，就像它们在同一级别时所做的那样。

对我来说，嵌套不是将具有相同扩展名的文件组合在一起，而是将逻辑上属于一起的文件显示在一起（也称为“派生资源”）。 那有意义吗？

@playerx N2 看起来好多了。 对于 angular 2 cli 用户，这不应该要求该命名约定。 也许在隐藏文件配置中可能有一些可配置的模式。

Angular2 cli 创建如下文件：

my.component.ts
我的组件.html
my.component.scss/css/less

@mbeckenbach很好的例子，谢谢

@bpassero嵌套生成的文件，在 TS 文件下是很好的例子，谢谢

我想问大家，让我们把每个可能的实际例子都放在这里（请不要理论），我们会在日常生活中使用，让我们根据这些例子做出解决方案。

让我们的问题是：
如何让资源管理器“更智能”以更优雅的方式可视化文件结构的真实画面？

@bpasero好吗？ 我仍然试图不混合功能 N1 和功能 N2。

场景一：
前：

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：
前：

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一个补充：它还会生成这个文件：my.component.spec.ts

我隐藏了规范文件，因为我没有对演示项目进行单元测试。 :-)

谢谢，更新了场景 1，请选择您会选择使用的选项

场景 1 选项 1 在我看来是最合适的。

1. angular 2 组件可以在没有 html 文件的情况下存在（内联模板）
2. 如果 angular 团队决定有一天将更多部分提取到多个文件中，将允许使用其他文件名，例如 my.component.animations.ts

场景 1，选项 1 ftw！ +1 因为 angular2 命名约定

@seveves我绝对想拥有这个功能，但我不得不说 Angular 2 的命名约定太糟糕了。 支持此功能不应基于特定于框架的任意样式指南，该指南根据 ES 模块构建工具下的开发人员人体工程学需要规定命名约定，这些工具不再与使用它们的框架相关。 我再次希望看到对此功能的支持，但我认为这是错误的原因。

@aluanhaddad - 在这里不要太离题，但是您是否有一个示例，说明对于场景中指定的 4 个文件来说，什么是更好的命名约定？

所有文件在扩展名（+.spec 文件）之外的名称都相同，这显然不是 angular2 特定的。 提出的问题是具有类似命名文件的扩展名的优先顺序是什么：这将被视为主要分组。

我认为在这种情况下（客户端类型），优先级是：TS、JS、HTML、[样式类型]。 你总是有一个 TS 或 JS 文件，但不一定是模板或样式

这将非常整洁！

@playerx于 2016 年 10 月 15 日发表评论 • 已编辑

对于建议：

N1。 将文件浏览器变成逻辑视图
示例：您可以将 fileA ("directoryX/fileA") 链接到放置在目录中的 fileB

我很确定这在任何当前的操作系统中都可用； windows 现在已经支持了几个版本的“Junctions”，甚至现在还有一个 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"
]

另一种选择是使用 RegEx 模式。

这将按照模式指定的顺序嵌套与模式匹配的文件。 这打开了一组广泛的配置选项，它不限于 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

😆
因为很明显它是一个组件......

我反对 John Papa 的 Angular 2 命名约定。 我反对他对组件、管道、服务、模块的命名，以及其他多余的废话。 当他使用 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}

请注意，在当前示例中，规范文件是完全隐藏的。 它旨在使用户专注于代码。 在这种情况下，用户将拥有单独的逻辑视图，以他喜欢的方式向他展示单元测试。 它应该可以在工作区、用户和扩展级别进行配置。 用户应该能够通过界面和键盘快捷键在视图之间快速切换。

这只是一个草案，但我希望它能清楚地表达这个想法。

我仍然真的希望这能得到解决。这对组织来说非常重要。

这也越来越多地适用于 Aurelia。 与 Angular 2+ 的结构非常相似。 添加（可配置的）文件嵌套会将一个完整的扩展src文件夹（包含折叠子项）在我们的一个平均项目中减少大约 2/3 的长度。

@RichiCoder1是的，谢天谢地，Aurelia 使用合乎逻辑的、非冗余的命名约定:)
你有没有检查过 aurelia vscode 扩展和它的Open-Related-File命令。 与嵌套没有真正的关系，但它非常有用。

我也很想在一次重命名操作中重命名一个组。

当你开始开发巨大的 angular 应用程序时，这变得非常重要，请考虑引入 vscode，vs 已经拥有它，如果没有，请为我们在 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 什么都不做，也不会给任何人带来问题。 它可以检测可能的嵌套候选对象，并弹出一个警告，询问“看起来您有应该嵌套的文件。您想应用这些默认嵌套配置文件之一吗？”

如果开发人员想要逻辑嵌套，那么可以拥有。 如果他们不想要它，他们只是不添加设置。

用于在my-component.ts (AngularJS 2) 下捕获my-component.A.B ：

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

用于在my-component.ts下捕获my-component.dev.ts my-component.ts ：

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

或者对于生成的文件（使用 Aurelia 导航框架，其中文件生成为dist/ ）：

// 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) = 从第一个 glob 开始的路径）。

我希望得到一些关于是否考虑这一点的信息或反馈。 就目前而言，在包含功能之前，我不会将 VS Code 用于任何 Angular 或 Aurelia 开发。

@threedaysmore没有迹象表明 VSCode 团队真的在考虑它（因为它已经落到积压工作的末尾）。 PR #13754 解决了这个问题，但看起来@playerx已经放弃了它，至少是暂时的。

我创建了一个更新的 PR：#32061。 我正在寻求帮助，因为我对某些事情（即树模型）的处理有问题。

+1

+1

+1

我不确定如何表明我对此功能感兴趣。 +1 似乎不是一个很好的方法，因为它会向线程发送垃圾邮件（并且人们不赞成）。 为 github 问题提供 +1 或“我会喜欢这个功能”的推荐方法是什么，只是为了表明我的兴趣？

只需为第一作者的评论添加拇指，以表明/增加此功能的重要性

@bpassero关闭了我的拉取请求 #32061：“感谢公关，但我们不接受这么大的区域。” （当然，我的拉取请求还处于萌芽状态。）

维护者或其他任何人都可以对此进行扩展吗？ 或者提供有关如何将其作为拉取请求或扩展实施的任何指导？

@firelizzard18我真的很想要这个功能，花了一些时间来研究它并得到了同样的反馈。 我认为他们不想要这个功能是有原因的，但他们没有告诉我们:)

@bpasero
我认为这个功能值得你（来自贡献者）提供更多指导，它可以如何完成，正如你所看到的，有些人可以花时间来实现它。

在 VS Code 中嵌套文件也会很棒。
最近，由于更好的 Angular 支持/集成，我从 VS 2017 更改为 VS Code，用于我的 ASP.NET Core 应用程序的 Angular/前端编程。 它的效果要好得多，但我真的很想念文件嵌套。 :-(

请在 VS Code 中添加文件嵌套功能或给其他人开发扩展的可能性！

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

@bpassero我很好奇我们是否可以从团队那里获得任何更新？ 在过去的几年里，有很多人参与了很多活动； 它被关闭，重新打开，并且已经以最小的方向拒绝了几个实现。 这仍然是所需的功能吗？

React 和 TypeScript 社区有强大的用例，开发人员的情绪一直是积极的（我个人也想肯定这一点）。 再次感谢

@develleoper我认为他们的期望非常明确。 他们希望它完全可定制以被接受。 允许任何不能让您完全控制文件浏览器的内容是没有意义的。 棘手的部分是您必须允许文件创建/移动，而您的 IDE 中的结构可能与物理结构完全不同。 此外，我认为他们希望它允许在多个视图之间切换（例如：您可以拥有文件上下文和单元测试上下文。在其中编写测试，然后切换到另一个以满足它们）。

我很确定他们知道用例，但是如果您查看路线图，您可能会发现他们的计划比这个计划更加雄心勃勃和有用，因此（我猜）这就是为什么他们决定将这个计划留给社区.

我想你非常欢迎试一试——Micro$oft 的绝佳职业机会正在等待勇敢的人;)

“Micro$oft” LUL - 我很惊讶经验有限的青少年竟然会关注这个帖子。

_无论如何_，

@waynebloss IMO，不应将此功能保留为需要新面板的潜在扩展。 这种方法不仅需要使用其所有当前功能重新实现文件树，还需要使用任何未来添加的功能更新它。 是的，当前的文件树代码可以分叉到扩展中，但这并不能减轻跟踪未来功能更新的维护负担。

至少，文件树本身可以授予足够的可扩展性点来实现这一点。 （无论如何，添加并构建扩展以将其用于此功能可能会减少初始工作。）

@RoyTinker同意 - 我认为在正式支持文件嵌套之前，新面板只是一种解决方法。

@Wayofthesin我完全不确定你想达到什么目的。 我认为没有人会认真质疑社区是否需要此功能，因为我们已经非常清楚地表明我们需要。 同样清楚的是，如果你真的读过历史，社区已经试图实现这一点，而开发人员却说“不”。 @playerx提出了一个拉取请求并被告知“不”。 我分叉了他的拉取请求，并在那时合并到了最新的主分支，做了一些调整，然后提交了。 并被告知“不”。

所以很明显社区想要这个并且开发人员没有兴趣接受社区贡献。

@develleoper和其他人，我认为@bpassero对@playerx公关的评论告诉我们很多关于 VSCode 团队想要去的地方： https :

从他的评论中，我了解到@bpassero ：

• 想要一种全面的方法来迎合所有想要某种逻辑观点的群体
• 将文件嵌套视为逻辑视图（而不是物理文件系统视图）
• 相信逻辑视图应该与物理文件系统视图分开

在我看来，虽然文件嵌套 _is_ 是一个逻辑视图更改，文件隐藏也是如此，目前在文件树中支持并且可以通过设置进行配置。 在我看来，文件嵌套只是文件隐藏的另一种形式，只不过它提供了一种显示这些文件的方法。

顺便说一句，Atom 现在通过他们的树视图包支持文件嵌套——参见https://github.com/atom/tree-view/issues/572

@firelizzard18我已经看到了你的拉取请求。 我只是评论了我的想法。 #32061。

@RoyTinker很好地评论了他们的期望。 你可以谈论正在创建公关，但据我所知，@bpassero 的第一个期望都没有得到满足：

独立于 VS，我们自己的项目将所有生成的 MAP 和 JS 文件放入一个 out 文件夹，与 TS 文件不在同一级别，我相信还有其他项目也这样做。 我的观点是，我希望将这些文件嵌套在 TS 文件下，就像它们在同一级别时所做的那样。

作为额外的内容，我要补充一点：不要将虚拟资源管理器视为文件资源管理器。 有人可能想在打字稿文件下嵌套导出的对象。

我想这就是为什么他们不接受 PR 的原因。 他们对修补现有代码不感兴趣。 他们正在寻找不仅可配置而且可扩展的灵活解决方案。 看起来他们自己不知道，但他们几乎知道他们不想要什么。

我看到的问题是我们试图猜测为什么他们不接受 PR 并且没有明确的答案和指导。 你所做的所有评论都是你对@bpassero 的看法的解释。

如此多的对话和贡献者仍然保持沉默，我认为这对产品本身不利。

@Wayofthesin ， @playerx一针见血：我们都清楚@bpasero想要的不仅仅是我们提供的东西，但@bpasero未能提供足够的反馈来明确移动的位置。 就我而言， @bpassero以极其含糊的评论结束了我的 PR。 在@playerx的案例中， @bpassero评论说，“我们目前处于最后阶段，我只能下个月才能回来”，并且在过去的一年半中没有发表任何进一步的评论。

我的公关正在进行中。 我想从开发人员那里获得有关如何前进的指导。 相反，我得到了一个神秘的回应，我的 PR 关闭了。

我的评论，你在你对我的 PR 的评论中提到的，我提出了一个计划来解决@bpassero的问题，但@playerx的方法（缺乏）普遍性。 在我的 PR 中，我开始着手实施其中的一些但不是全部，因为我处于非常陌生的领域并且在继续之前需要指导。

只是在开玩笑。 想稍微提升一下情绪。 请调查此事。 使用这种项目视图真的很难。 它不难但效率低下。

+1，同意，这个功能对微信小程序开发也很有帮助

这太难了？ 大约 200 万 Java 社区成员尽快需要此功能。 请....！！！

VS Code 似乎对在树视图中嵌套虚拟文件有一些支持。 1.29 版的更改日志包括这一点：

这似乎表明已经创建了文件分组的基础。

@MortenChristiansen嗯......这似乎不是同一个功能'

作为建议，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文件，因此它有效地使我们的文件树长度加倍。 我们很乐意将该元数据文件放在源文件下。

我认为收集用户对嵌套功能的要求/需求不是问题。
我不认为实施它是一个问题。 也许一些捐赠将有助于在正式版本中更快地实施它？

盯着我的档案，
打字稿、网页和样式堆积如山。
嵌套会很好。

对不起大家。 看起来他们对这个根本不感兴趣。

兄弟，我也很想看这个。

奇怪 - 此功能的行为非常明确，显然非常需要。

+1 来吧伙计们

这不会发生，所以我可能会关闭这个问题。

@isidorn已经明确表示他们对此不感兴趣，也没有尝试去做。 这是不幸的。 这就是阻止我现在使用 VSC 的全部原因。 如果没有文件嵌套，Angular 应用程序就是如此冗长和凌乱。

我想我现在仍然坚持使用 WebStorm。

我建议让这个问题保持开放，我们可能会在不久的将来解决这个问题。

@isidorn ，鉴于“不久的将来”，您能否就如何实施提供指导？ 我想试一试，但我的 MR 得到了零反馈。

2019，有什么新人吗？

作为一名 Java 开发人员，这是阻止我完全迁移到 vscode 的主要因素。

在我的 java 项目中，java 包命名空间的空目录占用了资源管理器中可用空间的一半（或更多）。 我总是必须在资源管理器中向上/向下滚动，当您必须为每个开发迭代执行这么多次时，这有点耗时。 许多 Java 开发的 IDE 将这些空目录折叠成一个包名，便于开发人员查看整个包结构。

这是否可以在 vscode 中实现但由于其他更高优先级的任务而没有优先级？ 还是由于底层 vscode 架构的限制而无法实现？

任何扩展来执行此操作？ 这是一个非常需要的功能！

开了 3 年多了...看起来他们不会这样做...现在安装 webstorm...

这和缩进粘贴一些非常基本的东西，你觉得它们会得到解决，也许这就是你从免费软件和开源中得到的。 没那么好...因为游戏中没有皮肤。

是的 - 来自其他优秀开发团队的非常令人失望的回应（或缺乏回应）。

我做了自定义嵌套，但我的拉取请求不会被合并。 由于 VS Code 团队有其他计划，不想对那部分代码进行更改。 对我来说，这个功能也很重要，所以我做了自定义的 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$"
        ]
    },

启用嵌套时需要重新启动 vs 代码。

@floatas感谢您的代码！ 你对做扩展有什么看法？

@e-belair 遗憾的是，无法创建扩展。 此功能的 API 不可用。

文件嵌套功能太棒了！ 希望这会发生:)

@floatas公关在哪里？

@tariqporter # 72160

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

由于 VS Code 团队有其他计划，不想对那部分代码进行更改。

那将是#41627，它将首先作为树视图重写的一部分进行处理，这可能会使之后更容易实现。

我认为 VS Code 很棒，但这是它缺乏的基本功能。

也很期待

我需要它

只是好奇是否有任何更新？ 必须清理树视图会很棒！

仍然使用 VS for Mac 只是因为 Blazor 应用程序的此功能。 为什么球队的阻力如此之大？

是否存在跟踪通过它们实现这一点所需的扩展 API 的实现的问题？

4年后，在这个问题上没有进展？ 哦..
老实说，这令人难以置信......

我想不出我使用过的任何 IDE 不以一种或另一种方式支持这一点，也想不出我在任何平台上工作过的任何项目都没有用处...... oO..这到了我只是假设这是在任何 IDE 中给定的...猜不是...

团队只是试图将人们推向竞争对手吗？...
我很想用 VSCode 替换 WebStorm，但我想这不会发生。 然后我们离取代 VS 或 IDEA 还差得很远：S ...

那好吧...

@jeme你认为骚扰开发人员会产生任何影响吗？ 我知道如果我是维护者，我会断然忽略任何反对意见。 如果您真的想要建设性而不仅仅是害虫，请尝试“此功能对我来说非常重要并且阻止我采用此工具。”

@firelizzard18那么您将错过为客户群提供急需的东西。 学会倾听所有客户的意见确实是一个很好的特质，可以说是超越了其他人。 如果您通读这里的评论，就会发现很多人的行为方式应该让他们倾听。 然而，他们没有倾听，并且在 4 年之后，挫败感会很高，特别是如果有人真的想切换但看不到方法，因为项目太大而不能将文件嵌套在一起。 我真的相信 Visual code 是免费软件，没有人真正关心真正将其作为优先事项。 这就是我们用户对要求苛刻的免费软件所得到的。 游戏中没有皮肤让他们做任何事情。 如果这意味着这样的事情会落实到位，我会为 IDE 付费。 再次使用 webstorm（我付了钱）。 他们真的应该出来说我们不会这样做，因此关闭票证并完成它。

如果您通读这里的评论，就会发现很多人的行为方式应该让他们倾听。

你认为敌对会改变事情吗？

我的意思是，一个优秀的商务人士并不关心他们倾听的信息是如何传达的。 因此，如果您忽略这些评论，您就不会成为一个好的商人。 如果您曾在任何一家科技公司的客户支持热线工作，您就会明白这一点。

最后，我的总体结局，如果你读到它是说，不管怎样，好（之前的评论很好）或不好（你正在讲的评论）都没有关系，他们不会这样做，因为他们在游戏中没有皮肤它是免费软件。 确实是一个有争议的问题，他们应该关闭票证。

我们能否将评论部分的重点放在可能的解决方案和见解上，而不是抱怨为什么这个问题还没有解决？ 向您传达此问题的影响的一种方法是对问题描述进行

谢谢

有一个公开的 PR (#13754) ...
如果有人正式宣布分叉并建立一个基本的静态站点，其中包含适用于 windows 苹果和 linux 的二进制文件……也许一夜之间会有 1000 名 Angular 开发人员扑向它，如果某处有一个捐赠按钮，你也可以赚一些钱为了努力。
我个人现在不需要这个功能，但是 VSCode 是在 MIT 许可下的，社区真的想要一个功能，社区的一些成员真的很努力地实现了这个功能。
所以...

也许他们也可以修复#75181！ 仅显示资源管理器面板不应导致打开任何文件选项卡。

@BrunnerLivio你抱怨抱怨太有趣了；)。 这开始是因为有人想纠正或将他们的道德行为强加给其他人，因为他们是如何表达他们的不满、需要或投票的。 你也在做同样的事情。 同样，这是免费软件，这个问题不会消失。 4年没有了。 每个人都在谈论“他们”，这是免费软件。 他们是这个论坛上的人，这是我大约一年前意识到的。 我工作太多了，没有时间做这个增强，宁愿为 IDE 付费，这就是我对 webstorm 所做的。

就我个人而言，我认为拥有它会很好，但我不会为它而烦恼任何人
因为你知道它基本上是免费的，所以并不是有人要求他们遵守服务级别协议或支付支持费用。 由于“客户”一词意味着购买的产品

所以替代方案是

1. 有人分叉源，添加功能，发出拉取请求，然后要求他们包含它
2. 作为另一种选择，可以尝试 Visual Studio 2019 Community，它也是免费的（但不是开源的），因为它具有嵌套
3. 使用其他东西直到它被添加

我认为另一种选择：

使用自己的侧边栏按钮和面板构建一个模仿 Explorer 树的扩展并使用它。

我这样做了。

pt., 7.02.2020, 02:15 użytkownik Hecatron通知@github.com
纳帕萨乌：

就我个人而言，我认为拥有它会很好，但我不会打扰任何人
超过它
因为你知道它基本上是免费的，所以好像没有人持有它们
服务水平协议或支付支持费用。 既然这个词
“客户”表示购买的产品

所以替代方案是

1. 有人分叉源，添加功能，发出拉动
   请求，然后要求他们包括它
2. 作为另一种选择，可以尝试 Visual Studio 2019 Community
   也是免费的（但不是开源的），因为它有嵌套
3. 使用其他东西直到它被添加

—
您收到此消息是因为您订阅了此线程。
直接回复本邮件，在GitHub上查看
https://github.com/microsoft/vscode/issues/6328?email_source=notifications&email_token=ACJ4R34R3CWQNAAMHTCOP2TRBSY3TA5CNFSM4CDVJHV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXZHJK85BMDNCGWWWZissueQ85BMDNCGWWZHJK85BMM5CWQNAAMHTCOP2TRBSY3TA5CNFSM4CDVJHV2YY3PNVWWK3
或取消订阅
https://github.com/notifications/unsubscribe-auth/ACJ4R3YUKMXFVOO5NSXSQ6DRBSY3TANCNFSM4CDVJHVQ
.

一些提前！ 我觉得在vscode中很有必要！！

VS Code 是免费产品，Visual Studio 完整版是付费产品

@GeorgeTarazi根据您的评论，我假设您从未使用过 VSCode 或从未使用过 Visual Studio。 因为如果你用过两者，你就会知道它们是完全不同的产品。 Visual Studio 绝不是 VSCode 的“完整版”。

没有人希望不断收到有关您的偏离主题的意见的通知。 也许存储库维护者现在应该考虑锁定关于这个问题的讨论。

我个人发现 Visual Studio 2019 社区（免费）版足以满足我需要做的一切
与过去的旧 Pro/Enterprise 版本相比。
例如，当您从 MS 试图将 dotnet 推为 Java 的开源替代品的角度来看时，这是有道理的。
尽管从商业角度来看，您仍然可能需要许可证才能使用 Studio 2019。

我确实将 Studio 2019 和 VSCode 用于不同的用例。 VScode 我更喜欢 python，Studio 2019 我更喜欢 dotnet。
VSCode，如果我正在研究一些开源等。
编译器不是共享的，至少不是 dotnet，因为那是一个单独的外部工具 btw。
两者都是用不同的语言编写的，VSCode - Javascript，Studio 2019 可能是 C# 和 CPP 的组合。

我猜这个功能还没有被移植的原因是以太

1. 他们的目标是首先实现一些其他功能，例如与扩展相关的内容或首先需要的依赖项
2. 不同的团队，不同级别的资源
3. 需要从头开始编写，不能在不同语言之间复制粘贴。

@georgebatalinski我同意你所说的大部分内容。 但是，我会说我发现可视化代码对 angular 比 Visual Studio 更有用，它特别是为了对前端水疗中心更友好。 我从 90 年代开始使用 VS 产品，所以我可能比你年长；) 我可以追溯到 vb 时代，甚至 Qbasic。 我个人厌倦了 me me me 的东西，免费给我。 我很乐意为可视化代码付费以特别获得此附加功能。 但是我仍然没有使用 VC，因为我觉得这个功能对于我眼中的大型应用程序来说是必要的。

这个功能会实现吗？
我发现它在处理 Web 项目时非常有用，因为有很多生成的文件使工作区混乱（但有时您需要查看它们，因此隐藏不是解决方案）。

为什么不让用户选择禁用/启用它，并选择哪些扩展触发它？！ :-)
实现起来似乎很简单......

@funder7不是很快。 开发人员表示他们对 VS Code 应该如何运作有不同的意识形态，所以这并不是一个优先事项。

谢谢@tmarkovski ，我现在正在使用它来删除生成的文件rm -f *.js *.map ...顺便说一下，我在 IntelliJ Idea 中发现了该功能，它在处理复杂项目时非常方便。
如果这不是开发人员查看应用程序的方式，至少我会默认禁用它，但将启用它的选项留给最终用户。
我提到 Idea 是因为这种功能对我来说是辅助软件和您最喜欢的软件之间的区别。

其实我发现这个

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

隐藏生成的文件，但随后它们消失了，您没有注意到它们的存在：/

4年多了，这在软件领域是永恒的，还没有实施的计划吗？ 通过减少扫描巨大文件树结构时的心理负担，这对生产力来说是巨大的。 允许单独的 Typescript 接口文件，而无需在资源管理器中显示其他文件。

此功能有任何进展吗？

此功能有任何进展吗？

上周，vscode 团队成员关闭了重复问题，因此他们知道它但选择忽略它。
真的很想知道为什么。

真的很想知道为什么。

因为这不是他们的优先事项。 作为一个团队，他们决定优先考虑其他事情。 你可以不同意他们的决定，但所有这些“天啊whhhhhy ”的抱怨都是令人讨厌和毫无意义的。

因为这不是他们的优先事项。 作为一个团队，他们决定优先考虑其他事情。 你可以不同意他们的决定，但所有这些“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 并复制/粘贴它
因为它已经在显示类似于主文件浏览器的子目录中的文件
不同之处在于它的目的是模拟 VStudio 2019 的视图，而不是进行文件嵌套。

用于说明应包含哪些文件扩展名的设置将类似于我上面提到的 .filenesting.json 或其他一些与 json 相关的文件。

真的很想知道为什么。

因为这不是他们的优先事项。 作为一个团队，他们决定优先考虑其他事情。 你可以不同意他们的决定，但所有这些“OMG _whhhhhy_”的抱怨都是令人讨厌和毫无意义的。

您确实意识到您遇到了_功能请求_问题，对吗？ 你会在其他任何地方，但这是请求和谈论它的_实际_正确的地方（这不是毫无意义的抱怨）。 如果他们认为人们很快乐并且不需要它，那么它永远不会成为优先事项。

我将解释为什么我需要“虚拟文件夹”：我正在使用通过 makefile 配置的 C 代码库，我不能冒险更改它。 然而，代码一团糟，我还有其他代码库要维护同样的问题。

我需要在虚拟目录中虚拟排列文件以保持我的理智，并且可以在：Code::BLocks、Programmers Notepad（是的）中做到这一点。 但我不能在 VS Code 中。

对于无法控制如何在文件夹中组织文件的人来说，这是必须的，这在许多组织中很常见。 这不是关于“让它更漂亮”。

结果：我使用 VS Code 的效率要低得多。 我希望我可以使用它，但这只是一个较慢的工作流程。

我希望团队改变主意，我不认为这应该由插件来处理，即使它在技术上可以。 我不想依赖插件提供商来满足这样的核心需求，而在可能会破坏的东西上投入时间。

我知道这不是优先事项，我只是问，如果您希望更多用户能够使用 VS Code 并提高工作效率，请在未来考虑。

@grbd我很乐意提供帮助，但这似乎有很多工作，不确定我是否有那么多时间。
我更新了自定义文件嵌套 fork 以匹配今天的 master。 如果有人需要文件嵌套的起点，还可以添加二进制文件来尝试一下。
https://github.com/floatas/vscode