Less compilation not working in Visual Studio 2015 Preview

[henkosch]

I have just installed Visual Studio 2015 Preview and Web Essentials 2015.0 and I noticed that my .less stylesheets don't get compiled at all into css. In fact the less options are completely missing from the Web Essentials settings in the options window.

[madskristensen]

As described in the release notes, all of the compilers have been removed. Use grunt or gulp instead. Its supported in VS and much more flexible than WE could ever be

[rosieks]

And what about preview pane - it was really usefull to see generated CSS.

[madskristensen]

The Preview pane was associated with the compiler, but since that is now removed, the Preview window can no longer function

[copernicus365]

"release notes" ?? what release notes?! They certainly are not referenced in the change log (http://vswebessentials.com/changelog). Pardon me for being frustrated about this, as this might have saved half my day or more. Currently we are given these very short notes in the change log with NO instructions or other helpful notes, so I was left guessing what in the world it meant that: "Removed all node.js based tools ... -Sass/LESS compilers". I hoped that meant they were native to VStudio now, but I'm glad to see this is available in another and more native way with grunt or gulp. I hope you guys will consider providing such "release notes" prominently and particularly visible from the change log page in the future, this will really help.

With all of that out of the way, thanks for all your excellent work guys!!!

[borekb]

In VS2013, my workflow was:

1. Edit LESS file
2. Save it
3. Watch my browser(s) auto-update using compile-on-save feature

Can I achieve the same in VS2015? The compile-on-save feature is gone, I can hook a gulp task to some build step but that still requires full build, right?

[madskristensen]

I'd recommend using the gulp-watch task as well to give you compile on save

[borekb]

Great, and browsers pick up the changes thanks to Browser Link. This workflow really feels quite modern, I like it. Thank you.

[madskristensen]

Awesome. Glad you like it :)

[jakenuts]

It's funny, I understand the reasoning behind this change and initially got excited about learning a new "alt" tool, and now three hours later I'm wondering if I've learned something different. Sometimes it's great not to have to install, configure, script, execute, watch stuff instead of just hitting Ctrl-S. In the end though it's a testament to how well you built WE in the first place.

[haribo256]

I have to agree with @jakenuts. While I greatly welcome Grunt and Gulp, the LESS compiler that was integrated worked everywhere; this route requires me to modify the projects (and websites) themselves, something that is not always easy or possible to achieve.

The great thing about WE is it makes LESS compilation simple and is only thing to upgrade.

Another point to consider is that it means all those poor joes like me have a significant upgrade path for all their websites in order to simply open them, and get them to compile in the new 2015.

One step forward, two steps back it seems. Please consider reintegration.

[Bartmax]

what about not mvc6 projects? like mvc4 or mvc5.

[madskristensen]

@Bartmax Both Grunt and Gulp works with MVC 5 projects as well and the Task Runner Explorer supports that.

[Bartmax]

@madskristensen actually, it doesn't. I encourage you to create a new project and update the project to adapt for the current workflow of using source files for dev and build files for release, you will find lots of issues, I will enumerate some:

Dynamic created files are not included in csproj so they won't get published.

This is also a problem for simple copy from bower components to folders like Fonts because MVC5 doesn't have a watch on folders so you need to keep refreshing solution explorer and adding files to solution and like previous point, if you fail to do that, they wont get published. And of course errors on clean...

tools like useref (usefull for concat-min on release) doesn't recognize "~" character so you will need to avoid them using only "/" which will give you problems if you are debug on local IIS (because you end up with localhost/appname/ .. or you must have to do some complex configurations on hosts files and ports on IIS not easily shared via source control.

so if you void using ~ character, you can wiredep and useref, but actually doing it on layout is a pain. MVC doesn't work with .html template pages, and are not built to work on .cshtml, even you can do some sort of things with a lot of imagination and custom configurations

wiredep on Bundles.cs is a valid approach but it's kinda lame, and you end up using a mix of tasks and optimization library.

Task Runners on visual studio are great for SPA, good on MVC6 (still need some improvements, forget about wiredep for example or you end up publishing all your bower_components, for example) but it doesn't even get close to be 'enough' on MVC5 projects.

I'm wondering how much testing grunt - gulp workflow actually had on MVC, doesn't look like much.

If the solution is to don't wiredep, useref, min, uglify only on prod, etc, then what's the point of using a task runner in the first place?

[scottdorman]

I understand the reasoning for making this change, but by making it you've made the extension less useful and more cumbersome all at the same time. Previously, if I wanted to start using LESS in my project, all I needed to do was have the WE extension installed. Now, I need to have the extension installed, then add Grunt/Bower to each project, then configure the dependencies to pull in the LESS compiler, etc. This is, to say the least, an inconvenience that I'll have to do on every project.

Not only that, but when something goes wrong, there are very few options to get things working again. For instance, I tried to install Grunt/Bower to one of my projects and get the following error:

Failed to run "\Web\Gruntfile.js"...
cmd.exe /c grunt -b "\Web" --gruntfile "\Web\Gruntfile.js" --tasks "C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\Web Tools\TaskRunnerExplorer\Scripts" vs-grunt-task-reader

This leaves me in a completely broken state when it comes to using Grunt/Bower as the task runner explorer fails to load the script, so I can't do anything. Ultimately, I have a .less file that can't be turned into CSS. Again, this is a huge step backwards in functionality and ease of use. The point of the extensions are to make things easier for us as developers, not more complicated and error prone.

Even looking at the WE website:

Effectively, none of that is true anymore. WE doesn't compile LESS or provide a preview or use a compiler. Instantly less useful.

[aikeru]

With gulp/grunt I can add tools the authors of gulp/grunt were not aware of. There's a huge set of them not limited to CSS transpiling and static analysis beyond linting that is growing every day. By using things like gulp and keeping things accessible from the terminal, they're composable and not limited to Visual Studio. I can integrate them into my CI build or share them with my colleagues who use Mac or Linux, where Visual Studio cannot run. It would unreasonable to demand that Web Essentials can accommodate for every possible workflow and every possible tool with a GUI alone. There's a huge community of tools and effort I can benefit from, plug in to or swap with thanks to gulp/grunt.

@scottdorman LESS isn't the only game in town. SASS, Sassy CSS, Stylus and so on. I may want to use other tools as part of my LESS transpilation process. It would be similarly unreasonable to expect TFS, Team City and Bamboo to be aware of LESS and how to transpile it (wait, you don't check in the transpiled files do you?). Personally, I'd prefer that gulp and the task runner take on the responsibility of what to do with the code I write and how to package it so Web Essentials can focus on giving me the best editor experience for the widest array of options for syntax, intellisense and so on. Similarly, gulp is what I expect to use on Team City, TFS, Bamboo, etc. since my CI and build servers wont have Visual Studio installed. I'd like my CI process to match what I run locally. It seems like if you want to stay with the legacy workflow (pre-gulp/grunt), you can keep developing in Visual Studio 2013 with WE 2013. If you want to use the new technology (2015), you'll need to learn some new things. This investment may carry too high of a cost for you today, so take it in small pieces or put it off for later.

There are definitely some rougher edges with this new workflow, but there are huge benefits to be gained.

[scottdorman]

@aikeru I'm not saying that the change isn't the right approach and that it will, in the long run, yield a lot of benefits. What I am saying is that by simply removing existing functionality in favor of letting the end-user figure out how to use a bunch of other tools, configurations, etc. to achieve the same result is taking a huge step backwards.

It should be pretty straightforward for @madskristensen to, at a minimum, provide instructions on how to achieve the same result using the new workflow. Ideally, the extension should configure itself appropriately to achieve the same result. What I mean by that, is the options for automatically compiling LESS files on save should remain and when a new .less file is added to the project (and the option to compile on save is on), the appropriate changes should be made to gruntfile.js.

I don't want to have to configure this for every project I'm ever going to use LESS with when it's functionality that was already included in the extension. That was/is one of the main reasons WE exists in the first place - to extend VS with features that we've been missing but make it easy as well. Adding a bunch of manual configuration steps for every project and every time I add a new .less file is taking a step backwards in the productivity gains.

[Bartmax]

This doesn't need to be black or white @aikeru. I use and like Task Runners, but at the time of authoring a .less file, the preview was very useful, right now there isn't one.

You can have CI servers and customized builds or you can author a simple .less file compile and drop it into wwwroot and you get the same result. It always depends on the needs, and problems at hand to solve.

Is like saying to drop support to save markdown as html, use a gulp-markdown-processor for that, I think there should be balance.

There were 2 features removed here: the less compilation preview and generate css file from less

I do understand why this was removed, and why task runners are a step forward, but also know a lot of problems it has on projects that wasn't created with that workflow in mind. (like watch folders on MVC 1-5) and since not everyone is doing ASPNET5 MVC6, I guess the ability to have it adds value.

There's no need to be enabled by default neither to complete remove it.

As of things are right now, the best approach to MVC5 and earlier is to keep using Bundle and Minification packages (also the mvc team is discussing to bring that to mvc 6) which lines up pretty well with WE LESS compilation, while on MVC6 the preferred approach will mostly be using grunt/gulp/brunch.

Maybe an option will be to keep this feature enable by default on pre MVC6 applications so people can keep working how they used to before task runners even exists on ASP.NET world and disable moving forward, making it optional, not every tools works for all tasks and not all tasks are better solved with the same tool.

The less compilation was a GREAT feature of web essentials, and it's something their users are missing a lot, that at least must mean something.

[scottdorman]

As a good example, in my opinion, of how this is currently worse here is what I had to do:

The steps I had to follow:

1. Add grunt to the project.
2. Restart Visual Studio in order for the Task Runner Explorer to properly recognize/read gruntfile.js.
3. Update package.json to include grunt-contrib-less.
4. Update gruntfile.js to include a new task for the less compliation.
5. Update gruntfile.js to load grunt-contrib-less.
6. Set the binding for the less task to be a "Before Build" task.
7. Compile

Keep in mind, this will only generate css from less. If I then want that CSS minified, I have to add additional packages and tasks. (Of course, that assumes that I want both minified and non-minified versions of the CSS, which typically is desirable. If I just want one or the other, I can do that with just the single less task and the appropriate options.)

Contrast all of that to what WE used to provide, which was simply some flags that let me compile on save and automatically generate minified and non-minified versions of my CSS (with source maps).

I think that's the underlying issue here. We moved to a more robust and flexible design (potentially) but did so at a huge cost to user productivity and ease of use. _Oh, and between discovering that my less files weren't being automatically compiled (expectation from previous versions of WE), researching to find out why (it was removed), researching what I needed to do to enable some semblance of the same functionality (grunt, grunt-contrib-less, etc.), and commenting here, I've now wasted an entire morning on what would have previously been completely trivial._

Doing all of that, incidentally, I get the following errors when running the task:

> cmd.exe /c grunt -b "d:\users\scott\source\web" --gruntfile "d:\users\scott\source\web\gruntfile.js" less
>> Local Npm module "grunt-bower-task" not found. Is it installed?
Running "less:development" (less) task
File undefined created.
Process terminated with code 6.
File Content/Site.css created
File undefined created.
File node_modules/grunt-contrib-less/node_modules/less/test/browser/less/console-errors/test-error.css created
>> NameError: variable @global-var is undefined in node_modules/grunt-contrib-less/node_modules/less/test/browser/less/global-vars/simple.less on line 2, column 10:
>> 1 .test {
>> 2   color: @global-var;
>> 3 }
Warning: Error compiling node_modules/grunt-contrib-less/node_modules/less/test/browser/less/global-vars/simple.less Use --force to continue.
Aborted due to warnings.

There are three issues here:

1. The "out of the box" gruntfile.js that is added by WE throws an error: Local Npm module "grunt-bower-task" not found. Is it installed?
2. The grunt-contrib-less module has a bug (apparently) in it where it's creating some unnamed files and trying to create a test-error.css file (which is part of the grunt-contrib-less distribution, not anything I wrote) which is causing an error.
3. That error causes the less task to fail prematurely.

[rubenprins]

We currently use Web Essentials only for the following features:

• minification on save (which appears to still exist)
• bundling
• less compilation on save (removed)
• JSHint (removed)

Pretty much all other features are not worth the overhead of a rather buggy and crash-prone extension like WE, especially since I can configure minification and bundling in gulp/grunt when I have to write the less and JSHint code anyway.

Bluntly removing features like this because there's a new hype around the corner, is a disservice to your users. You do realise that we, the users, actually USE these productivity features? And that if we upgrade to VS2015, we have no choice but to accept this gutted version of WE?

I'm still on the fence about ASP.NET v5, which appears to be a huge step back in productivity (not to speak about no backward compatibility whatsoever), and is so opinionated on how one ought to develop an application, that it makes existing application models impossible: http modules, handlers, and auto wireup of modules -- all gone and replaced with code files you have to keep in sync (and proper order) by hand. And our entire codebase is going to upgrade by magic or something.

And having WE force ASP.NET v5's workflow on non-v5 projects is just the icing on the cake. But at least the ASP.NET web team is being consistent.

We liked the productivity the ASP.NET-Visual Studio-Web Essentials tool chain provided. But what we're left with is your opinions on how we must change our way of writing our applications forced upon us, and no productivity.

[madskristensen]

The LESS/Sass/CoffeeScript compilers were removed because VS2013 was way to unstable and I couldn't even compile the project anymore. I'm working on a new extension that will handle bundling and minification for JS, CSS and HTML files and it will be released very soon.

I'm also starting to design a way to handle LESS/Sass/CoffeeScript compilation in a separate VS extension that uses the built in Node.js and npm features of VS2015, but it's a little further out.

[scottdorman]

@madskristensen I think removing the compilers in favor of the node.js and npm features is the right approach, but until the new extensions are done we've taken a big step backwards in terms of productivity. The compile extension sounds like what I was suggesting earlier. I think the biggest frustration and pain point being felt (and expressed in the reviews on the VS gallery) are because we lost functionality without having a documented mechanism to get it back using the new workflow.

As for the new extensions, that's great to hear and it sounds like they'll provide the same level of functionality (at a minimum) as to what was previously in WE. I'm curious as to why you're doing them as separate extensions rather than part of WE? Mainly asking this because it seems like now we have a split of functionality between WE (editor and intellisense) and the two new extensions (compilation and minification). It seems unlikely that someone is going to want one set of features without the other. Having all of it bundled as part of the one WE extension rather than split into 3 seems like it should still be the right approach.

[madskristensen]

New extension because the implementation in WE2013 was extremely problematic and error prone. Since it had to be rewritten to use the internal node.js and npm features, I wanted to move that to its own extension going forward. I've been doing that for the last year or so in order to give the flexibility to get just the extensions you want instead of a big monolithic extension that is WE.

Even if VS2015 didn't have node.js and npm included I would still have removed the LESS/Sass/CoffeeScript compilers because, as I mentioned, I couldn't even compile the project.

I hear what you and others are saying and I'm not taking it lightly. A solution will be out around the time VS2015 goes RTM for people that doesn't want to use Gulp/Grunt

[aikeru]

@Bartmax I definitely see the fact that there was a preview before, and now there isn't. I don't really see how this is a killer feature, though. If, for some reason, you must use 2015 - open the output CSS file in a new pane and let Visual Studio update it on saving. Still not the same thing, but it's workable.

@scottdorman so, did you try the refresh button on the task runner explorer? If you did try, and it didn't pick up changes to your gulpfile, then that sounds like a bug. If you were forced into using VS2015 or WE 2015 for some reason, I would understand better your pains in figuring out why the new version works as it does. As it is, both of these are still RC software anyhow. Maybe the community (maybe even me) can help you with your particular setup issue. I suggest you open a StackOverflow or something - get your gulpfile.js up in a gist or something too - then link to it. If you're not familiar with gulp, it can be easy to miss something important.

@rubenprins WE is open source and no one requires you to use VS2015. There are arguably better tools out there than JSHint (just as JSHint was a big step up from JSLint, ie: check out ESLint) and other static analysis tools (ie: jscomplexity, flow type checking). Maybe you could fork WE for 2013 and make it work the way you want for 2015.

I think, in light of the fantastic news that @madskristensen is going to develop additional plugins to take away some of the pain for folks not used to troubleshooting and setting up gulp and tasks ... I don't know why anyone would be too upset that in an RC product things don't work quite as they expect. Maybe if you folks want/need those plugins, somehow we as a community can contribute to mads' efforts. Whether it's code, testing or monetary gifts.

@madskristensen, can you link to your work on these extensions? If you haven't put them online yet, maybe you could do that. If there isn't a way for people to contribute monetarily to your efforts, is there a reason why?

[aikeru]

Also, hopefully, with time tutorials and pluralsights and all that will catch up with these rapid developments. Then, when someone wants to LESS or minify or ESLint or something ... folks can just point them to the easy step-by-step tutorial with sample source code.

I know that material exists for development outside of Visual Studio, and then plugging in an existing gulp/npm configuration to Visual Studio is relatively easy, but I'm not sure that's part of the ask from the folks that have commented.

[madskristensen]

@aikeru I'll put it online today

[scottdorman]

@madskristensen Thanks for the clarification on why new extensions versus including in WE. Is the long term plan is to break WE up into separate smaller more targeted extensions? I don't mind using gulp/grunt and think long term that's the right approach, but (especially for something like compile on save) there's a lot of overhead involved in getting that setup every time I create a new project.

@aikeru Yes, I tried the refresh button on the task runner explorer. Tried it several times, in fact. As for not being forced into using VS2015, I fail to see the relevance there. Yes, I choose to use WE2015, but did so with an expectation that I was not loosing functionality. I'm more than aware that these are both RCs and that things are potentially missing/unstable still, but, again, that's different than loosing functionality. There is a big difference between something not working quite as expected (IE, compilation failing for some reason) and functionality being removed without an adequate replacement and/or instructions on how to replace it. What would help is for the necessary steps to be "officially" documented somewhere (here or the WE website, for instance) rather than lots of people "opening a StackOverflow or something". As for "tutorials and pluralsights" catching up, that's not the ask and it's not the point of the frustration. One of the primary benefits gained from WE (prior to 2015) was that it simply and easily added functionality that was missing from the core VS product and that's something that got lost. The other extensions @madskristensen is working on will provide the replacement functionality using the new workflow, which will be great.

[madskristensen]

@scottdorman Yes, the idea is to break it apart in smaller more manageable extensions. We'll have to roll in a lot more features to VS from WE before that can happen, but that's the goal. It makes it easier to maintain and also easier for the community to contribute to smaller code bases

[madskristensen]

Here's the brand new repo for the bundling and minification extension https://github.com/madskristensen/BundlerMinifier

[aikeru]

@scottdorman that's fair about RC vs not, but I guess that's the part where this isn't VS 2014.5, it's VS 2015. Yeah, step-by-step instructions to get the previous functionality is a fantastic idea. That would probably solve a lot of the headaches. One reason I point to SO and PluralSight is because as an open source project, "anyone" can contribute to the answers you're looking for.

@madskristensen would it be appropriate to add an issue for step-by-step instructions somewhere (ie: on the web essentials website or something) to replace functions once supported by WE and now delegated gulp/grunt or to the other plugins?

[scottdorman]

@aikeru Yes, clear and concise instructions to get back to the previous functionality (or something close) would solve a lot of the headaches. The issue with using SO and PluralSight is that they aren't official and there are multiple ways presented (not all of which work properly) so it's difficult for the general community to figure out which one to use. Yes, it's an open source project and anyone can contribute, but that also means anyone contributing should do so here in the GitHub project and not on SO.

@madskristensen Taking a quick look at the repo for the website, it looks like it would be straightforward to include the instructions in the feature page. Something similar to:

<article id="preview" class="panel panel-default" data-version="WE2015">
    <h3 class="panel-heading">
    <a href="#grunt">
        <span class="fa fa-link"></span>
    </a>
    Grunt implementation
    </h3>
    <div class="panel-body">
    <p>
        <!-- Step by step instructions would go here. -->
    </p>
    </div>
</article>

I'd be happy to submit a PR if somebody (@aikeru maybe?) can provide the content. Alternatively, I can start with my solution and we can refine it as necessary.

[rosieks]

Regarding moving from WE built-in compiler to node/npm/bower, I'm wonder if 260 chars path limit was fixed? both in git tools for Visual Studio and in TFS build

[aikeru]

@scottdorman if no one else does it before me, I may try and take a stab at it when I have some free time... :) It would be a privilege to contribute, even in a small way, to one of mads' projects :)

[madskristensen]

Perhaps write an article or blog post and then link to it from the WE website. There is plenty of information on how to use Gulp to compile LESS files etc, so perhaps just compile those and make a specific WE migration version? Btw, let's focus on Gulp instead of Grunt

[madskristensen]

The Bundler & Minifier extension is now in a good state and ready for testing. You can download it here https://visualstudiogallery.msdn.microsoft.com/9ec27da7-e24b-4d56-8064-fd7e88ac1c40

If you got some time, please try it out and let me know if it works as advertised and if there are features missing. I want to use the exact same model for the LESS/Sass compiler extension, so please help test this extension so it will be super awesome before I base the LESS/Sass extension on it.

Also, thanks for all the feedback you've provided so far. It really helped me to push for getting these extensions done in time for VS2015 RTM

[rubenprins]

@madskristensen I do like the prospect of the new bundler & minifier extension (especially as a separate and more focused extension), but is there a reason for using a single monolithic bundle definition file rather than a bundle definition file per bundle (like the WE2013 .bundle files)? Or are both going to be supported by each separate extension?

[madskristensen]

I like the single file approach better, because it is a single point of failure/success/cleanup. Also when dealing with how files should be included in the project or not and in source control, a single file makes things simpler.

[aikeru]

@scottdorman @madskristensen Here's a first take on the content needed (as markdown in a git repository) for illustrating how to get this workflow in Visual Studio 2015 using gulp and the Task Runner Explorer. My goal was to be complete, to appeal to the lowest common denominator and to keep the instructions easy and "push-button-simple". They aren't very pretty and I'd love any feedback or PRs.

Perhaps later, sample files could be added (ie: gulpfile.js/package.json templates) that folks could just drop-in and use. https://github.com/aikeru/WE2015Workflow

[madskristensen]

I'm now working on a new extension for compiling LESS and Sass files. Link to GitHub and Gallery download to follow...

[madskristensen]

Here's the Web Compiler extension for LESS and Sass compilation: https://visualstudiogallery.msdn.microsoft.com/3b329021-cd7a-4a01-86fc-714c2d05bb6c

GitHub repo: https://github.com/madskristensen/WebCompiler

Please help testing it

[hatton]

Works for me. Thanks Mads.

[scottdorman]

@madskristensen Both of the new extensions have been working great. Thank you for getting these done so quickly. I'm glad to see that the compiler extension generates both the minified and unminified versions and nests them properly. Looking forward to the update that includes source map support for LESS files.

[empouras]

Hi, I think (unless I have understood something wrong) that the web compiler is missing an important thing that WE had.... the fact that when changing one less file, on save it would recompile all the related files and not only that file! As well is it very difficult to be able to have the preview of the css file as used to be in the VS2013 in a split screen?

[superquinho]

Sorry! I know this thread is closed, but I cannot find how to uninstall WebEssentials anywhere. Could anyone give me a hint? WebEssentials have been very essential, but is not essential anymore. Not only that, but after I installed it on my project, not even the html pages are been updating on build. Very annoying. So I am just gonna use gulp...... WebEssentials is a necessary ending! Thanks for all the good times and happiness we had until this day