DarksideCookie

I started building web-based software professionally around year 2000, just before the big IT crash in Sweden. It started out being just hacing together HTML, mostly using tables, and a little JavaScript. But slowly evolved into building ASP applications with VB Script and COM-components in VB. Since then, I have been in and out of the webdevelopment scene a whole bunch of times, and very little has changed. It is still HTML/CSS/JavaScript over HTTP…

Yes, on server-side there have been some changes. First an abstraction into WebForms, and then back to MVC. And to me, ASP.NET MVC is pretty similar to classical ASP in many ways. But the front end has pretty much stayed the same. It is still good ol’ HTML and JavaScript…and CSS of course. However, having been away from it for a little while now, coming back I realize that the scene has changed. A lot… Yes, the languages are unfortunately the same, but the methods have changed a lot.

The thing that has changed the most is that we are using MUCH more JavaScript and CSS. MUCH more. And that creates new requirements. Requirements like bundling and minifying, as well as testing even our front-end code. And in a lot of cases, we are authoring our code in other languages and have them “compiled”, or “transpiled”, into JavaScript and CSS, to make up for their “shortcomings”. Whether it be using CoffeScript or Dart for you JavaScript, or LESS or SASS for your CSS, it needs processing before we can use it… And this new way of building things has created the need for a front-end build pipeline… At least if you want to be really productive.

Most of the front-end stuff is built around tools we as C# devs are often unfamiliar with, so I thought I would just write down how we have solved it in the last couple of projects I have been working on. It might not be the best solution, but it is a working one. We all have different needs and workflows, and this has worked pretty well for us. But we are continuously tweaking our flow to get it better. And if you have opinions about it, feel free to voice them in the comments below, or by contacting me through some other channel you seem fit (like the contact form on this blog).

Ok, so let’s start building our pipeline! The most obvious way to start out is by accepting that we will be doing a lot of this using Node.js and JavaScript. Yes, that is correct! We will use JavaScript to create the stuff that, among other things, builds JavaScript. Very meta…

So I am just going to assume that you have Node.js installed, and that you are at least a little familiar with it. If not, you need to go and get it. And probably go and get some basic node knowledge. At least enough to know how to run npm, the node package manager… Actually…that is all you need to know about node. The rest is just JavaScript…

In my last project, we used TypeScript and LESS, so that is what I will use for this walkthrough. But you can use whatever you want. However, if you use some other languages, you will need other node modules to transpile them. But you will still get the basic idea in this walkthrough…

I am going to use a very simple folder structure for my code in this demo. I have one folder called src, in which I store my TypeScript files, and I have one called styles, in which I will keep my LESS files.

The first thing we need is some form of task runner. There are 2 VERY common choices here. Gulp and Grunt. Grunt used to be the sheriff in town, but lately it seems as though Gulp is the new beez kneez. And now, when you read it, there might be something else. Welcome to the wonderful world of front-end development. It is a very rapidly changing world, with LOTS of opinions.

Grunt is based on creating a bunch of configuration and use that to tell it what to do. Gulp on the other hand is code based. We write JavaScript telling Gulp what to do. In most cases you start out with defining what files to work with, then you chain the things you want to do to them, one after the other. A very smooth, and flexible, way of doing it in my mind.

Gulp is installed using npm. You can run Gulp both as a local and a global install, but when it comes to Gulp, I prefer a global install for different reasons and personal preference… Installing it globally lets you run Gulp tasks in the command window by just typing “gulp <task>”. If you install it locally you have to write “npm run gulp <task>”.

Next we need to install the modules we need to help us with the stuff we want Gulp to do. Remember, Gulp is just a smooth taskrunner, pretty much anything you want to do in it, is a separate module. Let’s start by transpiling our TypeScript into JavaScript. For this, you can use a module called “gulp-tsc”. So just install that using npm…

Just like when choosing taskrunner, there are often lots of different modules to choose from. I have looked at some of the options and just chosen one based on my gut feeling. Or, to be honest, by running a few of them to see which seems to work the best. Just have a look at the options and go for the one you like. If it doesn’t work well, when then you can always just replace it!

Gulp assumes that there is a file in the root directory called gulpfile.js, so let’s add one of those. It will be used to define the different tasks you want to use Gulp to run. In this case, I want a single task that I will call “default”. Calling it default means that Gulp will default to using that task if no specific task name is supplied. It looks like this

var gulp = require('gulp');
var typescript = require('gulp-tsc');
 
gulp.task('default', function(){
  // Task functionality
});

As you can see, you need to start out by “requiring” gulp. In this case, as we need to compile TypeScript, we should also “require” the gulp-tsc module that we just installed.

The first thing to do inside the task is to figure out what files to work with. This is done by calling a function called src() on the gulp object. To the src() function you pass a string, or array of strings, containing Unix glob filters. In this case, using “src/*.ts” will suffice.

The return value of src() is chainable, so we can just tack on what ever you want to do with the files that have just been selected. In this case, “piping” them to the TypeScript compiler seems like a good idea. And then finally they are piped to gulp.dest(), which tells Gulp to write the result(s) to the defined location. Like this

gulp.task('default', function(){
  gulp.src('src/*.ts')
    .pipe(typescript())
    .pipe(gulp.dest('build/js/'))
});

Ok, so now we should be able to get the TypeScript transpiled to JavaScript using Gulp. So let’s try it. To do that, create a simple TypeScript class called Person.ts in the src folder, and add the following TypeScript to it

class Person {
    fullname : string;
    constructor(public firstname, public lastname) {
        this.fullname = firstname + " " + lastname;
    }
}

Next, open a command prompt in the root directory, and type gulp and press enter. This should result in something similar to this

And if you look in the directory called “js” under the “build” directory in the root, which was just magically created, you will find a JavaScript file called Person.js containing the transpiled Person class. Sweet!

Sidenote: A neat feature that very few people seems to know is that if you browse to the root directory in Explorer, you can just type “cmd” in the addressbar and press enter to open a command line at that location…

Next up is to add some LESS. So let’s put a LESS file called styles.less in the “styles” folder. Add some simple LESS to it. Something like this

body {
    margin:0;
    padding:0;
    
    header {
        background-color: #ccc;
        font-family: Verdana;
        font-size: 14px;
    }
}

Next, let’s add LESS tanspiling to our gulpfile. First off, we need to “require” gulp-less, and then use that in in a new task called “styles”. This task selects all the less files in the “styles” directory, pass them to a the gulp-less module, and finally writes them to “build/styles”. Like this

//...other require statements...
var less = require('gulp-less');
 
// default task
 
gulp.task('styles', function() {
    return gulp.src('styles/*.less')
        .pipe(less())
        .pipe(gulp.dest('build/styles'));
});

And this will obviously fail as the gulp-less module is missing. So use npm to install it, and then run “gulp styles” in the command prompt.

Once again you are greeted by some colored text output from Gulp, as well as a new “styles” directory under the “build” directory. This directory will contain styles.css, which contains the transpiled css.

Ok, so that is pretty sweet! But having to run two different commands to build our front-end stuff is a bit annoying. So let’s modify the gulpfile to run both at the same time. This is done by renaming the default task to “typescript”, and adding a new task called “default”. But instead of passing a function as the second parameter to the default task, we’ll pass an array of strings with the names of the tasks we want to run. In the end, the gulpfile will look like this

var gulp = require('gulp');
var typescript = require('gulp-tsc');
var less = require('gulp-less');
 
gulp.task('styles', function() {
    return gulp.src('styles/*.less')
        .pipe(less())
        .pipe(gulp.dest('build/styles'));
});
 
gulp.task('typescript', function(){
  gulp.src('src/*.ts')
    .pipe(typescript())
    .pipe(gulp.dest('build/js/'))
});
 
gulp.task('default', ['typescript','styles']);

If you run Gulp now, without passing any parameters to it, it will run both tasks, and create your files. But wouldn’t it be nice to not have to go and run Gulp after each LESS or TypeScript change you ever made? Well, luckily Gulp supports watching files and directories as well. So let’s add a watcher that watches for changes to the TypeScript and LESS files, and automatically transpiles them. This is done using a function called watch() on the gulp object. Just remember that watching things will lock the command window, so I prefer having the watchers in its own task. That way, I can easily run the transpiling manually if I want to, but start the watchers if that suits my needs better at that point.

So let’s add a new task called “watch”. Inside it, use the watch() function to define what files to watch, and what tasks to run when they change. Like this

gulp.task('watch', function() {
    gulp.watch('styles/*.less', ['styles']);
    gulp.watch('src/*.ts', ['tyepscript']);
});

Now, if you run “gulp watch”, you should be greeted by something like this

And that window should now have locked itself for input, and if you go and change any of the LESS or TS files, it will automatically run the defined tasks. And if you want to stop the watching, just press Ctrl+C and confirm the termination by pressing Y and then enter.

So now we have a “build pipeline” that will handle all the transpile needs we have. And even doing it automagically in the background for us. All we need to do is to remember to start the watch task before we start coding. And if you are using VS for you development, there is even a Gulp taskrunner extension that you can install. It will enable starting Gulp tasks based on events in VS. Events like when the project is opened, when it is compiled and so on.

And obviously, you can configure as many tasks, and intricate task set-ups as you feel that you need. You can pretty much create whatever flow you can even think of using Gulp. This is just a very simple starter solution that works well for a small solution…

In the next part we will look at taking the whole thing one step further by adding bundling and minification to the pipeline so that we can optimize what we deliver to the client. We will also have a look at how we can write tests for our TypeScript, and have them run automatically, so that we can make sure we don’t break things.  But this is it for this time!