With everything we've seen so far, we can build and deploy large applications. Now, we are going to take a look at the few remaining options that we haven't covered yet. Some are just informative, while others can help you and your team write better TypeScript code. As with most command line utilities, the TypeScript compiler comes with a help parameter that will output all of the compiler's options. To view all of these options, use the –h or --help parameters or simply run the compiler with no parameters at all. There is also a version parameter that outputs the current version of the TypeScript compiler that is installed. This is viewed using either the -v or --version parameters. As you can see from the following screenshot, this book was written immediately following the initial release of TypeScript as a completed language.

Since the language is open source, expect improvements to be made and new versions to be available.

Now that we've covered the options that we'll use very infrequently, let's get back to improving how we develop for the Web. If you are writing a web application, it is possible you could have users all around the world. This means your applications could and probably should support multiple languages. To ensure that each localized character is displayed properly, you may have to specify a code page.

The TypeScript compiler provides the --codepage parameter to allow you to specify the character set that the resulting JavaScript file will contain. By default, the TypeScript compiler will use 65001 when this parameter is not provided. Visual Studio does not allow this option to be specified and UTF-8 should be used in most scenarios.

We talked earlier about JavaScript's strict mode and how it forced certain constructs upon the language that help improve the code we develop. TypeScript has its own version of strict mode that forces us to use types everywhere. If a type is not explicitly provided and the compiler is not able to infer the object's type information, we can use the compiler to warn us. To enforce this constraint, simply provide the --noImplicitAny parameter when compiling your TypeScript files. In the following code segment, you can see that we create a situation where the type variable a is not known. We do not provide it with initial type information and we assign it to multiple object types during execution.

function implicitType() {
    var a;
    a = 2;
    a = "bob";
    alert(a);
}

The final runtime value of a will be "bob"; however, this breaks the type safety that TypeScript aims to provide. In the following screenshot, you can see how to enforce types within your code and the result of attempting to compile the preceding code:

Enforcing types upon our code will not only help us to ensure we write solid code, but it will help anyone attempting to consume it on an API level or understand the intent of the code. Strongly typing our objects helps others know what they are working with. However, you don't want to have to provide all of your TypeScript source files to anyone consuming your code as an API. For this reason, TypeScript has created another language construct that will provide type information to consumers without providing any implementation details. This type information is placed into a declaration file, which can then be distributed along with the combined and minified JavaScript file that can be used at runtime. In the next segment of code, there is a module that is reusable and can be deployed for any JavaScript code to call:

module MyNamespace {
    export interface IClass {
        Id: string;
        DoSomething();
    }
    export class MyClass implements IClass {
        constructor(public Id: string = Date.now().toString()) {
        }
        public DoSomething() {
            alert(this.Id);
        }
    }
}

This module can be consumed by other TypeScript files that are aware where the source file is. However, someone consuming only a JavaScript file will be unable to interact with our objects in a strongly typed fashion. If we provide the declaration file to our consumers though, they can use our objects as if they existed inside of their own code base. To generate the declaration file for a TypeScript file, run the command shown in the following screenshot:

During the compilation process, the type information for our module will be extracted into a new file that will be output alongside the resulting JavaScript file. It will have the format <filename>.d.ts and will be treated by any TypeScript compiler as a collection of type definitions. Attempting to place execution code in a declaration file will result in an error. The file generated from our module is as follows:

declare module MyNamespace {
    interface IClass {
        Id: string;
        DoSomething(): any;
    }
    class MyClass implements IClass {
        public Id: string;
        constructor(Id?: string);
        public DoSomething(): void;
    }
}

As you can see, all of the type information is present but the implementation details have been left out. We will discuss these more in detail later when we start integrating other libraries such as jQuery.

The final compiler option allows us to pass a text file as the parameter to the compiler. This text file can contain the list of parameters for the compiler and all of the files for compilation, allowing us to bypass command line restrictions. This is the work-around to the buffer limit in the command line. In the following screenshot, you can see a text file that has been created to manage our compilation parameters:

As you can see, we are now able to provide all of our parameters in an easily managed list. The following screenshot shows how to use this file with the compiler: