Using NuGet with MSBuild

Using NuGet with MSBuild Note: You’ll need to configure your project to use the NuGet packages. Please see Configuring MSBuild projects to use NuGet for more information. The nightlies are available on www.myget.org. There are two packages: Microsoft.TypeScript.Compiler: Tools only (tsc.exe, lib.d.ts, etc.) . Microsoft.TypeScript.MSBuild: Tools as above, as well as MSBuild tasks and targets (Microsoft.TypeScript.targets, Microsoft.TypeScript.Default.props, etc.)

Using npm

Using npm npm install -g typescript@next

Using Namespaces

Using Namespaces Namespaces are simply named JavaScript objects in the global namespace. This makes namespaces a very simple construct to use. They can span multiple files, and can be concatenated using --outFile. Namespaces can be a good way to structure your code in a Web Application, with all dependencies included as <script> tags in your HTML page. Just like all global namespace pollution, it can be hard to identify component dependencies, especially in a large application.

Using Modules

Using Modules Just like namespaces, modules can contain both code and declarations. The main difference is that modules declare their dependencies. Modules also have a dependency on a module loader (such as CommonJs/Require.js). For a small JS application this might not be optimal, but for larger applications, the cost comes with long term modularity and maintainability benefits. Modules provide for better code reuse, stronger isolation and better tooling support for bundling. It is also worth

Using Class Types in Generics

Using Class Types in Generics When creating factories in TypeScript using generics, it is necessary to refer to class types by their constructor functions. For example, function create<T>(c: {new(): T; }): T { return new c(); } A more advanced example uses the prototype property to infer and constrain relationships between the constructor function and the instance side of class types. class BeeKeeper { hasMask: boolean; } class ZooKeeper { nametag: string; } class Animal { numL

Using a class as an interface

Using a class as an interface As we said in the previous section, a class declaration creates two things: a type representing instances of the class and a constructor function. Because classes create types, you can use them in the same places you would be able to use interfaces. class Point { x: number; y: number; } interface Point3d extends Point { z: number; } let point3d: Point3d = {x: 1, y: 2, z: 3};

Using --noResolve

Using --noResolve Normally the compiler will attempt to resolve all module imports before it starts the compilation process. Every time it successfully resolves an import to a file, the file is added to the set of files the compiler will process later on. The --noResolve compiler options instructs the compiler not to “add” any files to the compilation that were not passed on the command line. It will still try to resolve the module to files, but if the file as not specified, it will not be inc

User-Defined Type Guards

User-Defined Type Guards Notice that we had to use type assertions several times. It would be much better if once we performed the check, we could know the type of pet within each branch. It just so happens that TypeScript has something called a type guard. A type guard is some expression that performs a runtime check that guarantees the type in some scope. To define a type guard, we simply need to define a function whose return type is a type predicate: function isFish(pet: Fish | Bird): pet i

Use Union Types

Use Union Types Don’t write overloads that differ by type in only one argument position: /* WRONG */ interface Moment { utcOffset(): number; utcOffset(b: number): Moment; utcOffset(b: string): Moment; } Do use union types whenver possible: /* OK */ interface Moment { utcOffset(): number; utcOffset(b: number|string): Moment; } Note that we didn’t make b optional here because the return types of the signatures differ. Why: This is important for people who are “passing through” a value

Use Optional Parameters

Use Optional Parameters Don’t write several overloads that differ only in trailing parameters: /* WRONG */ interface Moment { diff(b: MomentComparable): number; diff(b: MomentComparable, unitOfTime: string): number; diff(b: MomentComparable, unitOfTime: string, round: boolean): number; } Do use optional parameters whenever possible: /* OK */ interface Moment { diff(b: MomentComparable, unitOfTime?: string, round?: boolean): number; } Note that this collapsing should only occur when al