Vscode: File Nesting

fyi @bpasero

The most ideal scenario for this is that anything that starts with the same text as a parent file, minus the extension gets nested, like this;

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

No plans at the moment. Closing until we reconsider this.

This is important feature for large projects. I'm using asp.net vNext for Angular project and now I've following structure automatically (by naming):

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

In VS Code Explorer I got:

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

Creating folders for each component is bad solution for angular project (you will need to change references).

We need this feature to move to VS Code.

Agree, at least ts + js + map files (for instance like webstorm does)

It would be great to have file nesting for ts + js + map + style.

Currently we are hiding the .js and .map files which makes checking them an annoyance. Even with just ts + css, the sidebar still feels bloated.

Agree I wish file nesting like this (especially for ng2)

Html
--css
--ts
-- etc ...

Please reconsider this! This is such an important issue.

Theres so many cases where generated files just clutter the workspace. Typescript! Typescript which you use as well! is a prime example. Or LESS/SASS -> css. Or Jade -> Html

There is the option to conditionally hide the generated files. For example:

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

This same principal could be applied to your css and map files.

And i am using that option. The problem arises when i want to see the
hidden files. Also its not clear whether the hidden files are actually
there (that the generation is working...), which makes me open the folder
in explorer where the files are also not grouped... another thing is that
some of my collegues arent comfortable with not seeing half the files in
the project and we would like to use the same settings for the whole team.

For some reason most other editors deemed this feature useful enough to
implement it so why not vs code.

I would like to note that this is really not a complicated feature. Im
pretty sure it can be done in a day. (I was thinking about making a pull
request but it might require some small changes to the architecture around
FileStat)

On Sunday, September 25, 2016, Andrew Sheehan [email protected]
wrote:

There is the option to conditionally hide the generated files. For example:

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

This same principal could be applied to your css and map files.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/6328#issuecomment-249392536,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABzUP4LXESXZpGtY1iFZJmmy9J10k4-Uks5qta2DgaJpZM4IdUnr
.

+1

any extension that may do the job?

Why is this closed? It's not implemented and would be a great feature.

@uxsoft

For some reason most other editors deemed this feature useful enough to
implement it so why not vs code.

Maybe because they need a reason for people to use the real visual studio :-)

This should have not been closed, reopening. Though there might exist duplicates meanwhile.

@stevencl @chrisdias @seanmcbreen @egamma fyi we need some PM steering and guiding here if we want to turn the file explorer into a logical view. An initial PR was created by @playerx in https://github.com/Microsoft/vscode/pull/13754

My 2 cents at the moment: we should think about a solution for the scenarios our users want to solve and my feeling is that only supporting to show similar files in the same level below a root file is not enough. People may want something powerful as the solution explorer in VS.

@bpasero, my apologies, but question you asked is not correct. there are two different kind of features:

N1. Turn the file explorer into a logical view
Example: you can link fileA ("directoryX/fileA"), to fileB, which is placed in directoryY

N2. Give file explorer support to show real files with more elegant way and give developers ability to enable this feature, example:

Feature N1 and Feature N2 are not the same, it's very important part here, they don't cover each other.

Thanks

@playerx I brought up the solution explorer because the description of this issue a reference to Visual Studio 2015 is made and to my knowledge there is only the solution explorer.

Independent from VS, our own project is putting all generated MAP and JS files into a out folder, not on the same level as the TS files and I am sure there are other projects that do the same. My point is that I would expect to nest those files under the TS files in the same way you do it when they are on the same level.

To me, nesting is not about grouping files with the same extension together, it is about showing files together that logically belong together (aka "derived resources"). Does that make sense?

@playerx N2 looks much better. For the angular 2 cli users, this should not require that naming convention. Maybe there could be some configurable pattern like in the hide files configuration.

Angular2 cli creates files like this:

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

@mbeckenbach good example, thanks

@bpasero nesting generated files, under TS files is great example, thanks

I want to ask everyone, let's put every possible practical example here (not theoretical please), that we would use in every day life and let's make solution based on that examples.

Let's the question be:
How to make Explorer "smarter" to visualize real picture of files structure, with more elegant way?

@bpasero okey? I'm still trying not to mix Feature N1 and Feature N2.

Scenario 1:
before:

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

after (option 1):

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

after (option 2):

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

after (option 3):

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

Scenario 2:
before:

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

after:

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

@playerx One addition: it also generates this file: my.component.spec.ts

I had hidden the spec files as i don't unit test demo projects. :-)

thanks, updated Scenario 1, please select which after option you would choose to use

Scenario 1 Option 1 would fit the best in my opinion.

1. An angular 2 component can exist without the html file (inline templates)
2. Would allow additional file names like for example my.component.animations.ts if the angular team decides to extract more parts into several files someday

Scenario 1, Option 1 ftw! +1 because of angular2 naming conventions

@seveves I definitely want to have this feature but I have to say that Angular 2’s naming conventions are just terrible. Supporting this feature should not be based on a framework specific arbitrary style guide that dictates naming conventions based on the need for developer ergonomics under pre ES Module build tools that are no longer relevant to the framework that is even using them. Again I want to see support for this feature but I think that is the wrong reason.

@aluanhaddad - not to get too off topic here, but do you have an example of what would be a better naming convention for the 4 files specified in the scenarios?

All of the files are named the same outside of the extension (+.spec file), which is obviously not angular2 specific. The question posed is what is the priority ordering of the extensions with similarly named files: which would be considered the primary to group under.

I think with this scenario (client side types), the priority would be: TS, JS, HTML, [style types]. You'd always have a TS or JS file, but not necessarily a template or styling

This would be really neat!!

@playerx commented on Oct 15 2016 • edited

For the suggestion:

N1. Turn the file explorer into a logical view
Example: you can link fileA ("directoryX/fileA"), to fileB, which is placed in directory

I am pretty sure this is available in any current OS; windows has supported "Junctions" for a few releases now, and even has a MKLINK command now.

Given that, I don't see an actual need for the N1 option, and I would recommend ciel's comment (commented on May 13 2016) of nesting based on extension.

How about using a configurable rule set more or less like:

"*.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"
]

Another option is using RegEx patterns instead.

This would nest the files matching the patterns in the order specified by the patterns. This opens up a wide set of configuration options, it's not limited to the Angular 2 convention (not even limited to ts/js/html) and provides predictability and consistency.

I think introducing solution views like in Visual Studio adds unnecessary complexity to VSCode and makes it lose its lightweight editing experience.

@aluanhaddad - not to get too off topic here, but do you have an example of what would be a better naming convention for the 4 files specified in the scenarios?

Really, I wouldn't change much from a logical point of view

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

would become

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

😆
because it bloody obvious it is a component...

I was objecting to John Papa's Angular 2 naming conventions. I object to his naming of components, pipes, services, modules, and the rest of the the redundant nonsense. He came up with those conventions for Angular 1 when he was using Grunt configurations to bundle manually IIFE wrapped modules, controllers, services, and directives (all of these was a decent idea at the time). The suffices were to enable bundling and other Grunt tasks to load all of the .module files first so the scripts that registered controllers, services, and so on didn't explode on load.

That said his Angular 1 style guide was almost flawless in every other regard, and these scenarios were relevant at the time, but his Angular 2 style guide (the official one) is terrible. Then again, who could write an elegant style guide for something that inherently ugly?

I think that File Nesting is a must in modern development, specially web development...

Please, please... consider supporting it.

It sounds like what we really want in here is custom configured logical view system next to physical explorer.

Lets imagine we have a project with structure (It is complicated intentionally):

- 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

We need some logic explorer that allows us to define how to group file and how to display it. Groups might be nested so we end up having view that is not related to folder structure. Let's imagine such a logical view config:

{
    "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
        }]
    }]
}

Within this view our files should be displayed as:

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

Note that in current example spec files are hidden completely. It is made to make user focus on code. In such a case user would have separate logical view which would present him unit tests in the way he likes. It should be configurable at workspace, user and extension level. User should be able to quick switch between views both from interface and keyboard shortcuts.

This is just a draft but I hope it presents the idea clearly.

I'm still really hoping this gets worked in. It is very important to organization.

This also is increasingly applying to Aurelia too. Very similar structure to Angular 2+. Adding (configurable) file nesting would cut a full expanded src folder w/ collapsed children on one of our average projects by about a 2/3rds in length.

@RichiCoder1 yes indeed and, thankfully, Aurelia uses logical, non-redundant naming conventions :)
Have you checked out the aurelia vscode extension and its Open-Related-File command. Not really related to nesting but it is very useful.

I would also love renaming a group in a single rename operation.

This is becoming a super important as you start working on huge angular app, please consider this to bring in vscode, vs already have it, if not, please bring similar experience for file nesting we have in vs

Man, this would really make the Angular application I'm working on so much less cluttered and obtuse. I sincerely hope you guys are seriously considering this.

As I said in another issue ..

The biggest reason I want this is for angular, where I have many similar named files together;

/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

If it could nest those, it'd be just great.

I also do Command/Mediator pattern, and so I end up with files that look like ...

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

It gets pretty verbose and this feature would just make my day.

This is the only reason I'm still using WebStorm...

Yes, us too.

On Jun 2, 2017, at 10:10 AM, MigFerreira notifications@github.com wrote:

This is the only reason I'm still using WebStorm...

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Dumb question: Can somebody provide a screenshot how it looks like? I can't imagine what's the sense behind it.

Ah, okay, thanks.

This has now become the biggest missing feature for us. I have coworkers who will not use it due to it not having this feature. It's a real pain when you are trying to find one particular file when so many have similar names. We tried adding more subfolders for each component (Angular), but that's not an ideal solution and we reverted back to just listing all of the components under feature (and sub feature) folders.

I'm introducing TypeScript and Angular to a large Dojo project, and I can say this feature will become very important for VSCode users on our team in the next several months.

I'm currently working on an Angular project and being able to group related files would be an excellent addition to an already excellent product. As the Angular project grows, the more difficult it becomes to navigate and currently hinders productivity.

Repeated from #13754:

IMO, the most elegant solution would be to leave it up to the project. As in .vscode/settings.json or maybe project.json. Use something like the file exclusion syntax. This would allow for per-project or per-folder customization. Framework/tool maintainers, or VSCode, or a third party could distribute pattern sets for given workflows.

This way, VSCode assumes nothing and causes issues for no one. It could detect possible candidates for nesting, and pop up an alert asking, "It looks like you have files that should be nested. Do you want to apply one of these default nesting profiles?"

If developers want logical nesting, then can have that. If they don't want it, they just don't add the settings.

For capturing my-component.A.B under my-component.ts (AngularJS 2):

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

For capturing my-component.dev.ts under my-component.ts:

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

Or for generated files (using the Aurelia navigation skeleton where files are generated into 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)"}
}

With some well-defined syntax like this, I could add whatever nesting scheme I wanted, as long as it's not excessively complicated. The last example is based on gulp's handling of paths ($(path) = the path starting with the first glob).

I would love some info or feedback on if this being considered or not. As it stands now, I won't be using VS Code for any Angular or Aurelia dev until it's an included feature.

@threedaysmore There is no indication that the VSCode team is really considering it (as in, it has fallen to the end of the backlog). PR #13754 addresses it but it looks as though @playerx has dropped it, at least temporarily.

I created a more up to date PR: #32061. I am looking for help as my handling of some things (namely tree model) is buggy.

+1

+1

+1

I am not sure how to show that I am interested in this feature. The +1, doesnt seem to be a very good way as it will spam the thread (and people gives it a thumbs down). What are recommended ways of giving a +1 or "i would love this feature" to a github issue, simply to show my interest?

Just add thumb up for the first author's comment, to indicate/increase importance of this feature

@bpasero closed my pull request #32061: "Thanks for the PR, but we do not accept it for this large area." (Granted, my pull request was pretty embryonic.)

Can a maintainer or anyone else expand upon this at all? Or provide any guidance on how this could be implemented as a pull request or extension?

@firelizzard18 I wanted this feature really hard, spent some time working on that and got same feedback. I think there is some reason why they don't want this feature, but they aren't telling us :)

@bpasero
I think this feature deserves more guidance from you (from contributors), how it can be done and as you can see there are people who can spend their time to make it happen.

Would be great to have file nesting in VS Code too.
Recently I changed from VS 2017 to VS Code for Angular/frontend programming for my ASP.NET Core app, because of better Angular support/integration. It works much better, but I'm missing file nesting really hard. :-(

Please add file nesting feature to VS Code or give others the possibility to develop an extension!

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

@bpasero I'm curious whether we can get any updates on this from the team? There's been a lot of activity from multiple folks over the course of several years; it was closed, reopened, and has had several implementations rejected with minimal direction. Is this still desired functionality?

There are strong use-cases for the React and TypeScript communities, and developer sentiment has been consistently positive (which I'd like to affirm, personally as well). Thanks again

@develleoper I think they made their expectations pretty clear. They want it to be fully customizable to be accepted. It doesn't make sense to allow anything that does not give you full control over the file explorer. The tricky part is that you have to allow file creation/moving around while the structure in your IDE might be completely different from physical one. Also I think they expect it to allow switching between multiple views (e.g.: you can have file context and unit tests context. Write tests in one and then switch to another to satisfy them).

I'm quite sure they are aware of use-cases but if you look at the road map you might see that their plans are far more ambitious and useful than this one so that's (I guess) why they decided to leave this one for community.

I guess you are more than welcome to give it a go - great career opportunity at Micro$oft is waiting for the brave one ;)

"Micro$oft" LUL - I'm surprised that limited-experience pre-teens are following this thread at all.

_Anyway_, @develleoper - they (Microsoft) recently added the ability to let extension makers add their own panel on the side, so when that is released soon some extension maker will probably make an extension to show a logical file tree instead of a physical one.

@waynebloss IMO, this feature shouldn't be left as a potential extension requiring a new panel. That approach would not only require re-implementing the file tree with all its current features, but also updating it with any future features that are added. Yes, the current file tree code could be forked into an extension, but that doesn't diminish the maintenance burden of tracking future functionality updates.

At the very least, the file tree itself could grant sufficient extensibility points to implement this. (Adding that and building an extension to utilize it for this feature would probably be less initial work anyway.)

@RoyTinker agreed - I was thinking that a new panel would just be a workaround until file-nesting was officially supported.

@Wayofthesin I'm not sure at all what you're trying to get at. I don't think anyone is seriously questioning whether the community wants this feature, as we have made it abundantly clear that we do. And what's equally clear, if you actually read the history, is that the community has tried to implement this and the devs have said "No". @playerx made a pull request and was told "No". I forked his pull request and merged in the newest master branch at that point, made some tweaks, and submitted that. And was told "No".

So it should be quite evident that the community wants this and the devs have no interest in accepting a community contribution for it.

@develleoper & others, I think @bpasero's comments on @playerx's PR tell us a lot about where the VSCode team wants to go with this: https://github.com/Microsoft/vscode/pull/13754

From his comments, I understand that @bpasero:

• wants a comprehensive approach that would cater to all groups who want a logical view of some sort
• thinks of file nesting as a logical view (as opposed to a physical, file-system view)
• believes a logical view ought to be separate from a physical, file-system view

In my opinion, although file nesting _is_ a logical view change, so is file hiding, and that is currently supported in the file tree and is configurable via settings. It seems to me that file nesting is just another form of file hiding, except that it provides a way to reveal those files.

As an aside, Atom now supports file nesting via their tree view package -- see https://github.com/atom/tree-view/issues/572

@firelizzard18 I have seen your pull request. I just commented my thoughts. #32061.

@RoyTinker pretty well commented what do they expect. You could talk about PR being created but as far as I can see not even the very first expectation from @bpasero has been met:

Independent from VS, our own project is putting all generated MAP and JS files into a out folder, not on the same level as the TS files and I am sure there are other projects that do the same. My point is that I would expect to nest those files under the TS files in the same way you do it when they are on the same level.

As an extra I would add: Do not think of virtual explorer as of file explorer. Someone might want to nest exported objects under typescript file.

I guess that why they did not accept the PRs. They are not interested in patch over existing code. They are looking for flexible solution that is not only configurable but extendible as well. It looks like they do not have idea over it themselves but they pretty much know what they do not want.

Problem I see is that we try to guess why they don't accept PR and there is not a clear answer and guidance. All the comments guys u made are your interpretations what @bpasero thinks about it.

So many conversations and still silence from contributors, I think thats not good for product itself.

@Wayofthesin, @playerx hit the nail on the head: we are both clear on the fact that @bpasero wants something more than what we're providing but @bpasero has failed to provide enough feedback to make it clear where to move. In my case, @bpasero closed my PR with an extremely vague comment. In @playerx's case, @bpasero commented, "We are in end game currently, I will only be able to come back to this next month," and hasn't made any further comments in the last year and a half.

My PR was a work in progress. I wanted guidance from the devs on how to move forward. Instead I got a cryptic response and my PR closed.

My comment, which you referenced in your review of my PR, I suggested a plan for addressing @bpasero's issues with the (lack of) generality of @playerx's approach. In my PR, I started working on implementing some but not all of this, as I was in very unfamiliar territory and wanted guidance before moving forward.

Just kidding. Wanted to raise the mood a bit. Please investigate into this. Its really hard to work with this kind of project view. Its not hard but inefficient.

+1, Agree, this feature will very helpful for wechat mini app development, too

Is this too hard to do? About 2 Million Java Community members need this feature ASAP. PLEASE....!!!

It seems that VS Code has some support for nesting virtual files in the tree view. The change log for version 1.29 included this point:

This seems to indicate that a foundation for file grouping has been created.

@MortenChristiansen mmm... It‘s seem not the same feature’

As a suggestion Visual Studio 2017 has a feature for file nesting via a .filenesting.json configuration file. Perhaps something similar in terms of a config file could be implemented for VSCode

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

As an example:

{
  "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"
          ]
        }
      }
    }
  }
}

bump 🏗

would be good for auto-generated files in dart too.

This would be helpful for the Salesforce extensions as well. Our projects have a *.meta.xml file associated with every code file so it effectively makes our file tree double the length. We would love to put that metadata file under the source file.

I don't believe it is an issue to gather requirements/needs of users about the nesting feature.
I don't believe it is an issue to implement it. Maybe some donation will help to implement it faster in official releases?

Staring at my files,
Typescript, web, and styles stacked high.
Nesting would be nice.

Sorry guys. Doesn't look like they're interested in this at all.

Man, I'd love to see this as well.

Bizarre - the behaviour of this feature is very well defined and it's clearly much needed.

+1 Come On guyss

This isn't happening guys so I'll probably close the issue.

@isidorn has made it clear that they aren't interested in it, and aren't trying to do it. Which is unfortunate. This is all that stops me from using VSC now. An Angular application is just so verbose and messy without file nesting.

I guess I'm still stuck with WebStorm for now.

I suggest to keep this issue open we might address this in the not so near future.

@isidorn, given “not so near future”, are you able to provide guidance on how this should be implemented? I would like to take a stab at it, but I got zero feedback on my MR.

2019, anything new guys?

As a java dev, this is the main thing that keeps me from migrating fully to vscode.

In my java projects, empty directories for java package namespaces are taking half (or more) of the available spaces in the explorer. I always have to scroll up/down in explorer which is kind of time-consuming when you have to do so many times for each dev iteration. Many IDEs for java development collapse these empty directories into a single package name, making it easy for devs to look at the whole package structure.

Is this something that is feasible to implement in vscode but not prioritized due to other higher prioritized tasks? or is this just not possible to implement due to limitations in underlying vscode architecture?

Any extension to perform this? It is a much needed feature!

Opened over 3 years... doesn't look like they are going to do it... Installing webstorm now...

this and indenting with pasting some very basic things you feel they would be addressed maybe that is what you get for freeware and open source. Not as good... Since no skin in the game.

Yes - very disappointing response (or lack of) from an otherwise excellent dev team.

I made custom nesting, but my pull request won't be merged. As VS code team has other plans and don't want to make changes to that part of code. For me this feature is also important, so I made custom Vs Code build (extension store works) you can give it a try https://github.com/floatas/vscode/releases/tag/1.37 Will see how progress goes on this issue, I'm considering making something similar as VsCodium (auto builds with updater) but with my changes.

Just add this config to your settings.json:

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

Vs code restart is needed when enabling nesting.

@floatas Thanks for your code! What you think about making an extension?

@e-belair Sadly it's not possible to create extension. API for this feature isn't available.

File nesting feature would be so sweet! Hope this will happen :)

@floatas Where is the PR?

@tariqporter #72160

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

As VS code team has other plans and don't want to make changes to that part of code.

That would be #41627, which will be worked on first as part of the treeview rewrite, which should probably make this easier to implement afterwards.

I think VS Code is just great but this is such a basic feature for it to be lacking.

Looking forward to it as well

i need it

Just curious if there is any update on this? Would be great to have to clean up the tree view!

Still using VS for Mac just because of this feature with Blazor apps. Why so much resistance from the team?

Is there an issue to track the implementation of the extension APIs required to make this possible through them?

4 years later and no progress on this issue? o.O...
This is mind-boggling to be honest...

I can't think of any IDE's that I have used that doesn't support this in one way or another, nor can I think of any projects on any platform I have worked on where this would not be useful... o.O... This to a point where I just assumed that this was a given in any IDE... guess not...

Are the team just trying to push people towards competitors?...
I would have loved to replaced WebStorm with VSCode, but i guess that's not happening. And then we are no where near replacing VS or IDEA :S...

Oh well...

@jeme Do you imagine that harassing the developers is going to have any effect? I know if I was a maintainer, I would categorically ignore any antagonistic comments. If you actually want to be constructive and not just a pest, try "This feature is very important to me and is keeping me from adopting this tool."

@firelizzard18 then you would be missing out on providing a customer base something is sorely needed. Learning to listen to all customers is truly a great trait to have, rising above the frey so to speak. If you read through the comments here there are plenty of people behaving in the way that you say should get them to listen. However, they are not listening and after 4 years frustrations will run high especially if someone truly wants to switch but can't see a way because the project is too large not to have the files nested together. I truly believe Visual code is freeware and no one really cares to truly make this a priority. And that is what we users get for demanding free software. There is no skin in the game for them to do anything. I pay for an IDE if it means things like this would get put into place. Again still using webstorm (which I paid for). They really ought to just come out and say we aren't going to do it therefore closing the ticket and be done with it.

If you read through the comments here there are plenty of people behaving in the way that you say should get them to listen.

And you think being antagonistic is going to change things?

What I am saying is a good business person doesn't care how the message gets across they listen. So you would not be a good business person, if you would ignore those comments. If you ever worked on a customer support line for any tech company you would understand this.

Finally, my overall ending, if you read it was saying, either way, it doesn't matter nice (by previous comments being nice) or not nice (the comment you are lecturing on) they aren't going to do it because they have no skin in the game it is freeware. Really is a moot point and they should close the ticket.

Can we focus the comment section on possible solutions and insights, rather than complaining about why this issue has not been resolved yet? A way to communicate the impact of this issue for you is by using the voting on the issue description.

Thank you

There is an open PR for this (#13754)...
If someone would officially declare a fork and set up a basic static site with binaries for windows apple and linux... perhaps a couple 1000 angular devs would pounce on it overnight, and if there's a little donate button somewhere you could also make some money for the effort.
I personally don't need this feature right now, but VSCode is under the MIT license, the community really wants a feature, and some members of the community have worked really hard implementing this feature.
So...

Maybe they can fix #75181 too! Simply displaying the Explorer panel should not cause any file tabs to be opened.

@BrunnerLivio you complain about complaining too funny ;). This started because someone wanted to correct or enforce their moralistic behavior onto someone else on how someone communicated their displeasure, need, or vote. You are doing the same. Again, it is freeware this issue is not going anywhere. It hasn't for 4 years. Everyone is talking about "they" this is freeware. They are the people in this forum is what I realized, about a year ago. And I work too much to have time to make this enhancement and would rather pay for the IDE, which is what I do with webstorm.

Personally I think it'd be a nice to have but I wouldn't hassle anyone over it
since it's ya know basically free, it's not as if anyone is holding them to an service level agreement or paying moneys for support. Since the word "customer" implies a purchased product

So the alternatives are

1. someone to fork the source, add in the features, issue a pull request, then ask them to include it
2. As another option maybe try Visual Studio 2019 Community which is also free (but not open source) since that has nesting
3. Use something else until it gets added in

One other alternative I think:

Build an extension that mimics the Explorer tree with it's own sidebar button and panel and use that.

And I did so.

pt., 7.02.2020, 02:15 użytkownik Hecatron notifications@github.com
napisał:

Personally I think it'd be a nice to have but I wouldn't hassle anyone
over it
since it's ya know basically free, it's not as if anyone is holding them
to an service level agreement or paying moneys for support. Since the word
"customer" implies a purchased product

So the alternatives are

1. someone to fork the source, add in the features, issue a pull
   request, then ask them to include it
2. As another option maybe try Visual Studio 2019 Community which is
   also free (but not open source) since that has nesting
3. Use something else until it gets added in

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode/issues/6328?email_source=notifications&email_token=ACJ4R34R3CWQNAAMHTCOP2TRBSY3TA5CNFSM4CDVJHV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELBMCGQ#issuecomment-583188762,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACJ4R3YUKMXFVOO5NSXSQ6DRBSY3TANCNFSM4CDVJHVQ
.

algun avance de esto!! creo que es muy necesario en vscode!!

VS Code is a free product and Visual Studio the full version is a paid product

@GeorgeTarazi Based on your comment, I'm going to assume you've never used VSCode or you've never used Visual Studio. Because if you had used both, you would know that they are completely different products. Visual Studio is in no way the 'full version' of VSCode.

No one wants to keep getting notified about your off-topic opinions. Maybe the repository maintainers should consider locking discussion on this issue for now.

Personally I've found Visual Studio 2019 Community (free) edition good enough for everything I need to do
compared to the old Pro / Enterprise versions of past.
This makes sense when you look at it from the point of view of MS trying to push dotnet as an open source alternative to java for example.
Although you'll still likley need a licence to use Studio 2019 from a business perspective.

I do use both Studio 2019 and VSCode though for different use cases. VScode I prefer for python, Studio 2019 I prefer for dotnet.
VSCode if I'm working on something open source etc.
The compiler isn't likley shared at least not for dotnet as that's a seperate external tool btw.
Also both are written in different languages, VSCode - Javascript, Studio 2019 probably a combination of C# and CPP.

I'd guess the reason the feature hasn't been ported across yet is ether

1. They're aiming to implement some other feature first such as something related to the extensions or a dependency that's needed first
2. Different team, different level of resource
3. Needs to be written from the ground up, can't copy paste between different languages.

@georgebatalinski I agree with most of what you are saying. However, I will say I find visual code useful for angular more than visual studio, It specifically went out of it's way to be more developer friendly for front end spas. I been using VS products since the 90s so I am probably older than you ;) I date back to vb days even Qbasic. I personally am tired of the me me me thing, give me it for free. I be happy to pay for visual code to get this added feature in particular. But again I am still not using VC because I feel this feature is just necessary for larger scaled apps in my eyes.

Will this feature be implemented?
I find it quite useful when working with web projects, as there are lots of generated files that clutter the workspace (but sometimes you need to look at them, so hiding is not a solution).

Why not leaving to the user the choice to disable/enable it, and choose which extensions trigger it?! :-)
It seems so simple to implement....

@funder7 Not very soon. The devs have expressed they have different ideological take on how VS Code should function, so this isn’t exactly a priority.

Thanks @tmarkovski, I'm using this now to remove the generated files rm -f *.js *.map... By the way I discovered that feature into IntelliJ Idea, it's very handy when working with complex projects.
If that's not in the developer way of seeing the app, at least I would keep it disabled by default, but leaving to the end user the option to enable it.
I mentioned Idea because this kind of features for me are what makes the difference between a secondary software and your favourite one.

Actually I've found that this

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

hides the generated files, but then they disappear and you don't notice their presence :/

It's been more than 4 years, which is an eternity in software land, and still no plans to implement this? This is huge for productivity by reducing mental load when scanning through a huge file tree structure. Allows for separate Typescript interface files without the burden of additional files appearing in the explorer.

Any progress for this feature?

Any progress for this feature?

Duplicate issue was closed by a vscode team member last week, so they are aware of it but choosing to ignore it.
Really struggling to see why.

Really struggling to see why.

Because it's not a priority for them. As a team, they have decided to prioritize other things. You can disagree with their decisions, but all of this "OMG whhhhhy" whining is obnoxious and pointless.

Because it's not a priority for them. As a team, they have decided to prioritize other things. You can disagree with their decisions, but all of this "OMG _whhhhhy_" whining is obnoxious and pointless.

For me it's pointless that a dev decides how another one must write his/her code. That's why applications usually have a "preferences" view, where you can set the environment as you like. Since we are talking about a tool used all day long for working purposes, it doesn't seem stupid to me to ask for a feature that makes the files list more readable.

Users asking for features is how VSCode improves, and maybe if enough people ask for this feature, it will actually happen. But complaining is pointless.

must have feature for large workspaces.

I've been taking another look at this recently, from what I can gather there have been a couple of pull requests in the past which haven't gone very far

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

But I'm starting to think it should be possible to implement this as an extension based on what I've seen here

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

I had a dig through some of the other extensions on vscode but didn't find anything
I think what we need is someone to write an extension that can show the same thing as the default file explorer window but with nesting added on, ideally with support for reading .filenesting.json files which is already in use in Visual Studio 2019 (not code)

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

javascript isn't my first language so I'm not sure if I'll ever be able to do something myself
although I think there's enough extension API exposed to do this, at least in a separate explorer tab in the left

Hi @grbd, I think that the "hook" for this development would be the point where the file explorer is handling folders: that would show how nested files are displayed. Then this beaviour should be extended to files, instead of directories only.
It would be nice to add a setting in order to tell which file extensions should be included in the new display mode.
I never developed anything for vscode, so I cannot give you other info... Developing an extensions seems a good idea though, and maybe once it's well used and tested, maybe it will be moved into the main application source code.

As a starting point I would probably look at vscode-solution-explorer and copy / paste it
since it's already doing something similar in showing files in subdirectories similar to the main file explorer
the difference is it's intention is to emulate the view of VStudio 2019 instead of doing file nesting.

the setting in order to tell which file extensions should be included would be something like .filenesting.json as I mentioned above, or some other json related file.

Really struggling to see why.

Because it's not a priority for them. As a team, they have decided to prioritize other things. You can disagree with their decisions, but all of this "OMG _whhhhhy_" whining is obnoxious and pointless.

You do realize that you are in the _feature request_ issue, right? You would be right anywhere else, but this is the _actual_ correct place to request and talk about it (it is not pointless whinning). It will never be a priority if they think people are happy and don't need it.

I'll explain why do I need "virtual folders": I'm working with a C codebase configured through makefile, which I can't risk changing. However the code is a mess, and I have other codebases to maintain with the same problem.

I need to virtually arrange the files in virtual directories to maintain my sanity, and can do that in: Code::BLocks, Programmers Notepad (yeah). But I can't in VS Code.

This is a _must_ for people who are not in control in how they organize their files in folders, which is common in many organizations. This is not about "making it prettier".

The result: I'm much less productive using VS Code. I wish I could use it, but it is just a slower workflow.

I hope the team change their minds, I don't think this should be handled by a plugin, even though it technically could. I don't want to depend on a plugin provider for such a core need, investing time in something that might break.

I understand it is not a priority, I'm just asking that, if you want more users to able to use VS Code and be productive, to consider it in the future.

@grbd I would love to help, but this seems a lot of work, not sure If I have that much time.
I updated custom file nesting fork to match today's master. If anyone needs a starting point with file nesting, also added binaries to try it out.
https://github.com/floatas/vscode