![\"cfa\"](\"https://cloud.githubusercontent.com/assets/8052307/5210657/c5ae0f28-7585-11e4-97d8-86169ef2a160.gif\")
With TypeScript 1.8 it becomes possible for a type parameter constraint to reference type parameters from the same type parameter list.\nPreviously this was an error.\nThis capability is usually referred to as F-Bounded Polymorphism.
\n\ntsfunction assign<T extends U, U>(target: T, source: U): T {\n for (let id in source) {\n target[id] = source[id];\n }\n return target;\n}\n\nlet x = { a: 1, b: 2, c: 3, d: 4 };\nassign(x, { b: 10, d: 20 });\nassign(x, { e: 0 }); // Error
TypeScript 1.8 introduces control flow analysis to help catch common errors that users tend to run into.\nRead on to get more details, and check out these errors in action:
\n
Statements guaranteed to not be executed at run time are now correctly flagged as unreachable code errors.\nFor instance, statements following unconditional return, throw, break or continue statements are considered unreachable.\nUse --allowUnreachableCode to disable unreachable code detection and reporting.
Here’s a simple example of an unreachable code error:
\n\ntsfunction f(x) {\n if (x) {\n return true;\n }\n else {\n return false;\n }\n\n x = 0; // Error: Unreachable code detected.\n}
A more common error that this feature catches is adding a newline after a return statement:
\ntsfunction f() {\n return // Automatic Semicolon Insertion triggered at newline\n {\n x: \"string\" // Error: Unreachable code detected.\n }\n}
Since JavaScript automatically terminates the return statement at the end of the line, the object literal becomes a block.
Unused labels are also flagged.\nJust like unreachable code checks, these are turned on by default;\nuse --allowUnusedLabels to stop reporting these errors.
\ntsloop: while (x > 0) { // Error: Unused label.\n x++;\n}
Functions with code paths that do not return a value in JS implicitly return undefined.\nThese can now be flagged by the compiler as implicit returns.\nThe check is turned off by default; use --noImplicitReturns to turn it on.
\ntsfunction f(x) { // Error: Not all code paths return a value.\n if (x) {\n return false;\n }\n\n // implicitly returns `undefined`\n}
TypeScript can reports errors for fall-through cases in switch statement where the case clause is non-empty.\nThis check is turned off by default, and can be enabled using --noFallthroughCasesInSwitch.
With --noFallthroughCasesInSwitch, this example will trigger an error:
\ntsswitch (x % 2) {\n case 0: // Error: Fallthrough case in switch.\n console.log(\"even\");\n\n case 1:\n console.log(\"odd\");\n break;\n}
However, in the following example, no error will be reported because the fall-through case is empty:
\n\ntsswitch (x % 3) {\n case 0:\n case 1:\n console.log(\"Acceptable\");\n break;\n\n case 2:\n console.log(\"This is *two much*!\");\n break;\n}
TypeScript now supports Function components.\nThese are lightweight components that easily compose other components:
\n\nts// Use parameter destructuring and defaults for easy definition of 'props' type\nconst Greeter = ({name = 'world'}) => <div>Hello, {name}!</div>;\n\n// Properties get validated\nlet example = <Greeter name='TypeScript 1.8' />;
For this feature and simplified props, be sure to be use the latest version of react.d.ts.
\nprops type management in ReactIn TypeScript 1.8 with the latest version of react.d.ts (see above), we’ve also greatly simplified the declaration of props types.
Specifically:
\nref and key or extend React.Propsref and key properties will appear with correct types on all componentsref property is correctly disallowed on instances of Stateless Function componentsUsers can now declare any augmentations that they want to make, or that any other consumers already have made, to an existing module.\nModule augmentations look like plain old ambient module declarations (i.e. the declare module \"foo\" { } syntax), and are directly nested either your own modules, or in another top level ambient external module.
Furthermore, TypeScript also has the notion of global augmentations of the form declare global { }.\nThis allows modules to augment global types such as Array if necessary.
The name of a module augmentation is resolved using the same set of rules as module specifiers in import and export declarations.\nThe declarations in a module augmentation are merged with any existing declarations the same way they would if they were declared in the same file.
Neither module augmentations nor global augmentations can add new items to the top level scope - they can only “patch” existing declarations.
\nHere map.ts can declare that it will internally patch the Observable type from observable.ts and add the map method to it.
\nts// observable.ts\nexport class Observable<T> {\n // ...\n}
\nts// map.ts\nimport { Observable } from \"./observable\";\n\n// Create an augmentation for \"./observable\"\ndeclare module \"./observable\" {\n\n // Augment the 'Observable' class definition with interface merging\n interface Observable<T> {\n map<U>(proj: (el: T) => U): Observable<U>;\n }\n\n}\n\nObservable.prototype.map = /*...*/;
\nts// consumer.ts\nimport { Observable } from \"./observable\";\nimport \"./map\";\n\nlet o: Observable<number>;\no.map(x => x.toFixed());
Similarly, the global scope can be augmented from modules using a declare global declarations:
\nts// Ensure this is treated as a module.\nexport {};\n\ndeclare global {\n interface Array<T> {\n mapToNumbers(): number[];\n }\n}\n\nArray.prototype.mapToNumbers = function () { /* ... */ }
It’s not uncommon for an API to expect a specific set of strings for certain values.\nFor instance, consider a UI library that can move elements across the screen while controlling the “easing” of the animation.
\n\ntsdeclare class UIElement {\n animate(options: AnimationOptions): void;\n}\n\ninterface AnimationOptions {\n deltaX: number;\n deltaY: number;\n easing: string; // Can be \"ease-in\", \"ease-out\", \"ease-in-out\"\n}
However, this is error prone - there is nothing stopping a user from accidentally misspelling one of the valid easing values:
\n\nts// No errors\nnew UIElement().animate({ deltaX: 100, deltaY: 100, easing: \"ease-inout\" });
With TypeScript 1.8, we’ve introduced string literal types.\nThese types are written the same way string literals are, but in type positions.
\nUsers can now ensure that the type system will catch such errors.\nHere’s our new AnimationOptions using string literal types:
\ntsinterface AnimationOptions {\n deltaX: number;\n deltaY: number;\n easing: \"ease-in\" | \"ease-out\" | \"ease-in-out\";\n}\n\n// Error: Type '\"ease-inout\"' is not assignable to type '\"ease-in\" | \"ease-out\" | \"ease-in-out\"'\nnew UIElement().animate({ deltaX: 100, deltaY: 100, easing: \"ease-inout\" });
TypeScript 1.8 improves type inference involving source and target sides that are both union or intersection types.\nFor example, when inferring from string | string[] to string | T, we reduce the types to string[] and T, thus inferring string[] for T.
\ntstype Maybe<T> = T | void;\n\nfunction isDefined<T>(x: Maybe<T>): x is T {\n return x !== undefined && x !== null;\n}\n\nfunction isUndefined<T>(x: Maybe<T>): x is void {\n return x === undefined || x === null;\n}\n\nfunction getOrElse<T>(x: Maybe<T>, defaultValue: T): T {\n return isDefined(x) ? x : defaultValue;\n}\n\nfunction test1(x: Maybe<string>) {\n let x1 = getOrElse(x, \"Undefined\"); // string\n let x2 = isDefined(x) ? x : \"Undefined\"; // string\n let x3 = isUndefined(x) ? \"Undefined\" : x; // string\n}\n\nfunction test2(x: Maybe<number>) {\n let x1 = getOrElse(x, -1); // number\n let x2 = isDefined(x) ? x : -1; // number\n let x3 = isUndefined(x) ? -1 : x; // number\n}
AMD and System modules with --outFileSpecifying --outFile in conjunction with --module amd or --module system will concatenate all modules in the compilation into a single output file containing multiple module closures.
A module name will be computed for each module based on its relative location to rootDir.
\nts// file src/a.ts\nimport * as B from \"./lib/b\";\nexport function createA() {\n return B.createB();\n}
\nts// file src/lib/b.ts\nexport function createB() {\n return { };\n}
Results in:
\n\njsdefine(\"lib/b\", [\"require\", \"exports\"], function (require, exports) {\n \"use strict\";\n function createB() {\n return {};\n }\n exports.createB = createB;\n});\ndefine(\"a\", [\"require\", \"exports\", \"lib/b\"], function (require, exports, B) {\n \"use strict\";\n function createA() {\n return B.createB();\n }\n exports.createA = createA;\n});
default import interop with SystemJSModule loaders like SystemJS wrap CommonJS modules and expose then as a default ES6 import. This makes it impossible to share the definition files between the SystemJS and CommonJS implementation of the module as the module shape looks different based on the loader.
Setting the new compiler flag --allowSyntheticDefaultImports indicates that the module loader performs some kind of synthetic default import member creation not indicated in the imported .ts or .d.ts. The compiler will infer the existence of a default export that has the shape of the entire module itself.
System modules have this flag on by default.
\nlet/const in loopsPreviously an error, now supported in TypeScript 1.8.\nlet/const declarations within loops and captured in functions are now emitted to correctly match let/const freshness semantics.
\ntslet list = [];\nfor (let i = 0; i < 5; i++) {\n list.push(() => i);\n}\n\nlist.forEach(f => console.log(f()));
is compiled to:
\n\njsvar list = [];\nvar _loop_1 = function(i) {\n list.push(function () { return i; });\n};\nfor (var i = 0; i < 5; i++) {\n _loop_1(i);\n}\nlist.forEach(function (f) { return console.log(f()); });
And results in
\n\ncmd0\n1\n2\n3\n4
for..in statementsPreviously the type of a for..in variable is inferred to any; that allowed the compiler to ignore invalid uses within the for..in body.
Starting with TypeScript 1.8:
\nfor..in statement is implicitly string.T (such as an array) is indexed by a for..in variable of a containing for..in statement for an object with a numeric index signature and without a string index signature (again such as an array), the value produced is of type T.\ntsvar a: MyObject[];\nfor (var x in a) { // Type of x is implicitly string\n var obj = a[x]; // Type of obj is MyObject\n}
\"use strict\"; prologueModules were always parsed in strict mode as per ES6, but for non-ES6 targets this was not respected in the generated code. Starting with TypeScript 1.8, emitted modules are always in strict mode. This shouldn’t have any visible changes in most code as TS considers most strict mode errors as errors at compile time, but it means that some things which used to silently fail at runtime in your TS code, like assigning to NaN, will now loudly fail. You can reference the MDN Article on strict mode for a detailed list of the differences between strict mode and non-strict mode.
.js files with --allowJsOften there are external source files in your project that may not be authored in TypeScript.\nAlternatively, you might be in the middle of converting a JS code base into TS, but still want to bundle all your JS code into a single file with the output of your new TS code.
\n.js files are now allowed as input to tsc.\nThe TypeScript compiler checks the input .js files for syntax errors, and emits valid output based on the --target and --module flags.\nThe output can be combined with other .ts files as well.\nSource maps are still generated for .js files just like with .ts files.
--reactNamespacePassing --reactNamespace <JSX factory Name> along with --jsx react allows for using a different JSX factory from the default React.
The new factory name will be used to call createElement and __spread functions.
\ntsimport {jsxFactory} from \"jsxFactory\";\n\nvar div = <div>Hello JSX!</div>
Compiled with:
\n\nshelltsc --jsx react --reactNamespace jsxFactory --m commonJS
Results in:
\n\njs\"use strict\";\nvar jsxFactory_1 = require(\"jsxFactory\");\nvar div = jsxFactory_1.jsxFactory.createElement(\"div\", null, \"Hello JSX!\");
this-based type guardsTypeScript 1.8 extends user-defined type guard functions to class and interface methods.
\nthis is T is now valid return type annotation for methods in classes and interfaces.\nWhen used in a type narowing position (e.g. if statement), the type of the call expression target object would be narrowed to T.
\ntsclass FileSystemObject {\n isFile(): this is File { return this instanceof File; }\n isDirectory(): this is Directory { return this instanceof Directory;}\n isNetworked(): this is (Networked & this) { return this.networked; }\n constructor(public path: string, private networked: boolean) {}\n}\n\nclass File extends FileSystemObject {\n constructor(path: string, public content: string) { super(path, false); }\n}\nclass Directory extends FileSystemObject {\n children: FileSystemObject[];\n}\ninterface Networked {\n host: string;\n}\n\nlet fso: FileSystemObject = new File(\"foo/bar.txt\", \"foo\");\nif (fso.isFile()) {\n fso.content; // fso is File\n}\nelse if (fso.isDirectory()) {\n fso.children; // fso is Directory\n}\nelse if (fso.isNetworked()) {\n fso.host; // fso is networked\n}
Starting with TypeScript 1.8, official NuGet packages are available for the Typescript Compiler (tsc.exe) as well as the MSBuild integration (Microsoft.TypeScript.targets and Microsoft.TypeScript.Tasks.dll).
Stable packages are available here:
\n\nAlso, a nightly NuGet package to match the nightly npm package is available on myget:
\n\ntscWe understand that a ton of monochrome output can be a little difficult on the eyes.\nColors can help discern where a message starts and ends, and these visual clues are important when error output gets overwhelming.
\nBy just passing the --pretty command line option, TypeScript gives more colorful output with context about where things are going wrong.
![\"Showing](\"https://raw.githubusercontent.com/wiki/Microsoft/TypeScript/images/new-in-typescript/pretty01.png\")
With TypeScript 1.8, JSX tags are now classified and colorized in Visual Studio 2015.
\n![\"jsx\"](\"https://cloud.githubusercontent.com/assets/8052307/12271404/b875c502-b90f-11e5-93d8-c6740be354d1.png\")
The classification can be further customized by changing the font and color settings for the VB XML color and font settings through Tools->Options->Environment->Fonts and Colors page.
--project (-p) flag can now take any file pathThe --project command line option originally could only take paths to a folder containing a tsconfig.json.\nGiven the different scenarios for build configurations, it made sense to allow --project to point to any other compatible JSON file.\nFor instance, a user might want to target ES2015 with CommonJS modules for Node 5, but ES5 with AMD modules for the browser.\nWith this new work, users can easily manage two separate build targets using tsc alone without having to perform hacky workarounds like placing tsconfig.json files in separate directories.
The old behavior still remains the same if given a directory - the compiler will try to find a file in the directory named tsconfig.json.
It’s always nice to be able to document your configuration!\ntsconfig.json now accepts single and multi-line comments.
\nts{\n \"compilerOptions\": {\n \"target\": \"ES2015\", // running on node v5, yaay!\n \"sourceMap\": true // makes debugging easier\n },\n /*\n * Excluded files\n */\n \"exclude\": [\n \"file.d.ts\"\n ]\n}
TypeScript 1.8 allows users to use the --outFile argument with special file system entities like named pipes, devices, etc.
As an example, on many Unix-like systems, the standard output stream is accessible by the file /dev/stdout.
\nshelltsc foo.ts --outFile /dev/stdout
This can be used to pipe output between commands as well.
\nAs an example, we can pipe our emitted JavaScript into a pretty printer like pretty-js:
\n\nshelltsc foo.ts --outFile /dev/stdout | pretty-js
tsconfig.json in Visual Studio 2015TypeScript 1.8 allows tsconfig.json files in all project types.\nThis includes ASP.NET v4 projects, Console Application, and the Html Application with TypeScript project types.\nFurther, you are no longer limited to a single tsconfig.json file but can add multiple, and each will be built as part of the project.\nThis allows you to separate the configuration for different parts of your application without having to use multiple different projects.
![\"Showing](\"https://raw.githubusercontent.com/wiki/Microsoft/TypeScript/images/new-in-typescript/tsconfig-in-vs.png\")
We also disable the project properties page when you add a tsconfig.json file.\nThis means that all configuration changes have to be made in the tsconfig.json file itself.
tsconfig.json file, TypeScript files that are not considered part of that context are not compiled.tsconfig.json file, which must be in either the root or the scripts folder.tsconfig.json in most project types.