Yeoman, Grunt, and Bower

Aside from being a top end legal team, Yeoman, Grunt, and Bower are also the names of some front-end development tools I use when working on new projects these days or whenever it’s going to be easier to throw together some code and test it out in a testbed rather than embedded in a larger project. First I’ll go over what role each of these has in the development of a modern website front-end. Then I’ll take a brief side trip into a tool (Node.js) which isn’t directly relevant to any of them, but one which is required in order to install them. Then we’ll get into some specifics for all three as I demonstrate using them to get started on an AngularJS project.

Yeoman is the code generator, it fulfills a role similar to that filled by the Rails app if you’ve ever used Ruby on Rails because it can be used to generate whole projects or individual pieces of code depending upon the specific code generators it has installed. It gives you a quick shell from which to start a project.

Grunt is the builder and utility tool. As with Yeoman it’s modular in nature and as a result it can fulfill a huge variety of roles. Typical things you might call upon Grunt to perform would be concatenating multiple CSS or JavaScript files together for faster download, minifying CSS or JavaScript files (again for faster download), running a small local server to make developing your website easier, looking for errors in your JavaScript, running JavaScript unit tests, running compilation tools for CoffeeScript, LESS, or Sass, and the list goes on and on. If you have a Java background you might think of Ant as the closest analogy for Grunt.

Finally, Bower is your web component installer. If you find yourself needing to install a JavaScript library or a CSS/JavaScript framework, Bower can handle that and even make sure that any other components upon which it depends (for example, Backbone.js requires Underscore.js) are also automatically installed. Java tools like Maven and Ivy offer similar functionality so that each developer can get the libraries he/she needs installed without having to check all of them into version control systems with the code being developed.

That side trip I mentioned

As strange as it might seem to require an installation utility (npm) in order to install an installation utility (Bower), that’s exactly what I’m going to tell you to do. These days any JavaScript software worth its salt seems to be installed in much the same way. First you go get the latest version of Node.js (there’s a big green install button on the middle of the http://nodejs.org/ page). When you install that you’ll also pick up a nifty little utility known as the Node Package Manager or npm for short. With npm installed you can then install all three of the aforementioned tools Yeoman, Grunt, and Bower.

As I mentioned earlier, you use the npm tool you just installed to install the other three by running “npm install -g yo” (the details are covered on Yeoman’s website: http://yeoman.io/ but that’s actually all you have to do). You’ll see npm download, compile, and install tons of stuff but you won’t actually be involved in the process. In that respect it’s much like other package managers like Yum or RPM.

Finally you’ll need some kind of Yeoman generator installed in order in order to generate our starting shell: “npm install -g generator-angular”

Yeoman

With all the installation out of the way, let’s create a directory for a new project (“mkdir TestApp”), change directory into the newly created directory, and just type “yo” at the command line and see what we see.

YeomanPick “Run the Angular generator” and hit enter, then answer the various yes or no questions it asks in order to generate the shell you want for your app. At the end it will also run npm to install the local copies of tools you may need and Bower to install the various libraries you need for your shell (for example, AngularJS and jQuery).

Yeoman has now fulfilled most of its mission but I want to look at some files it generated and then come back to using it as a tool even after we have our shell. There are many files worth noting which Yeoman generated but three in particular are:

  • package.json – This file tells npm which Node.js packages need to be installed in this particular project. Most of what you’ll find in here are packages Grunt needs to do its job. Rather than installing these globally, they are instead installed on a project by project basis so you can have different versions of the tools used by different projects.
  • bower.json – This file tells Bower which components to install in the app/bower_components directory. These are JavaScript and CSS components which you’ll use within the website you’re building.
  • Gruntfile.js – This file is task instructions for Grunt so it knows how to perform a set of different tasks for a given project. If you look near the bottom of the file you’ll see that the Angular generator has created a file with the tasks “server”, “test”, and “build” which in turn call many other sub-tasks to perform their work.

Finally it’s worth noting that that’s not the final use that Yeoman can have in our development. Just as a Rails user can continue to use the Rails command to generate new models, migrations, etc. within an already constructed project, the Angular generator can be used to generate services, routes, directives, filters, etc. as detailed here: https://github.com/yeoman/generator-angular

Grunt

Running Grunt from the command line with “grunt” should perform a default sequence where the JavaScript code is checked for errors, unit tests are run, and finally a “distribution” version of the application is built into the “dist” directory. Grunt will have concatenated CSS files and JavaScript files into common chunks like 7d151330.main.css, bd6ce9e3.plugins.js, c2ac0a01.scripts.js and the references to the original names within the HTML will have been replaced with the new file names. When you update some of your scripts and recompile, the file names will be different and there will be no need to worry about browsers continuing to use old cached versions of your scripts. You never have to perform this task, all of the files within the app directory may be deployed as soon as you are ready to do so, but Grunt performs a variety of optimization tasks which can make for a more performant site if you like.

One of the handiest things Grunt offers via the Gruntfile.js which was created is “grunt server”. Running that will compile files which you might have that need compiling (for example, if you use CoffeeScript rather than JavaScript or you’re using Sass), start up a server running the application, launch the index.html page in your default browser, and then watch for any changes to the files as you edit the CSS, HTML, and JavaScript and re-run compiles as needed and reload the page within the browser as you work on the website. I just love this feature because of how easy it makes it for me to work on features and immediately see the results in my browser, often I don’t even have to lift my fingers from the keyboard or switch apps to my browser because I can see if my changes accomplished what I want simply by looking at the automatically refreshed page.

At this point you would be forgiven for thinking that there was little point in installing Node.js except that it gave us the npm tool we needed to install all our other software, but actually Node.js is also being used behind the scenes by Grunt to run the local server I mentioned above.

Bower

Last but not least is Bower. It offers the opportunity to search for packages you may need in your project (for example, “bower search underscore” to find Underscore.js) and install them in your project (for example, “bower install –save underscore” to install the aforementioned package and add it to the list of dependencies in the bower.json file). Bower is also capable of understanding the difference between packages needed for development (for example, unit testing tools) and those needed for both development and runtime.

Since the .gitignore for the project will normally list both the app/bower_components and the node_packages directory, you won’t be checking in those pieces with your code (assuming you use Git as a version control mechanism). Instead, whenever checking out the project onto a new machine, just run “npm install” and “bower install” within the project directory and the tools will use the package.json and bower.json files to make sure all the needed pieces are installed.

But that’s not all

Keeping these tools up-to-date might prove difficult if not for the fact that the Node Package Manager is capable of doing so automatically via “npm update -g” for all your global software like Yeoman, Bower, etc. or “npm update” within the project directory to update Grunt packages, etc. I’m not going to contend that it always goes flawlessly, lots of this software is still beta and undergoing lots of changes so there have been days when I needed to remove it all and reinstall; but that’s rare and usually takes only a few minutes.

About these ads

9 thoughts on “Yeoman, Grunt, and Bower

  1. eonlepapillon

    A small “mistake”? First paragraph of section Grunt. The text “…into the “dist” directory. Bower will have concatenated CSS…” should probably be “…into the “dist” directory. Grunt will have concatenated CSS…”?

    Reply
  2. Pingback: Yoeman - Steel Bison Dev blog

  3. maverickpuss

    thanks for John for the nice and helpful post, it’s a great summary indeed and really helps me a lot!

    i’ve translated it into Chinese, maybe there will be some guys that find this post through baidu.com, if he saw this, he could go to my blog to see the translated version, any advises will be apreciated :)
    我把这个翻译了,放在我的博客上,如果有从搜索过来的朋友想看看的话,若有理解不对的地方欢迎提意见~

    the translation: http://184.82.206.139/post/12

    Reply
  4. Ben

    What IDE would be best with this? As a Java developer it would be ideal if I could get this working with an eclipse project. I don’t really want different IDE’s for the client side and the REST API.

    Reply
    1. John Munsch Post author

      I tried to use Eclipse when I switched to the world of JavaScript/HTML/CSS full time because I had used Eclipse for years as my Java IDE. However, I found its parsing of JavaScript to be substandard and it just didn’t have some of the many features I really wanted.

      So I switched from Eclipse to WebStorm and have been quite happy since. So, where does that leave you. I would recommend that you give IntelliJ IDEA (http://www.jetbrains.com/idea/) a serious look. Lots of people like it as well as or better than Eclipse and it’s the engine behind WebStorm. If it’s as good for Java as people say then I think you’d have a pretty good IDE that works cross environment.

      Reply
  5. Ben

    Btw, as a follow up to this. I’ve been using eclipse to develop my REST backend in Java and testing with SoapUI. I’ve been treating the angular client as a separate project developed using the command line with yeoman tools and notepad++ for editing source. The problem I was having was how to test both of these together. I recently found the solution here http://alfrescoblog.com/2014/06/14/angular-js-activiti-webapp-with-activiti-rest/. Basically I’ve setup an apache server and configured it as a reverse proxy. Requests for rest web services get passed onto the tomcat server running in eclipse and requests for client resources get passed to the node.js server started when I do grunt serve. Thought I’d share because without this I was struggling to get a satisfactory workflow.

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s