File Nesting

[ciel]

Is there any possible chance we might see File Nesting in Visual Studio Code the same way it works in Visual Studio 2015? It was really convenient and helpful. I would adore such a feature!

[isidorn]

fyi @bpasero

[ciel]

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

[bpasero]

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

[playerx]

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):

src
--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:

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

[serhiisol]

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

[CreepGin]

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.

[wupaz]

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

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

[uxsoft]

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

[ajsheehan]

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.

[uxsoft]

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 notifications@github.com 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 .

[RizwanAslam]

+1

[canda]

any extension that may do the job?

[MarcelMalik]

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

[mbeckenbach]

@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 :-)

[bpasero]

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

[bpasero]

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

[playerx]

@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

[bpasero]

@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?

[mbeckenbach]

@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

[playerx]

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

[playerx]

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

[playerx]

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

[mbeckenbach]

@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. :-)

[playerx]

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

[mbeckenbach]

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

[seveves]

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

[aluanhaddad]

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

[JohnYoungers]

@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

[felipegtx]

This would be really neat!!

[Earl-Brown]

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

[nseba]

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]

@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?

[cspaniard]

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

Please, please... consider supporting it.

[Wayofthesin]

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.

[ciel]

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

[RichiCoder1]

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.

[aluanhaddad]

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

[jvlppm]

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

[binoypatel]

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

[ciel]

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.

[ciel]

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.

[MigFerreira]

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

[ashbrener]

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.

[jens1o]

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

[MigFerreira]

[jens1o]

Ah, okay, thanks.

[timbyng]

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.

[RoyTinker]

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.

[pieperu]

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.

[firelizzard18]

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