Below is some of the features:

• React
• React Router 4
• React Hot Loader 3
• Redux
• Redux Saga
• Redux Form
• Webpack 3
• Hapi.js
• Universal / Isomorphic / Server-sider Rendering

Please star my JavaScript version of React Server-side rendering boilerplate/example and my TypeScript version of React Server-side rendering boilerplate/example

—-

I’ve been playing with TypeScript off and on since 2012 (version 0.8) and using ES6 modules seems to be the perfect way to do TypeScript/JavaScript.

In this post I will give you a quick overview how to setup your TypeScript project(s) to work with ES6 Modules. I suggest taking a look at my current TypeScript ES6 Modules Boilerplate after looking at the examples below.

I have two different setups:

1. Using TypeScript to develop your website/application
2. Using TypeScript to create a JavaScript library that others can use without TypeScript

TypeScript ES6 Modules Project Setup

TypeScript ES6 Module Sample Class

import AnotherClass from './AnotherClass';

class ExampleClass extends AnotherClass {

    public exampleProperty:string = null;

    constructor() {
        super();
    }

    public exampleMethod():void {
    }

}

export default ExampleClass;

Gruntfile for compiling your TypeScript ES6 Module Code

module.exports = function(grunt) {

    // Intelligently lazy-loads tasks and plugins as needed at runtime.
    require('jit-grunt')(grunt)();

    // -- Configuration --------------------------------------------------------
    grunt.initConfig({

        browserify: {
            buildTypeScript: {
                options: {
                    preBundleCB: function(bundle) {
                        bundle.plugin('tsify', {
                            removeComments: true,
                            noImplicitAny: false,
                            target: 'ES5'
                        });
                    },
                    // sourcemaps
                    browserifyOptions: {
                        debug: true
                    }
                },
                files: {
                    'web/assets/scripts/main.js': ['src/assets/scripts/main.ts']
                }
            }
        }

    });

    grunt.registerTask('default', [
        'browserify:buildTypeScript'
    ]);

};

NPM package.json for node modules used for the Gruntfile build

{
    "name": "Example",
    "version": "1.0.0",
    "browser": {
        "jquery": "./src/assets/vendor/jquery/dist/jquery.js"
    },
    "browserify-shim": {
        "jquery": "global:$"
    },
    "browserify": {
        "transform": [
            "browserify-shim"
        ]
    },
    "devDependencies": {
        "grunt": "^0.4.5",
        "grunt-browserify": "^4.0.1",
        "browserify-shim": "^3.8.11",
        "tsify": "^0.12.2",
        "jit-grunt": "^0.9.1"
    }
}

TypeScript ES6 Modules Library Setup

I maintain a library of code called StructureJS. I use the TypeScript library to generate the JavaScript one so that I only have one codebase. I suggest using grunt-ts and the umd module setting.

ts: {
    default: {
        src: ['ts/**/*.ts'],
        outDir: 'js/',
        options: {
            target: 'es5',
            module: 'umd',
            basePath: '',
            sourceMap: false,
            declaration: false,
            nolib: false,
            comments: true
        }
    }
}

You can see the actual usage here:
https://github.com/codeBelt/StructureJS/blob/master/Gruntfile.js

Today I want to show you how I think JavaScript Classes should be structured. I’ve written classes many different ways over the years (Prototypal Inheritance, Object Literal Notation, Mootools, Base2js, Sencha Touch, Backbone and TypeScript). The following is a condensed example of the current format I use to structure my classes in JavaScript.

var BaseView = (function () {

    function BaseView() {
    }

    BaseView.prototype.createChildren = function () {
    };

    BaseView.prototype.layoutChildren = function () {
    };

    return BaseView;
})();

You may have seen prototypal inheritance before but in the example above you can see it is wrapped with an extra closure. Sometimes this is referred to as an immediately invoked function expression (iife). The extra iife allows us to have access to the class when we start extending other classes. It is in this example to keep our class structure consistent.

Inheritance

Prototypal or class inheritance is where one class can inherit characteristics from another class. The benefit is you don’t have the same exact code or functionality in several different classes. If there is a bug in your code you don’t have to fix it in 10 different places. You just have to fix it in one class and all classes extending that class will be fixed.

Below is an example of how to extend the class above.

var AnotherView = (function () {

    var _super = Extend(AnotherView, BaseView);

    function AnotherView() {
        _super.call(this);
    }

    AnotherView.prototype.createChildren = function () {
        _super.prototype.createChildren.call(this);
    };

    AnotherView.prototype.layoutChildren = function () {
    };

    return AnotherView;
})();

The format is constant with the the BaseView above but now we have this `_super` thing in our class. What `_super` allows you to do is call the functions/methods on the class you extended.

If you look at Extend in `var _super = Extend(AnotherView, BaseView);` it is a helper function that allows you to extend other classes easily. It will take the first class (AnotherView) and extend it with the second class (BaseView).

Below is the 12 line Extend function/class. Go ahead, put it in your projects to easily extend your classes.

var Extend = function (inheritorClass, baseClass) {
    for (var p in baseClass) {
        if (baseClass.hasOwnProperty(p)) {
            inheritorClass[p] = baseClass[p];
        }
    }
    function __() {
        this.constructor = inheritorClass;
    }
    __.prototype = baseClass.prototype;
    inheritorClass.prototype = new __();
    return baseClass;
};

Real World Example

You may have a view class like below that you always use and repeat the same methods and logic throughout most of your classes. Lets use this class as our base for all of our other view classes. After, scroll down to the next sample class to see how we can extend this class.

var BaseView = (function () {

    function BaseView($element) {
        if (($element instanceof jQuery) === true && $element.length === 0) {
            // If a jQuery object was passed in and it doesn't have any items then exit.
            return;
        }

        this.$element = $element;
        this.isEnabled = false;

        this.init();
    }

    BaseView.prototype.init = function() {
        // Kick off the view lifecycle
        this.createChildren()
            .setupHandlers()
            .enable()
            .layoutChildren();

        return this;
    };

    BaseView.prototype.createChildren = function() {
        // Used to create any objects for thr view and/or find references to child elements.
        return this;
    };

    BaseView.prototype.setupHandlers = function() {
        // Creates a class reference to an event handler method that is bound to the scope of the object.
        return this;
    };

    BaseView.prototype.layoutChildren = function() {
        // Optional use to set any child objects for the view. Also can be called later to update objects.
        return this;
    };

    BaseView.prototype.enable = function() {
        if (this.isEnabled === true) {
            return this;
        }
        this.isEnabled = true;

        // Add event listeners for this class.

        return this;
    };

    BaseView.prototype.disable = function() {
        if (!this.isEnabled === false) {
            return this;
        }
        this.isEnabled = false;

        // Remove event listeners for this class.

        return this;
    };

    BaseView.prototype.destroy = function() {
        this.disable();

        // Nulls out all properties of the class to prevent memory leak.
        for (var key in this) {
            if (this.hasOwnProperty(key)) {
                this[key] = null;
            }
        }
    };

    return BaseView;
})();

In the new class below you will notice we don’t need to set any properties or have any logic that we usually have in all of our view classes. Since we extended BaseView and called super throughout the different methods it will be handle behind the scenes and we can concentrate on what this new class needs to do.

var AnotherView = (function () {

    var _super = Extend(AnotherView, BaseView);

    function AnotherView($element) {
           // Put any properties above super.
            _super.call(this, $element);
            // Put any method calls below super.
    }

    AnotherView.prototype.createChildren = function() {
        _super.prototype.createChildren.call(this);

        return this;
    };

    AnotherView.prototype.setupHandlers = function() {
        _super.prototype.setupHandlers.call(this);

        return this;
    };

    AnotherView.prototype.layoutChildren = function() {
        return this;
    };

    AnotherView.prototype.enable = function() {
        if (this.isEnabled) {
            return this;
        }

        return _super.prototype.enable.call(this);
    };

    AnotherView.prototype.disable = function() {
        if (!this.isEnabled) {
            return this;
        }

       return _super.prototype.disable.call(this);
    };

    AnotherView.prototype.destroy = function() {

       _super.prototype.destroy.call(this);
    };

    return AnotherView;
})();

I did not come up with this structure. This is what the TypeScript compiler spits out. I’ve just clean it up for easier use in native JavaScript projects.

Check out the example files for this article.

Less Typing with Templates and Snippets

Want to speed up your development? Check out my other article Templates/Snippets in your IDE to learn more.

Below is an example of a template I created that will create new classes that extends the BaseView above.

Below you can see the snippets in action. Just hit the Tab key to fill in the next predefined input area.

Creating a Property

Creating a Method

Creating a Class

Sublime Text Snippets

Here are three Sublime Text snippets for you to use:
* Method Helper

* Property Helper

* View Class

1) To create a snippet, go to Tools > New Snippet.

2) A new sample snippet file will be created. Go ahead and replace all of the code with one of the snippets I provided above. Below I have replaced it with the BaseView snippet.

3) Now save the file and name it “view.sublime-snippet”. For Sublime Text snippets the file must end with “.sublime-snippet”.

The snippets files will be saved in: Sublime Text > Preferences > Browse Package > Users

4) Once you have created all three snippets above you can start using them. First, create a new file and save it with the class name you are creating, be sure to give it a “.js” extension. You must have the extension defined so Sublime Text knows what type of snippet to use.

Now start typing “view” and hit the Tab key on your keyboard.

5) You can see it has created a “AnotherView” class that extends “BaseView” with all of the default methods.

JetBrains Templates & Live Templates

With JetBrains you have File Templates & Live Templates. Here are three JetBrains templates for you to use:
* Method Helper

* Property Helper

* View Class

File Templates

1) Lets create a File Template for the View Class template. In PhpStorm/WebStorm you can right click on any folder in your project then select New > Edit File Templates.

2) Now click the green plus button top left and name it JS View. Copy the snippet provided above and paste it in. Click the OK button and you are ready to go.

3) Now you can click New > JS View to create a new view class.

Live Templates

For the Method Helper and Property Helper snippets above we need to do the following.

1) Go to Preferences > Live Templates > JavaScript and click on the plus symbol and select 1. Live Template.

2) Fill in the Abbreviation: with the name you want to type to trigger the snippet. Add the snippet I’ve provided in the Template text: area and then click the Define link.

3) After clicking the Define select JavaScript and click the Apply button.

4) One thing you will want to do is click the Edit variables and order the names like I have below. Also on the Method Helper you will need to set the Expression and check the Skip if defined checkbox.

5) When you want to use the Live Template use Ctrl+J or Cmd+J and start typing the Abbreviation name to insert the snippet.

This template article relates to another article I wrote How To Write JavaScript Classes. Please let me know if you use and like these templates.

Full credit for this article goes to Peter Elst. I took a really old article of his and modified it to talk about TypeScript.

What is OOP

In object-oriented programming, developers often use the term “architecting an application.” This analogy is not far off the mark. You can approach any project as if you are its architect, and use object-oriented principles as building blocks to structure your code. As you develop your application, you can think of your code modules as the blueprints that form the foundation of your applications. Just as you can use one blueprint repeatedly to build similar structures, you can repurpose your code as needed to achieve your desired functionality.

The concept of classes is at the heart of all object-oriented code development. If you’re not already familiar with object-oriented programming (OOP), this article will get you started writing TypeScript classes. Writing classes has never been easier than with TypeScript. If you are new to working with TypeScript, you’ll find that writing classes allows you to create projects that are easier to manage and maintain.

The concepts covered in this article will help you begin writing more portable, reusable code and move beyond the world of procedural code.

What are classes?

Classes are nothing more than a collection of functions (called methods in this context) that provide a blueprint for any number of instances that are created from it. By changing some variables (or in OOP terminology, properties) of a class instance, or by passing different values as arguments to its methods, the same underlying class can have widely different outcomes.

The ability to generate multiple instances (that can appear and behave differently) from the same object is one of the reasons why classes are so powerful. Writing TypeScript classes promotes reusability because the functionality you create can be repurposed.

Let’s see how this looks in code:

class Brick {

    public color: string = 'red';

    constructor() {
        console.log(`new ${this.color} brick created`);
    }
}

export default Brick;

The Brick.ts class code above illustrates one of the most basic implementations of an TypeScript class. The class holds just a single method and property.

To use this class in another TypeScript we will need to import it and instantiate the class.

import Brick from './somepath/Brick';

const firstBrick: Brick = new Brick();

If you run the compiled TypeScript code which is JavaScript, you’ll see that the Console panel now displays “new red brick created” (see Figure 1).

Figure 1. Console panel of Brick class getting instantiated

The console message in the Console panel means that your TypeScript class is functioning correctly. Now it is time to start doing some more advanced things with classes.

Basic OOP concepts: Inheritance vs. composition

There are just a handful of concepts at the core of OOP. This article covers the most important ones: inheritance, encapsulation, and polymorphism. I also discuss a few related topics to help you put these ideas into context.

Without a doubt, inheritance is the most well-known principle of OOP. Inheritance can be defined as the ability to inherit properties and methods and extend the functionality of an existing class in a new one.

If you’re thinking ahead, you might imagine creating a new “Wall” class that extends the “Brick” class you created earlier. However, that is not how inheritance works.

Looking at the relationship between a brick and a wall, the best way to code this is not through inheritance but rather by a concept called composition.

A simple rule of thumb determines whether the relationship between classes is one that warrants inheritance or composition. If you can say class A “is a” class B, you’re dealing with inheritance. If you can say class A “has a” class B, the relationship is one of composition.

Here are some examples of inheritance:

• Cat “is an” animal
• Engineer “is an” employee
• Rugby “is a” sport

Here are examples of composition:

• Wall “has a” brick
• Computer “has a” keyboard
• School “has a” teacher

So what is the difference in how inheritance and composition are implemented? Let’s compare how this works, starting with inheritance:

class Animal {

    public furry: boolean;
    public domestic: boolean;

    constructor() {
        console.log('new animal created');
    }

}

export default Animal;

The Animal.ts class code above is the base Animal class, which you will now extend using inheritance with a Cat class:

import Animal from './somepath/Animal';

class Cat extends Animal {

    public family: string;

    constructor() {
        super();

        this.furry = true;
        this.domestic = true;
        this.family = 'feline';
    }
}

export default Cat;

If you look at the Cat.ts class, the constructor assigns values to three different properties. On close inspection, only one of these properties (family) is defined in the Cat class. The other properties (furry and domestic) come from the Animal base class.

While this not exactly the most practical example, you can see how class inheritance allows you to build upon existing functionality to create a new blueprint for you to start using as you develop your project.

Now if you wanted to create half a dozen cats, you could simply do this by instantiating the Cat class, which has all the properties already set up, rather than using the generic Animal class and having to define the properties again and again for each instance.

Currently in TypeScript there is no override keyword to override a method defined in the class that you extended. You just create a new method with the same name to override the one in the class you extended.

On the other hand, composition doesn’t have any formal syntax like the extends keyword. Composition simply instantiates its own instance of any class it wants to use.

Let’s take the Brick class created earlier. In this next example you’ll create a Wall class that uses composition to instantiate instances of the Brick class:

import Brick from './somepath/Brick';

export class Wall {

    public wallWidth: number = 0;
    public wallHeight: number = 0;

    constructor(w: number, h: number) {
        this.wallWidth = w;
        this.wallHeight = h;
        this.build();
    }

    public build(): void {
        for (var i: number = 0; i < this.wallHeight; i++) {
            for (var j: number = 0; j < this.wallWidth; j++) {
                var brick: Brick = new Brick();
            }
        }
    }
}

export default Wall;

In the code above, the Wall.ts class accepts two arguments passed to its constructor, defining the width and height in bricks of the wall you want to create.

Let’s do a quick test of this class by instantiating it:

import Wall from './somepath/Wall';

const myWall: Wall = new Wall(4, 4);

If you run the compiled TypeScript code which is JavaScript, you’ll see that 16 Brick instances are created with corresponding trace statements displayed in the Output panel to create a 4 x 4 wall (see Figure 2).

Output panel of Wall class getting executed Figure 2. Output panel of Wall class getting executed Apart from the difference in class relationship between inheritance and composition (as I discussed earlier), composition has the advantage of being able to add functionality to another class at runtime. It allows you to have control over the creation and destruction of class instances, whereas with inheritance the relationship between the classes is fixed and defined at the time the code is compiled.

Encapsulation

Now let’s move on to another important principle of OOP called encapsulation. The underlying concept of encapsulation deals with what methods and properties your class exposes to the outside world.

Up until this point you’ve always set methods and properties as public, but is that really what you’d want to do?

If you want your code to be stable, and if you want to develop projects that are least prone to bug and errors, you’ll want to restrict the ways in which other classes can interact with your code.

The key here is to only have those methods and properties available that are required as settings for the class, and restrict access to the rest. Using this approach, you’ll have a limited number of places in your code to debug when something goes wrong in the interaction with your class.

TypeScript includes the following keywords as access modifiers to methods and properties:

public

allows access from anywhere

private

can only be accessed within its own class

The keyword below is current not in TypeScript but I do hope it is added soon:

protected

can only be accessed within own class and subclasses

Let’s put this concept into practice. Take a look at the following example:

export class Person {

    private _age: number = 1;

    constructor() {

    }

    public get age(): number {
        return this._age;
    }

    public set age(val: number) {
        if (this._age > 0) {
            this._age = val;
        }
    }

}

export default Person;

Note: TypeScript supports getter and setter methods but some older browsers do not support the compiled JavaScript code. To learn more check out my TypeScript Getters Setters with TypeScript Accessor Tutorial.

The code example above shows a Person.ts class with a private property _age of a Number type. Even though you want to allow the age of the person to be set, you still opted not to use a public property here. Instead you are routing the age value through the use of a getter/setter method.

Getter/setter methods (as implemented in the previous example) appear as if they are properties, but they behave like methods.

When you set the age property, it calls the age setter method that assigns the value to the private _age property after validating it. In this case, you know that a person’s age can’t be a negative value.

The major advantage of this approach is that every time the age property is set, validation occurs because the age value is always routed through the setter function.

Polymorphism

The final concept I cover in this article is polymorphism. The concept behind polymorphism is based on the idea of different classes implementing the same method names.

Even though this is a very simple concept, polymorphism has some interesting implications. The first major advantage is that it allows classes to be interchangeable at runtime. There are no hard-coded references to specific method names for specific classes.

For example, imagine you have a Teacher class and a Student class. You could implement a teach method for the teacher and a study method for the student, but polymorphism allows you to write the code so that the two classes both implement a work method. Although a Teacher and Student class will clearly have a different implementation of a work method (one teaches, the other studies), you can use a shared generic method name, creating a single interface through which they can be accessed:

class Teacher {

    public work(): void {
        console.log('I am teaching');
    }

}

export default Teacher;

class Student {

    public work(): void {
        console.log('I am studying');
    }

}

export default Student;

Any class that gets passed an instance of either the Teacher.ts or Student.ts class does not need to do any type checking to determine whether it is dealing with a teacher or a student instance (or any other class implementing the same methods for that matter) but it can directly call the work method.

You can enforce polymorphism between classes through the use of something called interfaces. These are similar to classes in that they define a set of methods, but interfaces are different than classes because they do not have an implementation. Interfaces simply define a “contract” of the methods a class needs to implement in order to be valid.

Here’s an example of an interface called IWork:

interface IWork {
    work(): void;
}

export default IWork;

As you can see from the IWork.ts code above, an interface looks suspiciously like any other class. But there are a few differences. Most developers choose to name an interface name so that it begins with a capital I (a common naming convention for interfaces, although it is optional). Also, instead of a class keyword, interfaces use the interface keyword. Additionally, as you analyze the code, you’ll see that in the section where you would expect to see some code for the work method, only its method signature is defined.

The interface above requires that any class that implements it must have a method called work that has a return type of void.

Let’s see how the Teacher and Student class implement this interface:

import IWork from './somepath/IWork';

class Teacher implements IWork {

    public tenure: boolean;

    constructor() {
        this.tenure = true;
    }

    public work(): void {
        console.log("I am teaching");
    }

}

export default Teacher;

import IWork from './somepath/IWork';

class Student implements IWork {

    public averageGrade: number;

    constructor() {
        this.averageGrade = 4.07;
    }

    public work(): void {
        console.log('I am studying');
    }

}

export default Student;

That was easy. By simply adding the implements keyword, you now have set up both the Teacher.ts and Student.ts classes so that they are required to implement the work method. If you try removing or renaming the work method from either of the two classes, you’ll receive a compile-time error message.

By having classes all implement a common interface, the interface can actually be used as a data type. Let’s look at the following example:

import IWork from './somepath/IWork';

class Supervisor {

    constructor(worker: IWork) {
        worker.work();
    }

}

export default Supervisor;

In the example above, you have a Supervisor.ts class that can be passed an instance of a class implementing the IWork interface. In this way, the interface is being used as a data type.

The TypeScript compiler knows that any class instance implementing this IWork interface will have the work method defined. Therefore, it doesn’t complain about a possibly undefined method when the code is compiled.

import Supervisor from './somepath/Supervisor';
import Teacher from './somepath/Teacher';
import Student from './somepath/Student';

const supervisor1: Supervisor = new Supervisor(new Teacher());
const supervisor2: Supervisor = new Supervisor(new Student());

If you run the compiled TypeScript code which is JavaScript, you’ll see two lines appear in the Output panel. The first line displays “I’m teaching” and the second displays “I’m studying” (see Figure 3). These console.log statements are, of course, exactly what you’d expect by passing a new teacher and student instance to the Supervisor constructor.

Figure 3. Output panel of the Supervisor class using polymorphism

Type casting

That brings up the next question: What happens when you try to access class-specific methods or properties of Teacher or Student (other than the work method) that weren’t defined in the interface?

The Supervisor class uses the IWork data type for any instance that is passed to its constructor so if you were to call any other method, the compiler has no way of knowing whether that is implemented. The compiler will report an error.

You can work around this is by using something called type casting by converting the instance from this generic IWork data type back to the Teacher or Student instance.

The way this is accomplished is by using the instanceof keyword and the “as” keyword to cast the object:

import Teacher from './somepath/Teacher';
import Student from './somepath/Student';
import IWork from './somepath/IWork';

export class Supervisor {

    constructor(inst: IWork) {
        inst.work();

        if (inst instanceof Teacher) {
            const teacher = inst as Teacher;
            console.log('Has tenure:', teacher.tenure);
        }

        if (inst instanceof Student) {
            const student = inst as Student;
            console.log('Average grade is:', student.averageGrade);
        }
    }

}

export default Supervisor;

In the code above, the instanceof keyword checks whether the worker instance passed to the constructor is of the specific type Teacher or of the type Student.

If it is a teacher instance, you are able to type cast the instance to that specific class by using “as” keyword, so you can access its specific methods and properties. In this case you could, for example, have a Boolean tenure property set in the Teacher class.

The same holds true if we’re dealing with a student instance. If the is keyword confirms that you are working with a student, you can type cast the generic IWork instance to a student instance and access the averageGrade property.

This is a very useful behavior. You can see how using polymorphism in this way benefits your projects when you have a collection of classes that need to accept any number of data types, as long as they implement a common interface. When you need to get into the specific method implementations of the class implementing the interface, type casting makes this possible.

To check out an example of OOP and TypeScript check out an older post of mine Object Oriented Programming with TypeScript Tutorial.

Files for this example can be found at: https://gist.github.com/codeBelt/65a82e76597f2fb6c2af You can use the follow command to compile the example code:

tsc TestApp.ts -out app.js

Original Article written by Peter Elst (source)

In this TypeScript RequireJS tutorial I will show you how to setup AMD classes, setup your config file and how to use RequireJS plugins with TypeScript.

TypeScript AMD Classes

Below is how we setup a AMD class that we can use with RequireJS. The most important part is to have the export statement below the class itself and to equal the class you created.

// Base.ts file
class Base {

    constructor() {
    }

    public createChildren():void {

    }
}

export = Base;

Next we want to import that Base.ts AMD TypeScript class into another class. You can see below how we have an import statement that will bring in our Base class.

// TestApp.ts file
import Base = require("view/Base");

class TestApp extends Base {

    private _title:string = 'TypeScript AMD Boilerplate';

    constructor() {
        super();
    }

    public createChildren():void {

    }

}

export = TestApp;

Once you have your RequireJS config file setup to load jQuery then you can do the following in your classes. Later I will should my config file.

import $ = require("jquery");

RequireJS Plugins TypeScript

Seems like this is an undocumented TypeScript feature. Below is what you need to use RequireJS plugins like the text! plugin or in this example the Handlebars(hbs!) plugin:

/// <amd-dependency path="hbs!templates/topbar/TopNavigationTemplate" />
declare var require:(moduleId:string) => any;
var TopNavigationTemplate:Function = require('hbs!templates/topbar/TopNavigationTemplate');

If you need to add multiple plugins into the file you will need to put all the /// <amd-dependency path=”” /> above the require code like:

/// <amd-dependency path="hbs!templates/topbar/TopNavigationTemplate" />
/// <amd-dependency path="hbs!templates/login/LoginTemplate" />
declare var require:(moduleId:string) => any;
var TopNavigationTemplate:Function = require('hbs!templates/topbar/TopNavigationTemplate');
var LoginTemplate:Function = require('hbs!templates/login/LoginTemplate');

RequireJS Config & Bootstrap Classes

Here is my RequireJS config file(AppConfig.ts):

require.config({

    baseUrl: 'assets/scripts/',

    paths: {
        //main libraries
        jquery: '../vendor/jquery/jquery-1.9.1',

        //shortcut paths
        templates: '../templates',
        data: '../data',

        //require plugins
        text: '../vendor/require/text',
        tpl: '../vendor/require/tpl',
        json: '../vendor/require/json',
        hbs: '../vendor/require-handlebars-plugin/hbs'
    },

    shim: {
        jquery: {
            exports: '$'
        }
    }
});

And here is my main RequireJS file(AppBootstrap.ts) that kicks everything off:

/// <reference path="_declare/require.d.ts" />

///<reference path='AppConfig.ts'/>
///<reference path='TestApp.ts'/>

/**
 * Main entry point for RequireJS
 */
require(
    [
        'TestApp',
        'jquery'
    ],
    (TestApp, $) => {
        'use strict';

        $(document).ready(function () {
            var app = new TestApp();
            app.appendTo('body');
        });
    }
);

RequireJS TypeScript Example Files

Be sure to check out my TypeScript AMD(RequireJS) Example files to see how to setup an TypeScript application with RequireJS.

Final I figured out how to do both TypeScript AMD & CommonJS external modules and TypeScript Internal module classes. Hopefully you can get started right away with my examples below.

TypeScript External Modules Classes

Below is how to setup TypeScript AMD/CommonJS classes so they will output correctly. You can check out my TypeScript AMD(RequireJS) Example files to see how to setup an TypeScript application with RequireJS.

// TestApp.ts file
import Base = require("view/Base");

class TestApp extends Base {

    private _title:string = 'TypeScript AMD Boilerplate';

    constructor() {
        super();
    }

    public createChildren():void {

    }

}

export = TestApp;

Here is the Base.ts class that the TestApp.ts will extend.

// Base.ts file
import $ = require("jquery");

class Base {

    private _parent:JQuery = null;

    constructor() {
    }

    public createChildren():void {

    }

    public appendTo(selector:string):void {
        this._parent = $(selector);
        this.createChildren();
    }

}

export = Base;

TypeScript Internal Modules Classes

Below is how to setup TypeScript Internal classes so they will output correctly. This is the way I like to setup my TypeScript files. You can check out my TypeScript Internal Modules Example files to see how to setup an TypeScript application with regular classes.

///<reference path='_declare/jquery.d.ts'/>

///<reference path='view/Base.ts'/>

module namespace {

    export class TestApp extends Base {

        private _title:string = 'TypeScript Boilerplate';

        constructor() {
            super();
        }

        public createChildren():void {

        }

    }
}

Here is the Base.ts class that the TestApp.ts will extend.

module namespace {

    export class Base {

        private _parent:JQuery = null;

        constructor() {
        }

        public createChildren():void {

        }

        public appendTo(selector:string):void {
            this._parent = $(selector);
            this.createChildren();
        }

    }
}

If you want to learn more about TypeScript Namespace with Internal Modules check out this other post.

Go ahead and leave comments because I know people are trying to figure this out and I think this is the way to do TypeScript Internal and External Modules.

The jQuery eventListener plugin makes it so you don’t need to do this. Basically you can do everything the on and off methods does in jQuery. You’ll just need to pass the class scope as the last argument. Check out the Example 2.

Also check out the EventListenerApp sample code. https://github.com/codeBelt/jquery-eventListener

Example 1 without plugin

var DemoView = function() {
    this.isEnabled = false;

    this.setupHandlers();
    this.enable();
};

DemoView.prototype.setupHandlers = function() {
    // Bind event handlers scope here
    this.onClickHandler = this.onClick.bind(this);
    this.onMouseEnterHandler = this.onMouseEnter.bind(this);
    this.onMouseLeaveHandler = this.onMouseLeave.bind(this);
};

DemoView.prototype.enable = function() {
    if (this.isEnabled === true) return this;
    this.isEnabled = true;

    this.$card.on('click', this.onClickHandler)
    this.$card.on('mouseenter', this.onMouseEnterHandler)
    this.$card.on('mouseleave', this.onMouseLeaveHandler);
};

DemoView.prototype.disable = function() {
    if (this.isEnabled === false) return this;
    this.isEnabled = false;

    this.$card.off('click', this.onClickHandler)
    this.$card.off('mouseenter', this.onMouseEnterHandler)
    this.$card.off('mouseleave', this.onMouseLeaveHandler);
};

DemoView.prototype.onClick = function(event) {};
DemoView.prototype.onMouseEnter = function(event) {};
DemoView.prototype.onMouseLeave = function(event) {};

Example 2 with plugin

var DemoView = function() {
    this.isEnabled = false;

    this.enable();
};

DemoView.prototype.enable = function() {
    if (this.isEnabled === true) return this;
    this.isEnabled = true;

    this.$card.addEventListener('click', this.onClickHandler, this)
    this.$card.addEventListener('mouseenter', this.onMouseEnterHandler, this)
    this.$card.addEventListener('mouseleave', this.onMouseLeaveHandler, this);
};

DemoView.prototype.disable = function() {
    if (this.isEnabled === false) return this;
    this.isEnabled = false;

    this.$card.removeEventListener('click', this.onClickHandler, this)
    this.$card.removeEventListener('mouseenter', this.onMouseEnterHandler, this)
    this.$card.removeEventListener('mouseleave', this.onMouseLeaveHandler, this);
};

DemoView.prototype.onClick = function(event) {};
DemoView.prototype.onMouseEnter = function(event) {};
DemoView.prototype.onMouseLeave = function(event) {};

• TypeScript Cheat Sheet
• The Definitive TypeScript Guide
• TypeScript Handbook
• TypeScript Wiki

Also checkout my TypeScript Tutorials.

Being a former ActionScript developer, TypeScript is the next best thing and I wanted to share my TypeScript workflow. This is not a TypeScript workflow for Visual Studio. My IDE of choice is WebStorm/PhpStorm and they both have great TypeScript support.

Let Something Else Do The Grunt Work

My whole TypeScript workflow is handle by GruntJS and several Grunt plugins. Before we go over the Grunt plugins. I want to talk about the three Grunt Tasks in My TypeScript Workflow.

Development Task (src folder)

grunt – This task will compile our TypeScript files, Handlebar Template files and any JSON files we want converted into JavaScript. It will also create a index.html specifically for our development environment and starts up a node.js server for us to start working with files that are located in the development “src” folder.

Production Task (web folder)

grunt web – This task will do what the above Development Task does plus it will concatenate and minify our CSS & JavaScript files, prepends a comment block in our minified files, copies only the necessary files from the development folder to the production folder, creates a specific index.html file for our production environment and starts up a node.js server for us to start testing files that are located in the development “web” folder.

Documentation Generating Task (docs folder)

grunt doc – This task will create YUIDoc‘s from our code comments in the TypeScript files.

Example Code Files

Checkout my TypeScript Boilerplate example code to get started with the TypeScript Workflow and GruntJS. Make sure to checkout the Gruntfile.js file to see all the tasks.

If you have node.js and gruntjs installed you should only have to type the two following commands when in the root of the downloaded files:

• sudo npm install
• grunt

Grunt Plugins

grunt-env & grunt-preprocess

These two plugins work together to create an index.html file for both our development and production environment. It will take the config.html file and include/exclude section that we have outlined.

grunt-json

This plugin will take your JSON files and convert them into JavaScript files. For example if you had a JSON file that had a list of all countries that was never going to change. You could eliminate that HTTP request by making the file JavaScript and minifing it together with your other JavaScript code. You can read more about this on my Compile JSON files into Javascript Tutorial.

grunt-contrib-handlebars

This plugin will take your Handlebar Templates and Partials and precompile them into JavaScript for a performance boost. If you like to use Underscore Templates you can check out my Precompiling JavaScript Underscore Templates Tutorial.

grunt-typescript

This plugin will take your TypeScript files and compile them into JavaScript. It will also create sourcemaps for the TypeScript files. You can read more about this in my TypeScript Source Maps Example and/or TypeScript Source Maps After Uglify tutorials.

grunt-contrib-clean

This plugin will delete all the files in the production (web) folder so when we do another build for production we know there are no extra files from a previous build that were removed.

grunt-contrib-copy

This plugin will copy specified files from the development folder into the production folder so we don’t have to add files manually every time we do a build to production.

grunt-usemin

This plugin has two parts to it and maybe confusing at first. It also requires the grunt-contrib-concat, grunt-contrib-uglify & grunt-contrib-cssmin plugins. The two parts are:

useminPrepare

The useminPrepare part of the usemin plugin looks at the html file and checks for a build:js or build:css code block. It will take those files found in the code block(s) and concat them together and then runs uglify for js and/or cssmin for css files. useminPrepare requires grunt-contrib-uglify, grunt-contrib-concat, and grunt-contrib-cssmin plugins to be installed. Which is listed in the package.json file.

usemin

The usemin part will remove the code block(s) and replace that area with the single file path in the html file.

grunt-banner

This plugin allows you to prepend or append comments to files. I prepend the version number and date to my minified files whenever I do a production build.

grunt-manifest

The plugin allow you to create a Application Cache Manifest file from select folders and file types. This is only needed if you are making an application that needs to work offline.

grunt-express & grunt-open

These two plugins will creates a node.js Express Server to test our code in a server like environment and will open the index.html file in our default browsers.

grunt-contrib-watch

This plugin allows you to watch certain files and if they change it will kick off other tasks. In this TypeScript Workflow I watch the TypeScript and Handlebar files and have them re-compile every time I save my edits.

grunt-contrib-yuidoc

This plugin will generate YUIDoc’s from the yuidoc comments in your code files.

The Gruntfile.js File

module.exports = function(grunt) {

    // Load Grunt tasks declared in the package.json file.
    require('matchdep').filterDev('grunt-*').forEach(grunt.loadNpmTasks);

    // Project configuration.
    grunt.initConfig({

        /**
         * This will load in our package.json file so we can have access
         * to the project name and appVersion number.
         */
        pkg: grunt.file.readJSON('package.json'),

        /**
         * Constants for the Gruntfile so we can easily change the path for our environments.
         */
        BASE_PATH: '',
        DEVELOPMENT_PATH: 'src/',
        PRODUCTION_PATH: 'web/',

        /**
         * A code block that will be added to our minified code files.
         * Gets the name and appVersion and other info from the above loaded 'package.json' file.
         * @example <%= banner.join("\\n") %>
         */
        banner: [
                 '/*',
                 '* Project: <%= pkg.name %>',
                 '* Version: <%= pkg.appVersion %> (<%= grunt.template.today("yyyy-mm-dd") %>)',
                 '* Development By: <%= pkg.developedBy %>',
                 '* Copyright(c): <%= grunt.template.today("yyyy") %>',
                 '*/'
        ],

        /**
         * The different constant names that will be use to build our html files.
         * @example <!-- @if NODE_ENV == 'DEVELOPMENT' -->
         */
        env: {
            src: {
                NODE_ENV : 'DEVELOPMENT'
            },
            web : {
                NODE_ENV : 'PRODUCTION'
            }
        },

        /**
         * Allows us to pass in variables to files that have place holders so we can similar files with different data.
         * This plugin works with the 'env' plugin above.
         * @example <!-- @echo appVersion --> or <!-- @echo filePath -->
         */
        preprocess : {
            // Task to create the index.html file that will be used during development.
            // Passes the app version and creates the /index.html
            src : {
                src : '<%= DEVELOPMENT_PATH %>' + 'config.html',
                dest : '<%= DEVELOPMENT_PATH %>' + 'index.html',
                options : {
                    context : {
                        appVersion : '<%= pkg.appVersion %>',
                        filePath: ''
                    }
                }
            },
            // Task to create the index.html file that will be used in production.
            // Passes the app version and creates the /index.html
            web : {
                src : '<%= DEVELOPMENT_PATH %>' + 'config.html',
                dest : '<%= PRODUCTION_PATH %>' + 'index.html',
                options : {
                    context : {
                        appVersion : '<%= pkg.appVersion %>',
                        filePath: ''
                    }
                }
            }
        },

        /**
         * Cleans or deletes our production folder before we create a new production build.
         */
        clean: {
            dist: ['<%= PRODUCTION_PATH %>']
        },

        /**
         * Copies certain files over from the development folder to the production folder so we don't have to do it manually.
         */
        copy: {
            web:  {
                files: [
                    // Copy favicon.ico file from development to production
                    { expand: true, cwd: '<%= DEVELOPMENT_PATH %>', src: 'favicon.ico', dest: '<%= PRODUCTION_PATH %>' },
                    // Copy the media folder from development to production
                    { expand: true, cwd: '<%= DEVELOPMENT_PATH %>', src: ['assets/media/**'], dest: '<%= PRODUCTION_PATH %>' },
                    // Copy the index.html file from development to production
                    { expand: true, cwd: '<%= DEVELOPMENT_PATH %>', dest: '<%= PRODUCTION_PATH %>', src: ['index.html'], filter: 'isFile', dot: true }
                ]
            }
        },

        /**
         * Prepends the banner above to the minified files.
         */
        usebanner: {
            dist: {
                options: {
                    position: 'top',
                    banner: '<%= banner.join("\\n") %>',
                    linebreak: true
                },
                files: {
                    src: [
                        '<%= PRODUCTION_PATH %>' + 'assets/scripts/app.min.js',
                        '<%= PRODUCTION_PATH %>' + 'assets/styles/app.min.css'
                    ]
                }
            }
        },

        /**
         * Turns any JSON files into JavaScript files.
         */
        json: {
            web: {
                options: {
                    namespace: 'JSON_DATA',
                    includePath: false,
                    processName: function(filename) {
                        return filename.toLowerCase();
                    }
                },
                src: ['<%= DEVELOPMENT_PATH %>' + 'assets/data/**/*.json'],
                dest:  '<%= DEVELOPMENT_PATH %>' + 'assets/scripts/compiled/json.js'
            }
        },

        /**
         * Compiles the Handlebars templates into Javascript.
         * http://handlebarsjs.com/
         */
        handlebars: {
            compile: {
                options: {
                    namespace: 'JST',
                    // Registers all files that start with '_' as a partial.
                    partialRegex: /^_/,
                    // Shortens the file path for the templates.
                    processName: function(filename) {
                        return filename.slice(filename.indexOf("template"), filename.length);
                    },
                    // Shortens the file path for the partials.
                    processPartialName: function(filePath) {
                        return filePath.slice(filePath.indexOf("template"), filePath.length);
                    }
                },
                files: {
                    '<%= DEVELOPMENT_PATH %>assets/scripts/compiled/templates.tmpl.js': ['<%= DEVELOPMENT_PATH %>' + 'assets/templates/**/*.hbs']
                }
            }
        },

        /**
         * Compiles the TypeScript files into one JavaScript file.
         */
        typescript: {
            main: {
                src: ['<%= DEVELOPMENT_PATH %>' + 'assets/scripts/TestApp.ts'],
                dest: '<%= DEVELOPMENT_PATH %>' + 'assets/scripts/compiled/app.js',
                options: {
                    target: 'es3', //or es5
                    base_path: '',
                    sourcemap: true,
                    declaration: false,
                    nolib: false,
                    comments: false
                }
            }
        },

        /**
         * The useminPrepare part of the usemin plugin looks at the html file and checks for a build:js or build:css code block.
         * It will take those files found in the code block(s) and concat them together and then runs uglify for js and/or cssmin for css files.
         * useminPrepare requires grunt-contrib-uglify, grunt-contrib-concat, and grunt-contrib-cssmin plugins to be installed. Which is listed in the package.json file.
         *
         * The usemin part will remove the code block(s) and replace that area with the single file path in the html file.
         */
        useminPrepare: {
            html: ['<%= DEVELOPMENT_PATH %>' + 'index.html'],
            options: {
                dest: '<%= PRODUCTION_PATH %>'// Moves the single concatenated files to production.
            }
        },
        usemin: {
            html: ['<%= PRODUCTION_PATH %>' + 'index.html'],
            options: {
                dirs: ['<%= PRODUCTION_PATH %>']
            }
        },

        /**
         * Removes all comments from the production index.html file. I can also remove all whitespace if desired.
         */
        htmlmin: {
            dist: {
                options: {
                    removeComments: true,
                    collapseWhitespace: false
                },
                files: {
                    '<%= PRODUCTION_PATH %>index.html': '<%= PRODUCTION_PATH %>' + 'index.html'
                }
            }
        },

        /**
         * Creates a Cache Manifest file.
         */
        manifest: {
            generate: {
                options: {
                    basePath: '<%= PRODUCTION_PATH %>',
                    exclude: [
                        'assets/media/images/moblie-icons/icon-144x144.png',
                        'assets/media/images/moblie-icons/icon-100x100.png',
                        'assets/media/images/moblie-icons/icon-29x29.png',
                        'assets/media/images/moblie-icons/icon-50x50.png',
                        'assets/media/images/moblie-icons/icon-58x58.png',
                        'assets/media/images/moblie-icons/icon-72x72.png'
                    ],
                    preferOnline: false,
                    verbose: true,
                    timestamp: true,
                    master: []
                },
                src: [
                    'assets/data/**/*.json',
                    'assets/media/images/**/*.jpg',
                    'assets/media/images/**/*.png',
                    'assets/scripts/**/*.js',
                    'assets/styles/**/*.css'
                ],
                dest: '<%= PRODUCTION_PATH %>' + 'offline.appcache'
            }
        },

        /**
         * YUIDoc plugin that will generate documentation from our YUI comments.
         */
        yuidoc: {
            compile: {
                name: '<%= pkg.name %>',
                description: '<%= pkg.description %>',
                version: '<%= pkg.appVersion %>',
                url: '<%= pkg.homepage %>',
                options: {
                    paths: '<%= DEVELOPMENT_PATH %>' + 'assets/scripts/',
                    outdir: '<%= BASE_PATH %>docs',
                    themedir: '',
                    extension: '.ts',                                   // Default '.js' <comma-separated list of file extensions>
                    exclude: ''
                }
            }
        },

        /**
         * Creates a node.js Express Server to test our code in a server like environment.
         * Note: We are using the watch task to keep the server running.
         */
        express: {
            src: {
                options: {
                    port: 8000,
                    hostname: "0.0.0.0",
                    bases: ['<%= DEVELOPMENT_PATH %>'],
                    livereload: true
                }
            },
            web: {
                options: {
                    port: 8001,
                    hostname: "0.0.0.1",
                    bases: ['<%= PRODUCTION_PATH %>'],
                    livereload: true
                }
            }
        },

        /**
         * Opens the index.html file in the default browser after the node.js Express Server is running.
         */
        open: {
            src: {
                // Gets the port from the connect configuration
                path: ' express.src.options.port%>'
            },
            web: {
                // Gets the port from the connect configuration
                path: ' express.web.options.port%>'
            }
        },

        /**
         * Watches files and will run task(s) when files are changed. It will also reload/refresh the browser.
         */
        watch: {
            css: {
                options: {
                    livereload: true
                },
                files: [
                    '<%= DEVELOPMENT_PATH %>' + 'assets/styles/**/*.css',
                ]
            },
            src: {
                options: {
                    livereload: true
                },
                files: [
                    '<%= DEVELOPMENT_PATH %>' + 'assets/scripts/**/*.ts',
                    '<%= DEVELOPMENT_PATH %>' + 'config.html',
                    '<%= DEVELOPMENT_PATH %>' + 'assets/templates/**/*.hbs'
                ],
                tasks: ['src']
            }
        }

    });

    /**
     * Grunt tasks:
     *
     * grunt        (Will build and run your development code/server)
     * grunt web    (Will build and run your production code/server)
     * grunt doc    (Will generate the YUI documentation from the code comments)
     */
    grunt.registerTask('default', [
        'server'
    ]);

    grunt.registerTask('server', [
        'src',
        'express:src',
        'open:src',
        'watch'
    ]);

    grunt.registerTask('src', [
        'env:src',
        'preprocess:src',
        'json',
        'handlebars',
        'typescript'
    ]);

    grunt.registerTask('web', [
        'env:web',
        'preprocess',
        'json',
        'handlebars',
        'typescript',
        'clean',
        'copy',
        'useminPrepare', 'concat', 'uglify', 'cssmin',
        'usemin',
        'usebanner',
        'htmlmin',
        'manifest',
        'open:web',
        'express:web',
        'express-keepalive'
    ]);

    grunt.registerTask('doc', [
        'yuidoc'
    ]);

};

I am going to take my first TypeScript Source Maps Example a step future. I am going to take our compiled TypeScript code and then use UglifyJS to minify it. UglifyJS will also create a new source map for the minified version of the code.

I am going to assume you have read my first TypeScript Source Maps Example and know how to use GruntJS to compile TypeScript classes.

Here is part of my Gruntfile that does all the work for us:

grunt.initConfig({

    pkg: grunt.file.readJSON('package.json'),

    typescript: {
        base: {
            src: ['../ts/Man.ts'],
            dest: '../js/main.js',
            options: {
                sourcemap: true,
                declaration: false
            }
        }
    },

    uglify: {
        dist: {
            options: {
                // Reference to the source map TypeScript created.
                sourceMapIn: '../js/main.js.map',
                // Creates our new source map after minifying.
                sourceMap: '../js/main.min.map',
                // The root folder where the TypeScript live.
                sourceMapRoot: '../ts/'
            },
            files: {
                '../js/main.min.js': ['../js/main.js']
            }
        }
    }

});

You can download all the TypeScript Source Maps with Uglify example files here and try it out:
https://github.com/codeBelt/Grunt-TypeScript-Source-Map-to-JavaScript-with-Uglify

In the code I created a JavaScript object and tried console logging a property that didn’t exist on it.

var obj:any = {};
console.log( obj.property.anotherProperty );

If you look at the Console tab you will see the error. Also notice that Person.ts:16 is being referenced in the output. Clicking on that file name will take you straight to the TypeScript file.

As you can see Google Chrome maps the TypeScript source file with the error. Awesome!

You can download the TypeScript Source Maps example files here: https://github.com/codeBelt/TypeScript-Source-Maps

Grunt JS To Compile TypeScript Code

I used GruntJS to compile my TypeScript code. If you have never used GruntJS before you probably need to checkout my Install Grunt JS on a Mac Tutorial or Install Grunt JS on Windows Tutorial.

Grunt JS Setup

If you have never used GruntJS before you probably need to checkout my Install Grunt JS on a Mac Tutorial or Install Grunt JS on Windows Tutorial.

Example Code

To follow along with this tutorial you may want to download the files from https://github.com/codeBelt/Example-JSON-to-Javascript and click the “Download Zip” button.

Grunt File

If you take a look at the json config area you will see some options. Those options are:

namespace

The namespace in which the json data will be assigned. (Default: ‘myjson’)

includePath

Includes the full path of the file and the extension. By default only the file name is used as the key value. (Default: false)

processName

This option accepts a function which takes one argument (filename) and returns a string which will be used as the key for the object. The example below stores all json data on the default JSON_DATA namespace in lowercase letters. (Default: null)

module.exports = function(grunt) {

    // Project configuration.
    grunt.initConfig({

        //Read the package.json (optional)
        pkg: grunt.file.readJSON('package.json'),

        // Constants for the Gruntfile so we can easily change the path for
        // our environments.
        BASE_PATH: '../',
        DEVELOPMENT_PATH: '../dev/',
        PRODUCTION_PATH: '../prod/',

        // The JSON to JavaScript plugin.
        json: {
            prod: {
                options: {
                    namespace: 'JSON_DATA',
                    includePath: false,
                    processName: function(filename) {
                        return filename.toLowerCase();
                    }
                },
                src: ['<%= DEVELOPMENT_PATH %>' + '**/*.json'],
                dest: '<%= PRODUCTION_PATH %>' + 'assets/scripts/json.js'
            }
        }

    });

    // Loads the necessary tasks for this Grunt file.
    grunt.loadNpmTasks('grunt-json');

    // Grunt tasks.
    grunt.registerTask('default', ['json']);

};

Checkout the grunt-json plugin to learn more about the plugin.

JSON File

The grunt-json plugin will take the following JSON data convert it into a JavaScript Object like in the next example.

{
    "name": "Product",
    "properties": {
        "id": {
            "type": "number",
            "description": "Product identifier",
            "required": true
        },
        "name": {
            "description": "Name of the product",
            "type": "string",
            "required": true
        },
        "price": {
            "type": "number",
            "minimum": 0,
            "required": true
        },
        "tags": {
            "type": "array",
            "items": {
                "type": "string"
            }
        }
    }
}

JSON Converted to JavaScript

Below is what the JavaScript file will look like.

var JSON_DATA = JSON_DATA || {};
JSON_DATA["products"] = {
    "name": "Product",
    "properties": {
        "id": {
            "type": "number",
            "description": "Product identifier",
            "required": true
        },
        "name": {
            "description": "Name of the product",
            "type": "string",
            "required": true
        },
        "price": {
            "type": "number",
            "minimum": 0,
            "required": true
        },
        "tags": {
            "type": "array",
            "items": {
                "type": "string"
            }
        }
    }
};

Now we can used the data like any other JavaScript Object.

console.log( JSON_DATA.products );

Leave me a comment, I love comments.

In this TypeScript tutorial I will go over how to generate code documents from your TypeScript files. We will be using YUIDoc’s and GruntJS.

Grunt JS Setup

If you have never used GruntJS before you will need to checkout my Install Grunt JS on a Mac Tutorial or Install Grunt JS on Windows Tutorial.

Example Code

To follow along with this tutorial you may want to download the files from https://github.com/codeBelt/Example-TypeScript-Generate-Documentation and click the “Download Zip” button.

Package File

Lets look how I setup the package.json file in the _build folder. This file will install Grunt and Grunt plugins locally for our project. All we have to do to install grunt and the YUIDoc plugin is type npm install in Terminal or the Command Prompt when inside the _build folder.

{
    "name": "TypeScript-Generate-Documentation",
    "version": "0.1.0",
    "description": "Create documentation from TypeScript files",
    "url": "https://codebelt.github.io/blog",/
    "developedBy": "codeBelt",

    "devDependencies": {
        "grunt": "~0.4.1",
        "grunt-contrib-yuidoc": "*"
    }
}

Grunt File

Below is our Grunt file.You can add more plugins when you need but if you look we have only one ‘yuidoc’. One thing you need to do is set the extension option to ‘.ts’. The plugin will look for all files with the ‘.ts’ extension and generate documentation from those TypeScript files.

module.exports = function(grunt) {

    // Project configuration.
    grunt.initConfig({

        // This will load in our package.json file so we can have access
        // to the project name and version number.
        pkg: grunt.file.readJSON('package.json'),

        // Constants for the Gruntfile so we can easily change the path for
        // our environments.
        BASE_PATH: '../',
        DEVELOPMENT_PATH: '../dev/',

        // The YUIDoc plugin to generate documentation for code files.
        yuidoc: {
            compile: {
                name: '<%= pkg.name %>',
                description: '<%= pkg.description %>',
                version: '<%= pkg.version %>',
                url: '<%= pkg.homepage %>',
                options: {
                    extension: '.ts',                               // Default '.js' <comma-separated list of file extensions>
                    paths: '<%= DEVELOPMENT_PATH %>' + 'scripts/',
                    outdir: '<%= BASE_PATH %>' + 'docs/'
                }
            }
        }

    });

    // These plugins provide necessary tasks.
    grunt.loadNpmTasks('grunt-contrib-yuidoc');

    // Default task.
    grunt.registerTask('default', ['yuidoc']);

};

Once you have your package.json and Gruntfile.js setup you can navigate with Terminal or the Command Prompt to the _build folder and type the command below to generate the TypeScript documentation:

grunt

If you want to get a good overview of YUIDoc check out Documenting JavaScript with YUIDoc. You can also checkout the office YUIDoc Syntax Reference.

One thing I wanted to point out. You will see the tag below in the DisplayObject class. The @overridden is not a valid YUIDoc tag but I use it so I know what properties or methods Inherited the same comment blocks from other extended classes.

@overridden EventDispatcher.CLASS_NAME

Here is the DisplayObject class example with YUIDoc comments. You can download the files above and checkout the other classes with YUIDoc comments.

///<reference path='../events/EventDispatcher.ts'/>

/**
 * The {{#crossLink "DisplayObject"}}{{/crossLink}} class is the base class for all objects that can be placed on the display list.
 *
 * @class DisplayObject
 * @extends EventDispatcher
 * @constructor
 **/
class DisplayObject extends EventDispatcher
{
    /**
     * @overridden EventDispatcher.CLASS_NAME
     */
    public CLASS_NAME:string = 'DisplayObject';

    /**
     * The isEnabled property is used to keep track of the enabled start of the DisplayObject.
     *
     * @property isEnabled
     * @type {boolean}
     * @default false
     * @protected
     */
    public isEnabled:boolean = false;

    /**
     * The isCreated property is used to keep track if it is the first time this DisplayObject is created.
     *
     * @property isCreated
     * @type {boolean}
     * @default false
     * @protected
     */
    public isCreated:boolean = false;

    /**
     * Returns the number of children of this object.
     *
     * @property numChildren
     * @type {init}
     * @default 0
     * @readonly
     */
    public numChildren:number = 0;

    /**
     * A reference to the child DisplayObject instances to this parent object instance.
     *
     * @property children
     * @type {array}
     * @readonly
     */
    public children:DisplayObject[] = [];

    constructor()
    {
        super();
    }

    /**
     * The createChildren function is intended to provide a consistent place for the creation and adding
     * of children to the view. It will automatically be called the first time that the view is added
     * to another DisplayObject. It is critical that all subclasses call the super for this function in
     * their overridden methods.
     *
     * @method createChildren
     * @override
     * @public
     */
    public createChildren():void
    {
        // JavaScript Code ...
    }

    /**
     * Adds a child DisplayObject instance to this parent object instance. The child is added to the front (top) of all other
     * children in this parent object instance. (To add a child to a specific index position, use the addChildAt() method.)
     *
     * If you add a child object that already has a different parent, the object is removed from the child
     * list of the other parent object.
     *
     * @method addChild
     * @param child {DisplayObject} The DisplayObject instance to add as a child of this DisplayObjectContainer instance.
     * @returns {DisplayObject} The DisplayObject instance that you pass in the child parameter.
     */
    public addChild(child:DisplayObject):DisplayObject
    {
        // JavaScript Code ...
    }

    /**
     * Removes the specified child object instance from the child list of the parent object instance.
     * The parent property of the removed child is set to null , and the object is garbage collected if no other references
     * to the child exist. The index positions of any objects above the child in the parent object are decreased by 1.
     *
     * @method removeChild
     * @param child {DisplayObject} The DisplayObject instance to remove.
     * @returns {DisplayObject} The DisplayObject instance that you pass in the child parameter.
     * @public
     */
    public removeChild(child:DisplayObject):DisplayObject
    {
        // JavaScript Code ...
    }

    /**
     * Removes all child DisplayObject instances from the child list of the DisplayObjectContainer instance.
     * The parent property of the removed children is set to null , and the objects are garbage collected if
     * no other references to the children exist.
     *
     * @method removeChildren
     * @returns {DisplayObject}
     */
    public removeChildren():DisplayObject
    {
        // JavaScript Code ...
    }

    /**
     * Adds a child DisplayObject instance to this DisplayObjectContainer instance.
     * The child is added at the index position specified. An index of 0 represents the back
     * (bottom) of the display list for this DisplayObjectContainer object.
     *
     * @method addChildAt
     * @param child {DisplayObject} The DisplayObject instance to add as a child of this object instance.
     * @param index {int} The index position to which the child is added. If you specify a currently occupied index position, the child object that exists at that position and all higher positions are moved up one position in the child list.
     * @returns {DisplayObject} The DisplayObject instance that you pass in the child parameter.
     */
    public addChildAt(child:DisplayObject, index:number):DisplayObject
    {
        // JavaScript Code ...
    }

    /**
     * Returns the child display object instance that exists at the specified index.
     *
     * @param index {int} The index position of the child object.
     * @returns {DisplayObject} The child display object at the specified index position.
     */
    public getChildAt(index:number):DisplayObject
    {
        // JavaScript Code ...
    }

    /**
     * The enable method is responsible for enabling all event listeners and enabling children of the view.
     *
     * @method enable
     * @public
     */
    public enable():void
    {
        // JavaScript Code ...
    }

    /**
     * The disable method is responsible for disabling all event listeners and disabling children of the view.
     *
     * @method disable
     * @public
     */
    public disable():void
    {
        // JavaScript Code ...
    }

    /**
     * The layoutComponent method provides a common function to handle updating child objects.
     *
     * @method layoutChildren
     */
    public layoutChildren():void
    {
        // JavaScript Code ...
    }

    /**
     * The purpose of the destroy method is to make an object ready for garbage collection. This
     * should be thought of as a one way function. Once destroy is called no further methods should be
     * called on the object or properties accessed. It is the responsibility of those who implement this
     * function to stop all running Timers, all running Sounds, remove any event
     * listeners and take any other steps necessary to make an object eligible for garbage collection.
     * It is critical that all subclasses call the super for this function in their overridden methods.
     *
     * @method destroy
     */
    public destroy():void
    {
        // JavaScript Code ...
    }

}

Leave me a comment, I love comments.

Here is the template. Notice the ${Name} placeholder. That will place the name of the file you typed in.

///<reference path=''/>
 
/**
 * YUIDoc_comment
 *
 * @class ${NAME}
 * @constructor
 **/
class ${NAME} {
 
    public CLASS_NAME:string = '${NAME}';
 
    constructor() {
    
    }
    
}

To create a new file template in PhpStrom/WebStorm you can right click on any folder in your project and hover over New and click Edit File Templates… .

Now click the green plus button top left and name in TypeScript Class and copy the snippet above and paste it in. Click OK and you are ready to go.

Now you can right click and select New and then new TypeScript Class template you created.

You also can get this and other snippets at https://gist.github.com/codeBelt/8025959

Thanks to the post below I was able to fix the issue.
http://stackoverflow.com/questions/17201854/jquery-definition-screwed-up-with-typescript-0-9

I am not sure why the office TypeScript jQuery sample doesn’t have to right jquery.d.ts definitions but you can get it here:
https://github.com/borisyankov/DefinitelyTyped/blob/master/jquery/jquery.d.ts

grunt-contrib-requirejs
grunt-contrib-cssmin
grunt-contrib-htmlmin
grunt-contrib-copy
grunt-contrib-concat
grunt-env
grunt-preprocess
grunt-contrib-yuidoc
grunt-contrib-watch
grunt-contrib-clean
grunt-banner
grunt-usemin
grunt-manifest
grunt-express
grunt-open

Grunt JS Setup

If you have never used GruntJS before you probably need to checkout my Install Grunt JS on a Mac Tutorial or Install Grunt JS on Windows Tutorial.

Example Code

To follow along with this tutorial you may want to download the files from https://github.com/codeBelt/Single-Page-Application-Workflow-Boilerplate and click the “Download Zip” button.

Environments

We will setup GruntJS to build our development (src/ folder) environment and our production (web/ folder) environments. Our two GruntJS commands will be grunt and grunt web.

We will start with the following:

/
├──  src/
├──  web/
├──  Gruntfile.js
└──  package.json

src folder

The src folder will have all of the source files we need to create a single page JavaScript application.

web folder

The web folder will only contain the minified files and assets needed for the production server.

Gruntfile.js & package.json Files

The GruntJS tasks and plugins need to build our environments.

Development Folder

Lets take a look at our src folder. Notice the src/config.html file. This file will be used to create the index.html file for both our development (src) and production (web) environment.

/
├──+ src/
│  ├── assets/
│  ├── favicon.ico
│  └── config.html
├──  Gruntfile.js
└──  package.json

If where too run both the development (grunt) and production (grunt web) commands it would generate the following:

/
├──+ src/
│  ├── assets/
│  ├── favicon.ico
│  ├── config.html
│  └── index.html
├──+ web/
│  ├── assets/
│  ├── favicon.ico
│  ├── offline.appcache
│  └── index.html
├──  Gruntfile.js
└──  package.json

Here is our config.html in the src folder. Notice the NODE_ENV conditions, they will be used to determine how the production and development html file will be generated.

<!DOCTYPE html>

<!-- @if NODE_ENV == 'DEVELOPMENT' -->
<html lang="en">
<!-- @endif -->

<!-- @if NODE_ENV == 'PRODUCTION' -->
<html lang="en" manifest="offline.appcache">
<!-- @endif -->

<head>
    <!-- The current version of the application -->
    <meta name="version" content="<!-- @echo buildVersion -->"/>

    <!-- Add the fav icon -->
    <link rel="icon" href="/favicon.ico" type="image/x-icon">
    <link rel="shortcut icon" href="/favicon.ico" type="image/x-icon">

    <!-- build:css assets/styles/app.min.css -->
        <link rel="stylesheet" media="screen, projection" href="assets/styles/setup.css" />
        <link rel="stylesheet" media="screen, projection" href="assets/styles/bootstrap.css" />
        <link rel="stylesheet" media="screen, projection" href="assets/styles/screen.css" />
    <!-- endbuild -->

</head>
<body>
    <!-- @if NODE_ENV == 'DEVELOPMENT' -->
        <script src="assets/vendor/require/require.js" data-main="assets/scripts/AppBootstrap.js"></script>
        <script src="assets/scripts/config.js"></script>
    <!-- @endif -->

    <!-- @if NODE_ENV == 'PRODUCTION' -->
        <script src="assets/scripts/require.js" data-main="assets/scripts/app.min.js"></script>
    <!-- @endif -->
    </body>
</html>

Install GruntJS & the necessary plugins

Lets look how I setup the package.json file. This file will install Grunt and Grunt plugins locally for our project. All we have to do to install all of the plugins is type npm install when in root of this project and it will install everything we need.

{
    "name": "Single-Page-Application-GruntJS",
    "version": "0.2.0",

    "appVersion": "0.1.0",
    "description": "A sample single page JavaScript application workflow boilerplate with Grunt.js",
    "url": "https://codebelt.github.io/blog/javascript/single-page-javascript-application-workflow/",
    "developedBy": "codeBelt",

    "devDependencies": {
        "grunt": "0.4.2",
        "matchdep": "0.3.0",

        "grunt-contrib-requirejs": "0.4.1",
        "grunt-contrib-yuidoc": "0.5.0",
        "grunt-contrib-watch": "0.5.3",
        "grunt-contrib-cssmin": "0.7.0",
        "grunt-contrib-htmlmin": "0.1.3",
        "grunt-contrib-concat": "0.3.0",
        "grunt-contrib-uglify": "0.2.7",
        "grunt-contrib-copy": "0.4.1",
        "grunt-contrib-clean": "0.5.0",
        "grunt-banner": "0.2.0",
        "grunt-usemin": "2.0.2",
        "grunt-manifest": "0.4.0",
        "grunt-preprocess": "4.0.0",
        "grunt-env": "0.4.1",
        "grunt-express": "1.2.1",
        "grunt-open": "0.2.2"
    }
}

Take notice of the “version” property. It will be used in the creation of the index.html, minified css, minified JavaScript and the cache manifest files.

Here is the Gruntfile.js file. You can read the comments to see what each plugin is doing.

module.exports = function(grunt) {

    // Load Grunt tasks declared in the package.json file.
    require('matchdep').filterDev('grunt-*').forEach(grunt.loadNpmTasks);

    // Project configuration.
    grunt.initConfig({

        /**
        * This will load in our package.json file so we can have access
        * to the project name and appVersion number.
        */
        pkg: grunt.file.readJSON('package.json'),

        /**
        * Constants for the Gruntfile so we can easily change the path for our environments.
        */
        BASE_PATH: '',
        DEVELOPMENT_PATH: 'src/',
        PRODUCTION_PATH: 'web/',

        /**
        * A code block that will be added to our minified code files.
        * Gets the name and appVersion and other info from the above loaded 'package.json' file.
        * @example <%= banner.join("\\n") %>
        */
        banner: [
            '/*',
            '* Project: <%= pkg.name %>',
            '* Version: <%= pkg.appVersion %> (<%= grunt.template.today("yyyy-mm-dd") %>)',
            '* Development By: <%= pkg.developedBy %>',
            '* Copyright(c): <%= grunt.template.today("yyyy") %>',
            '*/'
        ],

        /**
        * The different constant names that will be use to build our html files.
        * @example <!-- @if NODE_ENV == 'DEVELOPMENT' -->
        */
        env: {
            src: {
                NODE_ENV : 'DEVELOPMENT'
            },
            web : {
                NODE_ENV : 'PRODUCTION'
            }
        },

        /**
        * Allows us to pass in variables to files that have place holders so we can similar files with different data.
        * This plugin works with the 'env' plugin above.
        * @example <!-- @echo appVersion --> or <!-- @echo filePath -->
        */
        preprocess : {
            // Task to create the index.html file that will be used during development.
            // Passes the app version and creates the /index.html
            src : {
                src : '<%= DEVELOPMENT_PATH %>' + 'config.html',
                dest : '<%= DEVELOPMENT_PATH %>' + 'index.html',
                options : {
                    context : {
                        appVersion : '<%= pkg.appVersion %>',
                        filePath: ''
                    }
                }
            },
            // Task to create the index.html file that will be used in production.
            // Passes the app version and creates the /index.html
            web : {
                src : '<%= DEVELOPMENT_PATH %>' + 'config.html',
                dest : '<%= PRODUCTION_PATH %>' + 'index.html',
                options : {
                    context : {
                        appVersion : '<%= pkg.appVersion %>',
                        filePath: ''
                    }
                }
            }
        },

        /**
        * Cleans or deletes our production folder before we create a new production build.
        */
        clean: {
            dist: ['<%= PRODUCTION_PATH %>']
        },

        /**
        * Copies certain files over from the development folder to the production folder so we don't have to do it manually.
        */
        copy: {
            web:  {
                files: [
                    // Copy favicon.ico file from development to production
                    { expand: true, cwd: '<%= DEVELOPMENT_PATH %>', src: 'favicon.ico', dest: '<%= PRODUCTION_PATH %>' },
                    // Copy the media folder from development to production
                    { expand: true, cwd: '<%= DEVELOPMENT_PATH %>', src: ['assets/media/**'], dest: '<%= PRODUCTION_PATH %>' },
                    // Copy the index.html file from development to production
                    { expand: true, cwd: '<%= DEVELOPMENT_PATH %>', dest: '<%= PRODUCTION_PATH %>', src: ['index.html'], filter: 'isFile', dot: true },
                    // Copy require.js file from development to production
                    { expand: true, cwd: '<%= DEVELOPMENT_PATH %>' + 'assets/vendor/require/', src: 'require.js', dest: '<%= PRODUCTION_PATH %>' + 'assets/scripts/' }
                ]
            }
        },

        /**
        * Prepends the banner above to the minified files.
        */
        usebanner: {
            dist: {
                options: {
                    position: 'top',
                    banner: '<%= banner.join("\\n") %>',
                    linebreak: true
                },
                files: {
                    src: [
                        '<%= PRODUCTION_PATH %>' + 'assets/scripts/app.min.js',
                        '<%= PRODUCTION_PATH %>' + 'assets/styles/app.min.css'
                    ]
                }
            }
        },

        /**
        * The useminPrepare part of the usemin plugin looks at the html file and checks for a build:js or build:css code block.
        * It will take those files found in the code block(s) and concat them together and then runs uglify for js and/or cssmin for css files.
        * useminPrepare requires grunt-contrib-uglify, grunt-contrib-concat, and grunt-contrib-cssmin plugins to be installed. Which is listed in the package.json file.
        *
        * The usemin part will remove the code block(s) and replace that area with the single file path in the html file.
        */
        useminPrepare: {
            html: ['<%= DEVELOPMENT_PATH %>' + 'index.html'],
            options: {
                dest: '<%= PRODUCTION_PATH %>'// Moves the single concatenated files to production.
            }
        },
        usemin: {
            html: ['<%= PRODUCTION_PATH %>' + 'index.html'],
            options: {
                dirs: ['<%= PRODUCTION_PATH %>']
            }
        },

        /**
        * The RequireJS plugin that will use uglify2 to build and minify our JavaScript,
        * templates and any other data we include in the require files.
        */
        requirejs: {
            compile: {
                options: {
                    baseUrl: '<%= DEVELOPMENT_PATH %>' + 'assets/scripts/',                         // Path of source scripts, relative to this build file
                    mainConfigFile: '<%= DEVELOPMENT_PATH %>' + 'assets/scripts/config.js',         // Path of shared configuration file, relative to this build file
                    name: 'AppBootstrap',                                                           // Name of input script (.js extension inferred)
                    out: '<%= PRODUCTION_PATH %>' + 'assets/scripts/app.min.js',                    // Path of built script output

                    fileExclusionRegExp: /.svn/,                                                    // Ignore all files matching this pattern
                    useStrict: true,
                    preserveLicenseComments: false,
                    pragmas: {
                        debugExclude: true
                    },

                    optimize: 'uglify2',                                                            // Use 'none' If you do not want to uglify.
                    uglify2: {
                        output: {
                            beautify: false,
                            comments: false
                        },
                        compress: {
                            sequences: false,
                            global_defs: {
                                DEBUG: false
                            }
                        },
                        warnings: false,
                        mangle: true
                    }
                }
            }
        },

        /**
        * Removes all comments from the production index.html file. I can also remove all whitespace if desired.
        */
        htmlmin: {
            dist: {
                options: {
                    removeComments: true,
                    collapseWhitespace: false
                },
                files: {
                    '<%= PRODUCTION_PATH %>index.html': '<%= PRODUCTION_PATH %>' + 'index.html'
                }
            }
        },

        /**
        * Creates a Cache Manifest file.
        */
        manifest: {
            generate: {
                options: {
                    basePath: '<%= PRODUCTION_PATH %>',
                    exclude: [
                        'assets/media/images/moblie-icons/icon-144x144.png',
                        'assets/media/images/moblie-icons/icon-100x100.png',
                        'assets/media/images/moblie-icons/icon-29x29.png',
                        'assets/media/images/moblie-icons/icon-50x50.png',
                        'assets/media/images/moblie-icons/icon-58x58.png',
                        'assets/media/images/moblie-icons/icon-72x72.png'
                    ],
                    preferOnline: false,
                    verbose: true,
                    timestamp: true,
                    master: []
                },
                src: [
                    'assets/data/**/*.json',
                    'assets/media/images/**/*.jpg',
                    'assets/media/images/**/*.png',
                    'assets/scripts/**/*.js',
                    'assets/styles/**/*.css'
                ],
                dest: '<%= PRODUCTION_PATH %>' + 'offline.appcache'
            }
        },

        /**
        * YUIDoc plugin that will generate documentation from our YUI comments.
        */
        yuidoc: {
            compile: {
                name: '<%= pkg.name %>',
                description: '<%= pkg.description %>',
                version: '<%= pkg.appVersion %>',
                url: '<%= pkg.homepage %>',
                options: {
                    paths: '<%= DEVELOPMENT_PATH %>' + 'assets/scripts/',
                    outdir: '<%= BASE_PATH %>docs',
                    themedir: '',
                    extension: '.js',                                   // Default '.js' <comma-separated list of file extensions>
                    exclude: ''
                }
            }
        },

        /**
        * Creates a node.js Express Server to test our code in a server like environment.
        * Note: We are using the watch task to keep the server running.
        */
        express: {
            src: {
                options: {
                    port: 8000,
                    hostname: "0.0.0.0",
                    bases: ['<%= DEVELOPMENT_PATH %>'],
                    livereload: true
                }
            },
            web: {
                options: {
                    port: 8001,
                    hostname: "0.0.0.1",
                    bases: ['<%= PRODUCTION_PATH %>'],
                    livereload: true
                }
            }
        },

        /**
        * Opens the index.html file in the default browser after the node.js Express Server is running.
        */
        open: {
            src: {
                // Gets the port from the connect configuration
                path: ' express.src.options.port%>'
            },
            web: {
                // Gets the port from the connect configuration
                path: ' express.web.options.port%>'
            }
        },

        /**
        * Watches files and will run task(s) when files are changed. It will also reload/refresh the browser.
        */
        watch: {
            css: {
                options: {
                    livereload: true
                },
                files: [
                    '<%= DEVELOPMENT_PATH %>' + 'assets/styles/**/*.css',
                ]
            },
            src: {
                options: {
                    livereload: true
                },
                files: [
                    '<%= DEVELOPMENT_PATH %>' + 'assets/scripts/**/*.ts',
                    '<%= DEVELOPMENT_PATH %>' + 'config.html',
                    '<%= DEVELOPMENT_PATH %>' + 'assets/templates/**/*.hbs'
                ],
                tasks: ['src']
            }
        }

    });

    /**
    * Grunt tasks:
    *
    * grunt        (Will build and run your development code/server)
    * grunt web    (Will build and run your production code/server)
    * grunt doc    (Will generate the YUI documentation from the code comments)
    */
    grunt.registerTask('default', [
        'server'
    ]);

    grunt.registerTask('server', [
        'src',
        'express:src',
        'open:src',
        'watch'
    ]);

    grunt.registerTask('src', [
        'env:src',
        'preprocess:src'
    ]);

    grunt.registerTask('web', [
        'env:web',
        'preprocess',
        'clean',
        'copy',
        'useminPrepare', 'concat', 'cssmin',
        'usemin',
        'requirejs',
        'usebanner',
        'htmlmin',
        'manifest',
        'open:web',
        'express:web',
        'express-keepalive'
    ]);

    grunt.registerTask('doc', [
        'yuidoc'
    ]);

};

Please let me know if you liked this tutorial.

In this YUIDoc JavaScript Documentation Tutorial I will be using the GruntJS YUIDoc Plugin to generate the JavaScript Docs.

Grunt JS Setup

If you have never used GruntJS before you will need to checkout my Install Grunt JS on a Mac Tutorial or Install Grunt JS on Windows Tutorial.

Now download the example files below and navigate with Terminal or the Command Prompt to the “_build” folder and type in:

npm install

On a Mac you may need to type:

sudo npm install

Basically what “npm install” is doing is looking for a “package.json” file and checks the “devDependencies”. NodeJS will download and install the necessary files for your GruntJS setup. Here is our package file:

{
    "name": "YUI-Docs",
    "version": "0.1.0",
    "description": "This is the description.",
    "url": "http://www.test.com",/
    "devDependencies": {
        "grunt": "~0.4.1",
        "grunt-contrib-yuidoc": "*"
    }
}

Luckily EaselJS uses YUIDoc and I could run a test with JavaScript classes already committed. Below is how the Gruntfile is setup.

// Metadata.
meta: {
    basePath: '../',
    srcPath: '../easeljs/',
    docsPath: '../docs/',
    deployPath: '../deploy/'
},

// Task configuration.
yuidoc: {
    compile: {
        name: '<%= pkg.name %>',
        description: '<%= pkg.description %>',
        version: '<%= pkg.version %>',
        url: '<%= pkg.homepage %>',
        options: {
            paths: '<%= meta.srcPath %>',
            outdir: '<%= meta.docsPath %>',
            themedir: '',
            exclude: ''
        }
    }
}

Now all we have to do is type the command below and it will generate the JavaScript documents for us.

grunt yuidoc

If you want to get a good overview of YUIDoc check out Documenting JavaScript with YUIDoc. Also it seems YUIDoc is not just for JavaScript Documenting before all languages.

Download the examples files to see the outputted docs.

It might be a secret you want to keep like my grandmothers chocolate chip cookie recipe but I want know, I want to learn, please teach me. I can keep a secret and you can email me at code{AT}codebelt.com. I used to work with Andy your Server-Side Savant. Maybe he can vouch for me.

While I am at it can you also create GreenSock LoaderMax JS.