Scott Hanselman

Introducing Gulp, Grunt, Bower, and npm support for Visual Studio

September 2, '14 Comments [72] Posted in ASP.NET | Tools | VS2013
Sponsored By

Web Development, specifically front end web development, is fast becoming as complex and sophisticated as traditional back end development. Most projects don't just upload some JS and CSS files via FTP. There's now a front end build process that can include expansion of SASS and LESS, minification of CSS/JS, running JSHint or JSLint, and much more. These build tasks and processes are coordinated with tools like Gulp and Grunt. Additionally, client-side libraries are managed as packages using management systems like npm and bower.

Why client-side package managers for ASP.NET? Why not NuGet? Why not MSBuild?

Some of you may ask, why not use NuGet for JavaScript? Why not extend MSBuild for building CSS/JS? Simple. Because there's already a rich ecosystem for this kind of thing. NuGet is great for server side libraries (and some client-side) but there are so many more CSS and JS libs on npm and bower. MSBuild is great for server-side builds but can be overkill when building a client-side app.

So, use both. These are tools in your toolkit. Adding support for Gulp, Grunt, Bower, npm (and other stuff, in the future if needed) means a more familiar environment for front-end devs doing ASP.NET and it opens the doors for ASP.NET devs to bring in the JS and CSS libraries communities use every day.

Introducing Task Runner Explorer

We’ve received a ton of feature requests regarding Grunt/Gulp support from many of you as well as the community at large. We are building first-class support for both Grunt and Gulp in Visual Studio “14” with full extensibility. Now we’re ready to ship a preview of this support as an extension to VS2013 and would appreciate your help testing and exploring this feature. 

Today we're introducing a preview of the "Task Runner Explorer" as a VSIX extension. We're also recommending two other VSIXs to round out the experience for this feature.

NOTE: Much of the functionality included in these multiple VSIX extensions will be built into Visual Studio so you won't need to install so many things. However, for VS2013 and this preview we needed multiple VSIXs in order to get you the bits sooner than later. Also note that today only Task Runner Explorer will work on Visual Studio Express but for VS14 all  the features will work in the free VS Express version.

Consider these features as a "DevLabs" preview for now, much like the VS Productivity Power Tools. They'll graduate into the final product.

What do you need?

First, you'll need Visual Studio 2013.3 - that 3 means "Update 3" which is a free update.

  1. TRX - Task Runner Explorer Visual Studio Extension
  2. NPM/NBower Package Intellisense - Search for online NPM and Bower packages directly with Intellisense
  3. Optional Grunt Launcher (gives right-click options in Solution Explorer - including "npm install")
    • Without this extension, for now you'll need to run npm install yourself to restore/add packages.
    • If you DO have this extension, right click on packages.json and "npm install" before running a grunt/gulp task.

To open the TRX (Task Runner Explorer), simply right-click any gruntfile.js in your project:

image002 

The TRX sits at the bottom of VS by default and looks like this:

 image001

Here we can see that it found a gruntfile.js in the root of one or more projects in the solution. It also shows the task bindings feature that allows any task or target to be triggered by 4 different Visual Studio events.

To associate a task/target with a VS event, just right-click and setup bindings.

image003

To run any task/target, just double-click it and a console appears:

image004

When you've got the Package Intellisense Extension you'll find it easy to add and update packages when directly editing your package.json for both bower and npm.

completion-name

You'll even get metadata tooltips populated asynchronously.

tooltip-animated

As you go testing it, remember you'll need to run "npm install" before you use the Task Runner Explorer to run Grunt tasks.

Big thanks to Mads Kristensen, Dan Chartier, and Van Kichline for their great work on this feature!


Sponsor: Many thanks to Intersoft for sponsoring the feed this week! Enterprise cross-platform native apps development made painless with Intersoft Crosslight. Sounds too good to be true? See it for yourself and get started today! 

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web
Tuesday, September 02, 2014 6:58:48 PM UTC
Nice. Now maybe I can use one IDE, rather than one frontend and one backend.
Tuesday, September 02, 2014 7:38:11 PM UTC
That is awesome!
Tuesday, September 02, 2014 7:38:29 PM UTC
Scott, could you please send my congratz to the team about this specific feature? You guys are moving so fast and in the right direction. We regular devs really appreciate this.
Tuesday, September 02, 2014 7:54:48 PM UTC
Thank you so much for this feature!

Quick question: where should we log bugs and/or feedback?
Jean-Baptiste Blanchet
Tuesday, September 02, 2014 8:07:37 PM UTC
Scott, it would be helpful if you could elaborate on Grunt and Gulp, how they work together, when they actually run, and who the target audience is for this. From quickly browsing the websites for both projects, they seem like they're for devs on a Node.js stack. As an ASP.NET developer, it's not clear to me how this could fit in or be beneficial.

Thanks!
Sam
Tuesday, September 02, 2014 8:10:15 PM UTC
Will this be supported in Azure Websites build process?
Chris
Tuesday, September 02, 2014 8:48:16 PM UTC
Man, this looks great! Aewsome!
Renan Borges
Tuesday, September 02, 2014 9:01:05 PM UTC
This Task Runner Explorer seems like a good step in the right direction.

@Sam: It's briefly mentioned in the opening to this article, but gulp and grunt are two alternative (you pick one or the other, for the most part) JS build engines (that run on Node.JS). In the ASP.NET world you tend to interact with them for front-end build processes where JS (or CoffeeScript or TypeScript) is the "native" language of the tool you need for a build step. Most of the best minifiers and optimizers for JS (uglify/CoffeeScript/TypeScript) and CSS (LESS/SASS), for two examples, are being written in JS at this point and gulp/grunt automates them into a pipeline (make/msbuild for JS essentially). The most common reason I use a gulp/grunt build in ASP.NET applications is for "r.js optimization", which bundles and minifies AMD (asynchronous module definition) modules (which are themselves built in TypeScript). I've seen partial C# reimplementations of r.js, but none of them have the power of r.js and r.js is written in the same language being bundled/minimized/optimized and owned by the same team that owns the require.js loader that it optimizes for and so it tends to get a lot more eyeballs and updates/fixes/features faster.

Tuesday, September 02, 2014 9:05:16 PM UTC
Sam,

Both Grunt and Gulp are task libraries similar to say MSBuild or PSake and are very common tools for managing the packaging of client side scripts. Both Bower and NPM are package managers similar to NuGet. There seems to be a movement to split client side and server side javascript into two package managers ATM, with bower being client side, NPM being both.

As for the benifit, think of it as bringing the mountain to Mohamed. Modern client side development is done using bower, npm, gulp and grunt. Current ASP.NET practices are a bit behind the times. If your team were to go out and hire an experienced front end web developer, they would expect to see these tools being used.

ASP.NET has been a bit of a walled garden for almost a decade. If you want to hire the best, support the tooling they want to work with is a good idea. It's really awesome to see this stuff moving into the realm of possibility in .NET. I am actually excited to do .NET development again.
Tuesday, September 02, 2014 9:43:52 PM UTC
Really great improvement. I recently started using Bower for all frontend related JSish libraries instead of Nuget, and wrote why in this blog post tinyurl.com/ThePowerOfBower

Really looking forward to try out some of the new web features
Tuesday, September 02, 2014 9:55:02 PM UTC
Great stuff :) Can you elaborate on how this new support works with say an asp.net site where the cs code is built with msbuild? How does the gulp/grunt stuff work in those cases?

Also, how about in a CI scenario? Would one build with msbuild first and then with gulp/grunt? The other way around? It would be really nice if msbuilt could bootstrap the front end builds and perhaps have tooling support similar to nuget where VS could also set up the tools for CI builds

I imagine most folk using this feature will be coming from the asp.net side and perhaps be less experienced in using the other tools :)
aL
Tuesday, September 02, 2014 10:00:58 PM UTC
This is the best news I've read about .NET in a long time. Can't wait to try it.
Coleman McFarland
Tuesday, September 02, 2014 10:12:11 PM UTC
Will this be supported for web sites as well as web apps?
Tuesday, September 02, 2014 10:13:02 PM UTC
Hot damn! This is a most welcome addition. Totally agree with Dan Kline's single IDE comment. VS 2014 going to be a very formidable front & back end tool.
Tuesday, September 02, 2014 10:39:23 PM UTC
I've heard rumors of such integration, so I can't wait to get update 3 installed and kick the tires on these! Even though most of my development is now in JavaScript, Visual Studio is still my IDE of choice.

Our teams have completely switched over to Bower from NuGet for client-side packages for several months now. We're using Gulp as our build tool for Angular apps with a MVC and Web API backend. After some blood, sweat and tears we were able to bypass our reliance on System.Web.Optimization for bundling, which had given us all sorts of pain.

I wrote quite the essay on our experiences in the form of a comparison of Bower vs. NuGet that your team may also find helpful: Why Bower is better than NuGet.

Kudos to the team for continuing to make Visual Studio relevant to the state of the market and a first class IDE!
Wednesday, September 03, 2014 2:25:34 AM UTC
Awesome! These features will bring me back to VS from other editors.
Wednesday, September 03, 2014 2:43:51 AM UTC
Huge fan of integration of these kinds of tools into Visual Studio.. now I'd love some extensibility in terms of integrating some alternative tools. Specifically in my case, PVC build - pvcbuild.com.

Good work to everyone putting in the hours to make this happen, we appreciate it!
Wednesday, September 03, 2014 3:22:42 AM UTC
@Brandon, the Task Runner Explorer is completely extensible. In fact, both Grunt and Gulp are added using the public extensibility API of the Task Runner Explorer. Any task/target based system (fez, broccoli, pvcbuild) can be added in the same way with same support. We haven't documented the API yet, since it's still subject to change, but we will.
Wednesday, September 03, 2014 4:41:58 AM UTC
Great to see this in visual studio 2013
Tirumala Dilip
Wednesday, September 03, 2014 7:17:28 AM UTC
@Mads can this be extended to things like jekyll? Jekyll lacks an editor. You have to build everything in the command line. I've been thinking of building and editor from scratch, but extending this as visual studio plugin seems better. I've also thought of the possibility of creating an editor based on the Visual Studio Shell.

Any thoughts?
Wednesday, September 03, 2014 8:11:35 AM UTC
Awesome feature guys, having switched to Angularjs as our main JavaScript library I find myself using npm and Grunt more and more. This feature is very welcome indeed!
Robert Mulder
Wednesday, September 03, 2014 8:49:21 AM UTC
How does this fit in with web deploy?
Erlend Wiig
Wednesday, September 03, 2014 8:50:47 AM UTC
Ok cool. These will come in handy
pelumini
Wednesday, September 03, 2014 10:15:16 AM UTC
Awesome! Downloading :D
Wednesday, September 03, 2014 12:03:46 PM UTC
Great!
It happened to me to ask for gulp and it's module support in visual studio a few months back. After a while I was notified that the development was started and now here it is.

Making a product every day better and empowering the community with one stone! Thanks.
Alessandro Ghidini
Wednesday, September 03, 2014 12:37:45 PM UTC
Utterly amazing news! Can't wait to try it
Mark Leybourne
Wednesday, September 03, 2014 12:45:10 PM UTC
Are there plans to migrate Javascript Intellisense from the _references.js convention of today?
Jeremy Fensch
Wednesday, September 03, 2014 12:51:28 PM UTC
Awesome news. I might have to dust off my front end chops. I also might have to get on the VS2014 train.
John Dunagan
Wednesday, September 03, 2014 1:52:46 PM UTC
This should be quite awesome. Being able to associate a VS build with a Gulp process. WIN!
Mike Kidder
Wednesday, September 03, 2014 1:56:10 PM UTC
I just upgraded from VS2010. While VS2013 seems nice but it is getting pretty bloated. My web site in 2010 compiled and was presented in 5 seconds. 2013, I have to wait 15 seconds. The default MVC project has tons of dll's referenced and all that takes time to load. I will have to check and see which of the dll references I can drop as it seems like over kill and unnecessary. The new Identity model is awful. Way too abstract for the common man to comprehend. I just need simple forms authentication with roles. Identity is a monster of overkill. VS2013 and the default project bloat is a bit of a punch in the face from VS2010. VS2013 and all the fantasy projects might be fun for a college professor and theoretical mindset, but a corporate programmer has too learn way to much and by the time they learn it, it changes. Its all about productivity. I've lost some of mine.
Tony
Wednesday, September 03, 2014 2:48:27 PM UTC
One issue I'm having with the grunt functionality is that I setup the grunt files up at the solution level, not at the project level. The plugin assumes the gruntfile is at the project level, so it doesn't detect any tasks yet. The Task Runner Explorer should list "Solution" in the Project dropdown, and support right-click actions from the solution as well as the project.

The workaround currently is to create an empty project at the root of the solution directory specifically for the purposes of grunt task detection, but I'd prefer not to have to do that.
Jeremy Bell
Wednesday, September 03, 2014 3:14:44 PM UTC
These features are really impressive, probably I'll use Visual Studio 2014 even for non-Microsoft projects.
Wagner Leonardi
Wednesday, September 03, 2014 3:34:59 PM UTC
This is awesome!
Uri
Wednesday, September 03, 2014 4:24:15 PM UTC
@Jean-Baptiste, please use the comments here or the discussion section on the VS Gallery for reporting bugs and giving feedback. http://visualstudiogallery.msdn.microsoft.com/8e1b4368-4afb-467a-bc13-9650572db708/view/Discussions
Wednesday, September 03, 2014 4:57:36 PM UTC
Does this support Visual Studio 2012?
Hansi
Wednesday, September 03, 2014 5:22:25 PM UTC
Sharing some pains on the subject of front-end workflow and VS:

I've been out of Visual Studio for front-end development for half a year.

It all started when I had a node_modules directory some kilometers deep, and visual studio started giving me errors when I tried to commit. I had to switch to the command line for that. (Update 3 came out and I still face this problem)

Since I was stuck to the commandline for commits, I slowly started incorporating all of the commandline flow. Npm -> yeoman -> bower -> gulp -> livereload. Development was FAST, but VS's intellisense for javascript was actually hurting me more than helping me. It was slow and innacurate and most suggestions were irrelevant. I finally switched to sublimetext and found it fast and satisfying.

What VS needs before I can go back to it for font-end:
a) Fix the path depth bug on GIT
b) Make intellisense better for JS
c) Be overall faster

What IS missing in my workflow is CI on TFS. I managed to get Chutzpah running jasmine tests on every build, but haven't had a look at integrating gulp into webdeploys from TFS.
Juliano
Wednesday, September 03, 2014 8:23:07 PM UTC
Excellent work! Are there any plans to integrate these tools more seamlessly with the TFS build process?
Jay
Wednesday, September 03, 2014 8:37:59 PM UTC
@Jay, yes there is, but only for Visual Studio "14". In earlier versions of VS you can simply use the post build script feature already in place
Wednesday, September 03, 2014 10:28:25 PM UTC
I am getting package intellisense for bower package names, but not version numbers.

When I attempt to "update package" I am getting an error that 'bower' is not recognized as an internal or external command.

I have the Nuget Bower package installed (version 1.3.5.2), but am new to Bower. I suspect I'm missing some simple setup step. Can you provide additional setup information in the article?
Bower newbie
Thursday, September 04, 2014 1:27:45 AM UTC
@Bower newbie,

It sounds like you don't have bower installed in global scope. Run this command "npm install -g bower" from anywhere. That will add the global bower command line support needed. I'm not sure the NuGet package does exactly the same thing as the official bower npm package does.

Also, the bower REST API doesn't allow for retrieving the version numbers. We're looking into using alternative APIs to get them.
Thursday, September 04, 2014 5:04:45 PM UTC
I am so excited about this!

This is a huge step in the right direction for Visual Studio, hooray \o/
Thursday, September 04, 2014 11:51:55 PM UTC
installed yeoman, it has a node package that exceeds windows path size.

crazy that it's 2014 and we still have this problem in windows.


I applaud making these tools accessible, I use them often, at same time, why not make your own platform do what needs to be done, ie:

improvements:

take your bundler, include capabilities like 'ng-annotate'. I should be able to include in the bundler pipeline all the goodness you get from grunt, etc... I shouldn't need to pop out into a completely different tech stack when working in VS. And no -'right clicking with extensions' doesn't work on large teams, it needs to be baked in. We need things like JSHint to be a part of the build process. Yes, you can install extensions, but if one dev doesn't have the extension, they don't get build errors through JSHint.

So basically the functionality Mads is doing with express is awesome... it's too bad though this type functionality isn't a norm in VS.

Lastly, to stay in touch with the frameworks - Angular is one of the most used - why not more attention to it ? I know Steve did a great job with Knockout, but it's not nearly as popular as Angular. I've seen some templates for Angular with Visual Studio, but it's so convoluted with 'mvc server side' stuff that I tend to start with a blank project and spend over an hour getting everything setup for a client side solution that uses WebAPI. And then running grunt build tasks, I spend another couple of hours setting up all the min paths, etc.. then when done, need to figure out how to, ie. deploy this to Azure... which seems to only like asp.net mvc vanilla deployments.

Much to do! Good progress... but dreadfully slow



Steve
Friday, September 05, 2014 3:21:26 AM UTC
These tools should be out of site and out of mind in VS. We should not have to know what the underlying tool is; just a category of the tool and an enabled/disabled switch is enough for most developers.

These convince tools have a short lifespan and less utility value in knowing them in detail.

A budding development issue is picking tools, third party libraries and development environment so that they last longer than the expected lifespan of the software solution to be developed. We've been hit by dead, near dead and especially zombie tools in 3 different $1 million+ software applications in the last 2 years. Our procurement team vets new tools for licensing issues, strength/longevity prospects and cost. The technical team will vet them for functionality, suitability and overall quality (hint: no documentation created by reflector as done by some major UI controls vendors).

This rules out many of the perpetual alpha/beta quality libraries.

Complicated sounding? Yes, if one develops throw away web sites and apps. No, if one is making a $2 to $3 million purchase of a new system expected to last for 7+ years.



ren
Friday, September 05, 2014 7:17:35 AM UTC
This is a great improvement! One more feature is missing which prevents me to do front-end development in Visual Studio - directory-based projects:

twitter.com/koistya/status/474242971781824515

I would love if Visual Studio would support project layouts similar to these:

github.com/angular/angular-seed ..or.. github.com/kriasoft/react-seed

(no .proj files, no /bin /obj ect. folders, at least not in the same folder with source files, F5 would start Gulp build process... etc.)

Friday, September 05, 2014 11:38:13 AM UTC
Konstantin - I believe that (directory based projects) is coming in VS "14" http://www.asp.net/vnext
Steve
Friday, September 05, 2014 12:48:41 PM UTC
Is there any step by step guide to run sample front end project from GitHub in Visual Studio using those tools ? With list of all the the dependencies like Node, etc.
Jacob
Friday, September 05, 2014 1:17:38 PM UTC
I'm starting to wonder whether the VS and ASP.NET teams could get into an existential crisis over all this pushing towards open source community-backed libraries and tools.
Client-side libraries such as Angular are putting question marks on parts of ASP.NET MVC and its view engines.
Now for front-end NuGet is being pushed aside by bower, MSBuild by Grunt and Gulp.
Even TypeScript has to make its case against ES6/7 (with Traceur) and Dart.

The server side .NET stack still stands ground thanks to C#, Web API, Entity Framework, and others, but for how long? We can hear Node.js and NoSQL knocking at the door more and more.

What I appreciate as a developer is to get something opinionated and coherent while providing best-of-class productivity and features. I don't want to have to roam around for the latest fashionable frameworks and tools and figure out how to make them interact. It gets too boring too quickly to have to match expectations of fellow developers in terms of technology, get paralyzed by choice, risk betting on technology with no future, when all you want is to get the job done for the client and make it maintainable for the next 5 to 10 years.
I hope that this is taken into consideration for the added value that the VS team is striving for with future releases.
Antoine
Friday, September 05, 2014 1:30:18 PM UTC
Jacob, here is a project to play with "Facebook React Starter Kit" for Visual Studio, it has node modules and Gulp pre-configured. So you would just run > npm install; bower insta; gulp build -- to build a project:

http://visualstudiogallery.msdn.microsoft.com/d65d6b29-6dd7-4100-81b1-609e5afce356
Saturday, September 06, 2014 1:11:43 PM UTC
Awesome! This is really a cool stuff with .Net framework. really great implementation by Micro Soft. It is very nice to have the feature like when you want the build status and build information with a helpful tool like this.
Saturday, September 06, 2014 5:54:30 PM UTC
@Steve, Angular is our #1 js priority for VS 14. You'll start seeing improvements in VS2013 Update 4 already.

@Konstantin Tarkus, folder based web projects have been possible since VS2005 using the Website Projects. There's no project files, just a folder. True generic folder based project support is in the works...
Monday, September 08, 2014 6:37:34 PM UTC
Looks great! But.. Who need js minification in vosual studio, but not on CI server?
Its possible to use this integration in msbuild?
Stas
Thursday, September 11, 2014 3:07:55 AM UTC
"I'm starting to wonder whether the VS and ASP.NET teams could get into an existential crisis over all this pushing towards open source community-backed libraries and tools."

I completely agree with this, Antoine... it is getting to the stage where there seems to be a constant desire to implement the latest open source fad or competitors latest idea, instead of providing a consistent stack on the MS platform, which has some areas that really need attention.

Now MS devs have been initially pushed towards jQuery, then Knockout.js, now probably Angular.js... a bit of TypeScript here and there to offset the fact that these are all weakly typed languages/frameworks that are either sponsored by competitors, or have a very limited lifespan... now Bower, Grunt, npm, Node.js while using NuGet, PowerShell, MSBuild ... *just to manage what external libraries are included and built* (never mind the whole OWIN ´keep adding bits and see if it works´ approach we have to face in vNext, with its open source naming convention, change from XML to JSON). Its becoming a jigsaw puzzle of ´what should I use now, how do I include it, what do I debug first, how the hell do I unit test this, oh god what do I do to deploy this´.

Far from being a step forward, I see this as a problem. We don´t all have the luxury of spending 12 hours a day reading and learning what the latest release of JavaScript framework X (and its 200 forks or competitors) offers and getting paid for it. Some of us actually have to deliver complex projects for a living, that consist of more than ´hello world´ and are intend to stay in Production for more than a week.

Front end devs are constantly changing their toolkit - try working with a couple of them on the course of a 6 month project - it is a constant fight to stop them from switching to some latest fad, rather than getting them to deliver what was specified.

Its basically back to coding about 15 years ago, with everything was custom created for the immediate needs, changed from one project to the next, and was impossible to coordinate between teams.
Perambulator
Thursday, September 11, 2014 2:18:42 PM UTC
Have been 'forcing' .Net devs to use grunt/bower/npm for some time now. It pays a whole heap with a bit of work. Its great I can now even silence the fewmembers of the, "yeah this is cool, but it can't be that good its not integrated into visual studio" club!!
Thursday, September 11, 2014 9:13:25 PM UTC
Hi Scott,

You guys are moving too fast. I can barely keep up. It feels like I spend more time learning new things that you guys are putting out than actually programming.

But I must say, programming in .NET is still my favorite thing to do.

Thanks a bunch for all the hard work you guys are putting in helping us build awesome apps!
Thursday, September 11, 2014 10:53:34 PM UTC
Man, I've wanted this for so long. It's a relief to know that the Visual Studio team has been listening.
Ciel
Friday, September 12, 2014 4:37:43 PM UTC
This worked right out of the box with my complex solution that uses Gulp to sort and organize the redistributable files that go between 6 different projects in a very picky way. Beautifully done. Absolutely beautiful!
Ciel
Friday, September 12, 2014 4:42:05 PM UTC
Damn, double comment. Oh well.

I also want to add, the gulpfile doesn't need to be in a visual studio project for this to work. I have my gulp stuff outside of my projects, just included in the solution as "virtual files". They still worked just fine!
Ciel
Saturday, September 13, 2014 12:30:18 AM UTC
Awesome, I was waiting for a solution like this, until now i have to remember the steps before build.

@Mansoor

On the web you are not alone, so you have to be the part of most communities otherwise you will be obsolete. Make your habit to at least visit asp.net and take a view on front page articles on daily basis after few weeks you will knew where the community is going and what you need to do to follow.
Abu Ali Muhammad Sharjeel
Saturday, September 13, 2014 1:19:46 PM UTC
Antoine, @Perambulator couldn't agree more. I don't want grunt, bower, npm, and other golum-golum tools that can't be relied on the long term, and I don't have the time to keep up with the latest version or installation incompatibilities between developers stations. I want professionally build libraries that I can relied on for the years to come, like the old good MS was producing.
thanzerv
Wednesday, September 17, 2014 3:45:48 AM UTC
The `I don't have time` excuse is so looser.

We all have problems, fact is:
I don't care, no one does.
You don't have time?
You are behind.

Choose your league wisely. Whatever your choice is, it's ok. No need to blame about that.
Bart
Thursday, September 18, 2014 2:32:04 AM UTC
@Bart: You are obviously not very familiar with requirements of enterprise development scenarios. While "don't have time" is a simplification, it is true in professional development environments where long term reliability and supportability by first party (vendor of the tool) is super important and shift in tooling easily can costs double digit or even triple digit millions.
Andi
Thursday, September 18, 2014 5:23:59 PM UTC
@Andi, the support for Grunt/Gulp/Bower/npm will be optional. You don't have to use it if you don't want/need to.
Friday, September 19, 2014 2:04:17 AM UTC
These extensions should obviously be available in any project type. There's no reason to not allow integrating of Gulp or Grunt into the standard MSBuild pipeline.

In fact, this extension should integrate into the standard MSBuild pipeline.
Jerome Haltom
Friday, September 19, 2014 2:07:19 AM UTC
And while you guys are on it, we need project references for all this new stuff. I need to be able to create a JavaScript project that creates .js file artifacts, that can be added to other projects by the mere addition of a project reference.
Jerome Haltom
Friday, September 19, 2014 8:34:12 AM UTC
Mads, thank you very much for this (and Scott for bloggin about it)! This is a huge step forward and very helpful. I'm developing a large Ember.js application and I love the fact that I can integrate grunt in VS.

Some questions:

1. I run my grunt build after the .NET build. Is there a way to integrate the task runner output in the standard VS output console?

2. I'm using a publishing profile for deployment. Is there a way to "wait" for the task runner result before compiling or deploying?

Thank you,
Stefan
Friday, September 19, 2014 2:18:32 PM UTC
@Jerome, the plan is to make it work in all project types. Because almost all project types are implemented differently, we weren't able to support them all in this initial release.

Integrating into the MSBuild pipeline out of the box is something we are investigating. It's no where nearly as simple as it sounds. You can however easily do that already by calling "grunt build" from the project's post build script.

@Stefan,
1. No, this is not currently possible. I like the idea though, so I've added it to my todo items to look into.

2. Not currently, however it is something we are looking into for upcoming releases. To do it right, we may have to hook into the MSBuild pipeline and that is not that simple (see reply to Jerome above)
Friday, September 19, 2014 3:22:15 PM UTC
Awesome! I guessed that both things aren't trivial. Thank you again Mads!
Saturday, September 20, 2014 1:01:40 PM UTC
Do I need to install node/npm separately, or am I just doing something wrong?

I get "'npm' is not recognized as an internal or external command" when I try to Right click -> NPM Install Packages.

I have installed all the vsix packages mentioned, on my VS 2013 Update 3.
Martin Lund
Sunday, September 21, 2014 12:10:27 AM UTC
Un discours de mariage rédigé
en bon français, foncez!
Tuesday, September 23, 2014 5:50:15 PM UTC
@Martin yes, if you download the windows installer for nodejs.org you'll get both node and npm globally. Right now there's a bug, you need to create an ~/AppData/Roaming/npm directory.

----

I've been using node/npm for several years now. I also started using build/postbuild for node tools to build my less/css files and min/merge/uglify my js for several years as well. I have two projects I am converting from using chirpy now (since that tool doesn't work in VS2013).

Node has served me very well, and honestly when I have to work in VS and with C# it's often a bit of frustration compared to how I now develop with node. It takes a different mindset.

Also, I really wish that VS had an "empty" or "bare" project for stuff that is similar to a web project, where there is no compile step (other than build/postbuilds specified), and has a project.ignore file for convenience. This way you could use VS to edit projects that will be built with other systems and work within a given solution. This would have been useful for years before an actual node project type was available.
Tuesday, September 23, 2014 9:24:07 PM UTC
A small heads up for those looking to jump into these.

If you need to compile your own LESS mixings into Bootstrap using Grunt, then forget about Bower. You need to clone the full Bootstrap repository from Github and install dependencies with npm.

You can then register your own copy of Bootstrap as a local package (file:///) with a Bower project, if you want.
Hamza Hakim Zade Hijazi
Wednesday, September 24, 2014 11:21:29 AM UTC
Did anyone try bower together with TFS GIT, I am having not much success. I did the protocol configuration to use http:// instead of git:// but always receive and error when doing a bower install git://tfs...#version.

Juerg Staub
Name
E-mail (will show your gravatar icon)
Home page
 
Comment (Some html is allowed: a@href@title, b, blockquote@cite, em, i, li, ol, pre, strike, strong, sub, super, u, ul) where the @ means "attribute." For example, you can use <a href="" title=""> or <blockquote cite="Scott">.
Live Comment Preview

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.