Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How do Bower, Grunt and Yeoman fit into a Visual Studio .NET workflow?

Tools such as Bower, Grunt and Yeoman have surged in popularity recently.

Whenever I've read about them or come across them in an article, I've dismissed them as tools used for Mac-based front-end devs or PC-based but not on the Microsoft stack - Sublime Text etc.

Visual Studio has NuGet, project templates, MSBuild, MSDeploy, TeamCity/TFS Azure etc. and I generally consider VS has being a very highly automated ecosystem (some say it makes us productive at a cost of understanding).

How are these tools being used by ASP.NET devs on VS?

Note: This is not an opinion-based question, I'm looking for real-world examples of how these tools are being used.

like image 383
Luke Puplett Avatar asked Oct 29 '14 10:10

Luke Puplett


2 Answers

There is a Package Intellisense extension for Visual Studio which adds bower and npm package support

enter image description here

Grunt/Gulp launcher extension for launching grunt/gulp tasks

enter image description here

Read this awesome article written by Scott Hanselman for more info:

http://www.hanselman.com/blog/IntroducingGulpGruntBowerAndNpmSupportForVisualStudio.aspx

UPDATE:

These features are now fully integrated into Visual Studio 2015: http://www.asp.net/vnext/overview/aspnet-vnext/grunt-and-bower-in-visual-studio-2015

Great tips from john papa: http://www.johnpapa.net/get-up-and-running-with-node-and-visual-studio/

like image 140
Marian Ban Avatar answered Dec 07 '22 00:12

Marian Ban


As per Scott Hanselman's blog posting, he says this about the reason why a VS dev might want support for these tools:

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.

Though I'd still be interested in other people's take on how these tools fit in to the 'workflow' of a VS developer. For example, "Before I installed Grunt, I wasn't able to easily... blah."

Update

I'll stick some updates in here as I learn things.

  • So, new learning no.1: Yeoman scaffolds front-end, client-side code. Whereas VS scaffolds server-side stuff and project templates (that don't change for months/years), Yeoman can help with boilerplate for fast-changing JS MV* frameworks, for example.

  • New learning no.2: the tooling is not ready for prime-time enterprise dev.

The first problem is that npm downloads dependent packages into nested subfolders and recurses this model exhaustively, so you end up with folder paths that are 100s of characters long. Windows and some tooling goes nuts. There are workarounds but its a serious flaw.

Latest Node and some added command line options now make this better behaved.

Developers running Windows are often in enterprise settings which means proxy filters and auth. For me, I needed to install Cntlm local proxy to get NPM and other tools to work via our proxy, which violates our IT policy, I just didn't tell them.

Some of NPMs packages seem to want to clone Git repos using SSH! Port 22 is not open; because the community is so Linux/Mac non-enterprise oriented, such issues arise because they're not a problem for so many creative-agency devs and then can hang around for months.

  • New learning no.3: how dynamically downloaded JS files end up as content in the project file and thus added to an MS Deploy package is still an unknown.

Update on learning 3, we created a build that just transformed the config files, then we used the MSDeploy command line to copy files individually to the destination server. Not something I'd do if I were working alone, it took weeks on and off, to automate all this.

like image 35
Luke Puplett Avatar answered Dec 06 '22 23:12

Luke Puplett