Great extension and really helped me get some outsourced front-end code into our Visual Studio environment. In order to take this to the next level, it would be great if there were built-in support in Visual Studio for getting Gulp into the build pipeline so that we can really take advantage of this in Continuous Integration scenarios. There is a really good article about this by Steve Cadwallader on his blog, which can be found here:
It is a nice idea but it completely breaks Visual Studio's git integration. To me, git is much more valuable inside VS. I can run gulp, grunt, etc just fine outside of VS with very little reduction in capability from what Task Runner Explorer offers. Not so with git. Maybe if/when this bug https://connect.microsoft.com/VisualStudio/Feedback/Details/865064 is resolved I will give it another try.
You don't need a file save event to bind to. Just use the Grunt watcher. Takes a little time to get Grunt integrated in your workflow, but this Task Runner makes it so much simpler. Staying in VS makes it more transparent.
This works great! I have 2 issues though. One was mentioned by another user about the tasks taking too long for the production files to be ready before publishing. My second issue is that any new files created by the tasks are not automatically included in the project.
No issues so far, installed it and tested it out on one of our large AngularJS projects at work without any modifications.
I wish there was a way to assign an alias to a button (on the toolbar). We have build.local and build.staging.
//Update: Yes, Hotkeys functionality would actually be better. I would probably prefer the hotkeys over a physical button (but some might like the button). (it deleted your reply when I updated this text).
I put together a simple spike and everything worked well. Once I transitioned to a larger project the extension stopped working when I right click the Gruntfile. Do you have a place for submitting issues?
Great job with the extension. It will change the way we develop client-side code going forwards.
Getting there... a great preview of what is to come.
Probably worth mentioning, especially to 'new-age front-end dev' newbs like myself, that you need to have done 'npm install -g grunt-cli' from your command line to get the Task Runner Explorer to work with Grunt... it won't parse the gruntfile.js otherwise. I think I thought that having listed grunt in the package.json devDependencies that would be sufficient, nor is doing 'npm install -g grunt' enough ,you need the cli tools (which are themselves dependent upon the grunt package). Just a trick for new players!
When I talked with Mads at the 2012 Build, he said they hadn't "wrapped their heads around" tools such as Grunt and libraries such as Angular. That was frustrating given the seamless integration that WebStorm had...
Well, now! Consider them wrapped! Good show, guys, good show. Now bring it home with VS14 and Monaco.
I do not install gulp globally, so attempting to execute gulp from the PATH won't work in my environment. However, gulp is installed into my project, so it can be found in node_modules/.bin/gulp.cmd. Presumably, most users who have a gulpfile will probably also have gulp.cmd, so I don't believe there is any reason to depend exclusively on gulp being in the path.
+1 The majority of npm projects don't need grunt or gulp (or broccoli or assemble or...). And for those that *do*, it's still generally recommended for npm scripts to be listed as aliases for the grunt/gulp/etc tasks for discoverability. (npm is the common thread amongst all of these, anyhow, so package.json is guaranteed to exist and be the first place people look).
Excellent extension! The only problem so far is that because I use grunt-watch heavily, I get a very large amount of text in the output area. So large that at times it takes more than 10-20 seconds to open after long term use. Reopening the solution (or restarting the task) solves the problem temporarily. I think this could be an easy fix, perhaps to limit the output buffer to some reasonable size.
Keep up the great work!
Closest I was able to get with this is to set an environment variable as a post-build task before calling gulp/grunt. Then, in your task, you can check process.env.whatever.
Pre-build event command line:
var minify = process.env.NODE_ENV === "Release";
When opening Task Runner explorer by right clicking on gulpfile.cs I get an error message saying "Failed to load. See output window for more information." The output window says "Referenced file '~/Scripts/_references.js' not found."
Running the latest version of Task Runner Explorer.
If you don't have a _reference.js file in your project, but you have Web Essentials 2013 installed, then it's really easy to add one. Simply right-click the /Scripts/ folder and go to the Add submenu to find an easy way to add references.js.
I think you'll find the _references.js file is unrelated to the TRX.
Drop down "Show output from:" and select "Task Runner Explorer" and that will show you the error for TRX.
If it runs on one branch and not another, are you sure you have installed gulp so it's available to the branch you have the problem with?
I have just started with Task Runner Explorer, and it is not only extremely useful, but helped me with learning Grunt and the transition to Grunt in a number of projects.
When you say in the description that only Web projects are supported, does that include both Web site projects and Web application projects?
Would there be any benefit in parsing gruntfile.ts in addition to gruntfile.coffee and gruntfile.js? I imagine not, because gruntfiles are usually relatively small. (It might be easier to get Intellisense on TypeScript files than on standard JS files, but I guess that's not in the scope of this extension.)
I have one issue on a Web site project -- I've attached a build binding to a grunt task, but the output from the task doesn't show up in the Output pane when I build, nor in the Task Runner Explorer terminal pane.
1. open solution with many project
2. unload project (solution explorer -> project -> unload)
I think, VisitAllProjects method should check "if(project.ProjectItems!=null)"
In a project from CTP5 I had Gruntfile.js with tasks and subtasks. The subtasks displayed in task runner and I could run them independently. Which is not uncommon if you have say a Sass task with both dev and prod versions.
This same gruntfile in CTP6 Task Runner no longer shows the subtasks.
The Task Runner wont find projects with a gulp file if those projects are inside a Visual Studio Solution Folder. If you move your project out of whatever solution folder you have it in and drop it at the root of your solution (in Visual Studio Solution Explorer), then all will be cool after school.
Hope that helps someone.