Using assemble.io with yeoman.io's webapp Gruntfile
02 September 2013 by @ddprrt | Posted in: Tools, Workflows, grunt, yeoman
A tool like that was much needed by our department once we switched from an inconvenient clutter of Ant builds, PHP includes, CodeKit and command line calls to our yeoman/grunt setup, so I gave it a try. And I was stunned how easy the set up was and how perfect it fits into the environment we created based upon yeoman's web app generator.
In this short article, I'll show you how you can use assemble.io with Handlebars templates and the basic yeoman.io web app generator Gruntfile.
When compiling, assemble.io clutches together bits and pieces from three different resource groups:
- Layouts: The basic layouts, with all the basic HTML setup, navigations, wrappers, and so on.
- Pages: Every page without the clutter around it. Just the "content" of a site
- Partials: Reusable Modules that can be included with different parameters on any of the above. Partials can also include other partials.
The assembling process goes as follows: Every page is included into a layout, with partials completing everything in-between.
A basic layout can be like that:
We already included some partials (navigation and footer), as well as some parts we define later in the pages. Either with parameters (title) or with content (body).
With the whole HTML layout in the layout modules, a page is a lot cleaner. It defines parameters in a sort of setup header, after that there's the content that is included when calling
I guess you get the idea by now... I'll cover the usage of parameters and stuff sometime later. This is all about the grunt setup.
For our websites, those module categories do have separated folders in a template folder in our app directory:
app |-- templates |-- layouts |-- pages |-- partials
Adding it to yeoman.io's webapp Gruntfile
yeoman.io's webapp setup is the best way to start any web related project. Plus, the generator can be easily adapted to be used with your workflow in particular (I guess this will also be an article for later).
Anyhow: The cool thing with its Gruntfile is, that you not only get compiling and building done, but also have some sort of developing environment, where you can easily access all the files in it's plain source, unminified and as-is. We will now setup grunt for both the building process, as well as the "grunt server" task for your dev environment.
First of all: Be sure to install assemble correctly after scaffolding your web app:
yo webapp npm install --save-dev assemble
Open your Gruntfile.js, and add assemble right after defining the module:
With that done, we can do the basic setup for the assemble task. Just add this part anywhere inside the
Pretty self-explanatory. We'll define the location of layout, partials, and some other stuff which you can ignore for now. Note that partials can be an array of folders, make use of that.
Before we'll check on the (oh so sweet) on the fly compiling when spawning a project dependent server, we just check on how to compile this baby when creating a build.
With the setup being complete, just add a line for the "dist" target. This is yeoman's default target for anything building and distribution related.
We have defined layouts and partials in the setup, the dist-target tells us where pages are located and where the assembled output should land. It's pretty straightforward: Just put all the pages in
<%= yeoman.dist %>/, the output directory of the build process.
Note: This can create some conflicts if you're using the
htmlmin task, since it tries for itself to copy everything HTML related from
<%= yeoman.app %>/ to
<%= yeoman.dist %>/. Just put everything done by assemble into a temporary directory, and let
htmlmin (which strangely never worked for me...) fetch the files from there:
Voil&aaucte;, you're done.
Now for the fun part: Having it compiled on the fly while changing your source files, and live reload it in your browser.
To achieve that, grunt creates a TMP directory where it puts all compiled stuff into. The server also points to that directory. So for having our HTML files assembled, just add this line of code to our assemble setup:
If you start your server the first time, all pages are compiled and available. If you want to update your server anytime a
*.hbs file changes, add the following line to the
Which actually just says: If anything changed in our layout/pages/partials folder, execute the assemble task again!
To have the changes displayed without refreshing, tell livereload to have a look at the HTML files compiled into the TMP directory of the server:
And you're done! Enjoy!
I got some great feedback in the comments. Thank you guys, you're amazing! Here are some issues I forgot to address:
Peter pointed out that with the current setup,
usemin won't be able to run through your code and compile scripts and style files. You can either point the
useminPrepare task to one of the template or partial files, or you just direct them to the
assemble, which I forgot to add anyways. Thanks Sarith for pointing me onto that one!
Thanks again for the great feedback! I really appreciate it!
As Mark Paul pointed out, you need some updates in your usemin configuration, otherwise you won't get any
Thank you for mentioning!
Grunt and yeoman are found their way into our development process rather quickly, and I think assemble.io will also be a part in our development future.
Setting up was rather easy and took me -- including research on how to use this in the first place -- about half an our. Plus, assemble.io solves major issues we faced after switching to yeoman+grunt:
- PHP includes weren't possible anymore, with assemble we can put template parts in separated files again
- With the much cleaner Handlebars syntax it's possible to prepare those modules for a later refining, e.g. to produce TYPO3/Wordpress/Name-your-CMS modules.
If your website deployment is based upon yeoman and/or grunt, you should definitely give it a try.
Me again. The Gulp, Yeoman, Bower book is pretty sweet. Just saying.
Comments? Shoot me a tweet!