I tried to post this as a "Feature Suggestion", but am having trouble finding it again - and the one time I found it before, it would not let me edit it, so I am posting it here.

I think you guys would expand on the usefulness of Web Workbench several times over with a few very, very minor tweaks to the way it works, and more specifically, the way it stores settings.

Right now, Web Workbench kind of takes an approach of "running on everything it can possibly run on", and then you turn that off for instances where you want to disable it. But my experience in development has shown me this is actually counter-intuitive.

• Most programmers that are using LESS/SASS/SCSS are not compiling each individual .less, .scss or .sass file. They are in fact more often creating multiple smaller files, and then collecting them up into a larger file that has a numerous amount of imports or includes. This 'master' file is actually what we want to compile to .css. The other files are just errata if compiled. This is not 100% true for all situations, but most large projects I have seen and created and most other developers I speak to have experienced this.

• Web Workbench's settings page is a cumbersome mess.

I am sorry, I love you guys. I love what you're doing. I love your product. But the settings are a disaster. You install the program and you're presented with a massive, bulky spew of all of your .js, .less, .scss, .coffee etc files just kind of 'dumped' in front of you. Visual Studio is now churning and struggling to compile each one when you save it, etc. It's actually the opposite of what I want to happen.

Just look at this

Look at how much information I have to deal with on one little screen? And it is all compressed and mushed together. This is really annoying for project management, and it gets even worse when you get to trying to synchronize it between machines with source control. I've had very mixed results over github.

Why is this bad?

This is bad for a few reasons;

1. It expects us to know which files we want to compile right then, on that screen. This is usually not the case, as we discover what we want to compile as we work through our code.

2. It is just messy. The picture I gave was just a project that has twitter bootstrap on it. You don't even see the other +114 .less files from kendo, font awesome, my own theme, etc. etc. This gets out of control very fast.

3. It is resource expensive. Every one of these files is getting compiled, and I don't want that. I only want about 6 of them to be compiled, honestly. In order to do this, I have to go through and manually edit over 110 entries on this list.

Solution

I think there are two key solutions to this problem, both of which fulfill the following;

1. Make the settings for Web Workbench version control agnostic and seamless
2. Make the settings intuitive, easy to access, not coupled to a UI, and faster to edit
3. Make the settings only apply to files you feel are important, by either specific file, directory, or pattern.
4. Improve Visual Studio performance by not trying to process files that you haven't asked it to.
5. Improve Visual Studio performance by giving on-demand compile access on the context menu.

I feel these are very compelling reasons to make this switch, and have more elaboration here. This is how I would accomplish it, after hours of looking at Web Workbench and analyzing its behavior.

Create a workbench.json file.

The first step is to go with a convention more like bower and nodejs and create a workbench.json file that is extremely simple. The syntax would be literally this basic;

{filename}, {output directory}, {compile switch}, {minify}, [options]

[
 { "content/assets/less/bootstrap.less", ".", true, false, [ { intellisense: false }] },
 { "content/assets/less/kendo.less", ".", true, true, [] }
]

You've lost the need for a complicated user interface, you've created a mechanic that is very easily portable, you have created a small, lightweight way to manage the files that Web Workbench works on, you have also greatly improved Visual Studio performance by now only compiling files that the user has asked you to.

This does not apply to intellisense. Intellisense would remain enabled by default.

Create a Web Workbench Context Menu

As its name implies, simply create a new context menu entry in the file explorer for Web Workbench with the simplest options available. Namely...

• Compile
• Edit Properties

This is a trivial mock up, but you get the idea;

In doing this, you now allow the user to compile web workbench compatible files on demand, thus further removing the need for entry into the settings (in this case, workbench.json) and freeing Visual Studio's resources up to only do processing when you ask it to. This helps to avoid un-wanted changes to source, and allows you to be more certain that it compiled right instead of 'hoping' that when you saved the file, it worked.

Edit Properties would simply add the file to the list in the workbench.json file.

With all of these changes, the only property that Web Workbench would need in the Visual Studio settings is really the location of the workbench.json file.

Thanks for the detailed feedback - we agree that the settings page definitely could use a UI overhaul. Ive linked this thread on our backlog so we can look at incorporating your ideas on the settings file.

Thanks!
Jeremy