How to put custom properties on Aurelia routes

I’m using Aurelia to build a web application and I wanted to be able to put custom properties on my routes and access those properties in my view. Specifically I wanted to be able to associate font awesome class names with each of the routes and then render the appropriate html in the view. To accomplish this you can add a settings property to the route element and put anything you’d like in there.

Once you are rendering the route elements in the view  you can access the element with


Below is an example of setting up a bootstrap navigation with font awesome icons.

First, configure each route with the corresponding font awesome class

Then, use the font awesome class when rendering the navigation

Deploying a production Aurelia app to Azure

I’m using Aurelia to build a production web application at work and I want to be able to host the site on Azure. I also want to be able to deploy automatically each time I check code in on my Bitbucket git repository. If you follow the Getting Started guide on the Aurelia site everything works as expected because all of your files are in the root of the git repository, but they haven’t been bundled, minified, etc. Once you step up to the Production Setup and you generate your Aurelia application with the yo generator, then the default deploy from source workflow does not work, because in the production setup you use gulp to build an optimized version of the web application and it puts that in a /dist folder, which is no longer the root of the git repository. Here is how I’m currently deploying an optimized Aurelia web application to Azure automatically when we check code into our git repository.

      1. Generate your skeleton Aurelia application

        Go through the Production Setup instructions and create the production template for your Aurelia application.

        npm install -g gulp jspm yo generator-aurelia karma-cli
        yo aurelia
        gulp watch
      2. Add a web.config file to the project

        By default, websites on Azure do not have a MIME type mapped for .woff or .woff2 files. The Aurelia application that gets generated uses font awesome which includes both .woff and .woff2 files so we need to tell Azure (specifically IIS) to serve those files or else we’ll get a 404 not found error for those files when we run our application on azure. The web.config goes in the root of the project and is shown here

      3. Modify the Paths.js file to define the destination folder

        We need to add a new destination folder where we want to copy the production files to. The simplest way that I’ve foundvto do this is to modify the build/tasks/paths.js file to include a new wwwroot property as shown here.

      4. Modify the Clean.js file to clean the destination folder

        Now that we have a new destination folder defined, we need to clean it each time we build our application. To do this, modify the build/tasks/clean.js file to include the new destination folder as part of it’s cleaning process as shown here.

      5. Add a gulp task to package the production application

        The production template by default has Gulp tasks that will build an optimized version of the application and place it in the /dist folder. The problem for deployment is that the /dist folder is not everything that is needed…we also need the /styles folder, the /jspm_packages folder, config.js and the index.html page from the project’s root. In order to accomplish this let’s add a package.js file to the /build/tasks folder that will copy over everything we need to run the application into a /wwwroot folder as shown here.

      6. Modify your .gitignore file to include wwwroot/jspm_packages

        By default, the .gitignore file that the yo generator scaffolds will ignore the jspm_packages directory. In our case, we need to include the jspm_packages directory underneath our wwwroot folder. In order to accomplish this modify the .gitignore as follows:

      7. Package the application for deployment

        With the package.js gulp task setup, you can build and package the application for deployment by running

        gulp package

        After the gulp task completes, you should now have a wwwroot folder in your git repositories root

      8. Add the wwwroot directory to your git repository

        We’re going to use a git sub-tree to push the wwwroot folder to a separate branch. This new branch will be what we tell Azure to deploy from when a commit happens.

        git add -A
        git commit -m "initial wwwroot commit"

        After the gulp task completes, you should now have a wwwroot folder in your git repositories root

      9. Deploy the wwwroot subtree to a different branch
        git subtree push --prefix wwwroot origin live
      10. Develop normally committing/merging your changes to your master branch

        Continue to work as you normally would, committing and merging into the master branch.

      11. Configure Azure to deploy from the live branch

        When you setup Azure to deploy from source, you have the option to choose which branch you want to trigger the deployment
        from. In this example you would choose the “live” branch.

      12. Deploy to production

        When you are ready to do a production deployment, run gulp package, commit the changeset and run the subtree push command

        gulp package
        git add -A
        git commit -m "<your message here>"
        git subtree push --prefix wwwroot origin live

I know that the aurelia bundler is going to be updated to make this process easier and as it does I’ll update the post.

Connecting KanbanFlow and Slack

At work our team uses KanbanFlow and Slack to keep track of project work. I wanted to get notifications in Slack when a task is created or updated so I setup the integration using Zapier and the beta version of KanbanFlow’s zap. It works as far as getting notified when a task is either created or updated (it does require two zaps to set this up) but I wasn’t able to get the data that I wanted (Which user created or moved the task?).

I’ve contacted KanbanFlow’s support to request the additional information be made available in their zap but in the meantime it gave me an opportunity to create a simple web service to integrate KanbanFlow and Slack the way I wanted it.

The result can be found on GitHub. Any comments or ideas for improvement are welcome! So far it’s been working great.

Following the Feature Branch Workflow

When working with Git on a distributed team it’s important to follow a process that working code accessible to everyone on the team. The simplest workflow that I’ve found to make this work is the feature branch workflow. The basic idea of this workflow is to always keep the master code branch production ready. When you start to work on anything (feature, bug, spike, task, etc) you create a new branch, do your work in the branch, and then issue a pull request to have your branch’s code merged back in to the master branch (thus making it ready for production deployment).

A side benefit of using pull requests is that it creates an opportunity to incorporate code reviews into your SDLC process. Below are the steps to make it all work. I’m using BitBucket in this example but it works the same for GitHub.

Create a new branch off of the master branch to hold the new work that you are about to do. Make sure you use a meaningful branch name.

git checkout -b add-email-create master

This creates a new branch named add-email-create off of the master branch. The -b parameter will create the branch if it doesn’t already exist.

Now, implement your code as you normally would. Code … add/modify/delete … commit.

At certain points, and before it’s time for a code review you can push your branch’s code to the central repository

git push -u origin add-email-create

This will push the add-email-create branch’s code to the central repository. The -u flag adds it as a remote tracking branch. After setting up the tracking branch, you can call git push without any parameters to push your code.

Once you’re ready for a code review, you commit/push the latest changes in the branch to the central repository so that other team members can view it

git push

Now you’re ready to create a pull request. From bitbucket you can view the branch and select “Create Pull Request” from the menu.


Once you select “Create Pull Request” you can edit the notification message, description, recipients, etc.


You and your team can comment on any line(s) of code that need to be discussed as part of the code review. Any additions/changes can be made and checked in against the feature branch and those changes will be included for review/discussion in the code review.

Once the changes are reviewed and ready for deployment they can be merged back into the master branch by clicking the “Merge” button in the Bitbucket UI.

Now that the feature branch code has been merged with the master branch, each developer should update their local copies of the master branch by running

git checkout master
git pull

Now whatever automated build/deploy/test/package/etc process that is triggered by a commit to the master branch kicks off.

After the feature branch has been merged into the master branch you can delete it from your local workstation with

git branch -d <branch name>

That’s it. Now pick the next feature/bug/task from your project and repeat the process.