-
Notifications
You must be signed in to change notification settings - Fork 116
File nesting in Solution Explorer is inconsistent and incorrect #347
Description
The Solution Explorer for ASP.NET 5 MVC projects has several major problems - one of them is file nesting. The below issues affect Visual Studio 2015 Update 1 with ASP.NET 5 Release Candidate 1.
tl;dr
- Please fix nesting rules for
.less,.scssand.sass, so those files are nested under.html. - Please fix incorrect nesting that sometimes appear after renaming/moving/copying files and folders.
- Please provide an option to disable all file nesting, and eventually, options to configure nesting rules.
- Please fix other critical Solution Explorer issues - this is just one of them, and there are many more.
File nesting is inconsistent when nesting files under .html.
The .less and .scss files should be nested under .html. Those files compile to .css just like .ts compile to .js and they are just as much part of the view component.


In fact, if we only have a .css file in there, then it is nested as expected, so clearly .less and .scss should also be nested:

While the above is clearly a bug, and a very annoying one at that, the rules for other file types are less obvious, but should maybe also be considered... maybe .json should also be nested under .html?
It probably contains either settings, string resources, or data for that view component, so it seems resonable to me, although I consider this far less important than getting the style sheet nesting fixed.

Those nesting rules have been inconsistent ever since they were introduced in ASP.NET 5, and it really needs to be fixed. Sure, everything compiles just fine, but I'm getting really pissed off looking at this mess in my Solution Explorer every day. Inconsistencies like this makes the whole concept of nesting seem like an annoyance more than a help, as it raises the obvious question "if only some files are nested, then why nest anything at all - that's just an extra click to get to the .ts file". Which brings me to...
File nesting can be annoying
While the fundamental idea of file nesting is not nessesarily bad, it can be very annoying at times, which is why, as a minimum, I want an option to disable all file nesting - and ideally, options to configure the nesting rules.
Consider this folder structure, where the folder already represents a container for the component:

Here the file nesting provides no benefit at all, and actually just introduces a really annoying extra click to get to the .ts file. A possible fix for this might be to only nest files if the folder name is different from the name of the .html file, but this might also be wrong - for example, a folder named tabs representing some fancy tabs component might actually contain multiple elements that work together, e.g. tabs.html/js, tab-pane.html/js and tab-button.html/js, and in this case we do want nesting for all three of those. Therefore, I strongly believe an option to simply disable all nesting is the best option here - and it is very much needed, because despite this example, we do have projects in which the nesting provides absolutely no value and represents a major annoyance.
One could also argue that the .html file should actually be nested under the .js file.
Consider an Angular 2 application, where the .ts file represents the actual Component, annotated with metadata specifying either the path to the .html file representing its view, or if the view is small, a string representing the markup of the view. Same for styles, where the metadata in the .ts file specifies either the path to the .css file, or a string representing the style rules. Here, both the view and the style sheet is clearly dependencies of the .ts file, so it would make sense to nest them below that...
An alternative idea
Alternatively, you could consider a completely different approach to nesting, where the part of the file name the files have in common, is used to show a "virtual folder" containing all the files - then file nesting could be used only for things like transpiler generated files. The image below is a concept I mocked up to illustrate this idea:

Here, all the files have the "foo" part of their name in common, and is therefore nested under a "foo" node in Solution Explorer. However, in the file system, the actual files are all located in the components folder, so in the code the path would be app/components/foo.js - nice an clean, works for any file type, and makes no assumptions about whether .html or .js is more important.
Going further with this idea, the IDE could also be smart, so when selecting this "virtual folder", it could maybe somehow open all the foo.* files in a split view (ignoring transpilation output of course), thus providing a quick way to see all the component code at once. Just a thought...
File nesting is broken
Not only is file nesting inconsistent, and sometimes annoying, but it is also broken.
Here are two cases of incorrect behavior I managed to reproduce - unfortunately, this does not seem to fail consistently, so it can be hard to reproduce - but it does happen often enough to be annoying.


Please take those Solution Explorer issues seriously - I've provided feedback about multiple critical issues several several months ago, and thus far nothing has improved. Solution Explorer still hangs or crashes the whole IDE when a large number of files is modified/moved/copied/renamed, it still has annoying, inconsistent and buggy file nesting, and it still constantly gets out of sync with the file system, crashing first the project system and eventually the whole IDE. I'm more that a little concerned about seeing a release candidate label on something this buggy and unpolished - if this is indeed what you intend to release, then we intend to find another IDE for our frontend development.