Optional and Default Parameters In TypeScript, every parameter is assumed to be required by the function. This doesn’t mean that it can’t be given null or undefined, but rather, when the function is called the compiler will check that the user has provided a value for each parameter. The compiler also assumes that these parameters are the only parameters that will be passed to the function. In short, the number of arguments given to a function has to match the number of parameters the function

Optional Parameters and Rest Parameters When comparing functions for compatibility, optional and required parameters are interchangeable. Extra optional parameters of the source type are not an error, and optional parameters of the target type without corresponding parameters in the target type are not an error. When a function has a rest parameter, it is treated as if it were an infinite series of optional parameters. This is unsound from a type system perspective, but from a runtime point of

Namespacing As we add more validators, we’re going to want to have some kind of organization scheme so that we can keep track of our types and not worry about name collisions with other objects. Instead of putting lots of different names into the global namespace, let’s wrap up our objects into a namespace. In this example, we’ll move all validator-related entities into a namespace called Validation. Because we want the interfaces and classes here to be visible outside the namespace, we preface

Never The never type represents the type of values that never occur. For instance, never is the return type for a function expression or a arrow function expresssion that always throws an exception or one that never returns; Variables also acquire the type never when narrowed by any type guards that can never be true. The never type is a subtype of, and assignable to, every type; however, no type is a subtype of, or assignable to, never (except never itself). Even any isn’t assignable to never.

NuGet Right-Click -> Manage NuGet Packages Search for Microsoft.TypeScript.MSBuild Hit Install When install is complete, rebuild! More details can be found at Package Manager Dialog and using nightly builds with NuGet

Needless Namespacing If you’re converting a program from namespaces to modules, it can be easy to end up with a file that looks like this: shapes.ts export namespace Shapes { export class Triangle { /* ... */ } export class Square { /* ... */ } } The top-level module here Shapes wraps up Triangle and Square for no reason. This is confusing and annoying for consumers of your module: shapeConsumer.ts import * as shapes from "./shapes"; let t = new shapes.Shapes.Triangle(); // shapes.Sha

Null and Undefined In TypeScript, both undefined and null actually have their own types named undefined and null respectively. Much like void, they’re not extremely useful on their own: // Not much else we can assign to these variables! let u: undefined = undefined; let n: null = null; By default null and undefined are subtypes of all other types. That means you can assign null and undefined to something like number. However, when using the --strictNullChecks flag, null and undefined are only

Multi-file namespaces Here, we’ll split our Validation namespace across many files. Even though the files are separate, they can each contribute to the same namespace and can be consumed as if they were all defined in one place. Because there are dependencies between files, we’ll add reference tags to tell the compiler about the relationships between the files. Our test code is otherwise unchanged. Validation.ts namespace Validation { export interface StringValidator { isAcceptable(s: str

MSBuild Update project file to include locally installed Microsoft.TypeScript.Default.props (at the top) and Microsoft.TypeScript.targets (at the bottom) files: <?xml version="1.0" encoding="utf-8"?> <Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <!-- Include default props at the bottom --> <Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.T

Moving to TypeScript Files At this point, you’re probably ready to start using TypeScript files. The first step is to rename one of your .js files to .ts. If your file uses JSX, you’ll need to rename it to .tsx. Finished with that step? Great! You’ve successfully migrated a file from JavaScript to TypeScript! Of course, that might not feel right. If you open that file in an editor with TypeScript support (or if you run tsc --pretty), you might see red squiggles on certain lines. You should thin