Theprogrammersfirst | A technical portal.

Emit Decorator Metadata - emitDecoratorMetadata Enables experimental support for emitting type metadata for decorators which works with the module reflect-metadata. For example, here is the JavaScript function LogMethod(   target: any,   propertyKey: string | symbol,   descriptor: PropertyDescriptor ) {   console.log(target);   console.log(propertyKey);   console.log(descriptor); } class Demo {   @LogMethod   public foo(bar: number) {     // do nothing   } } const demo = new Demo();Try With emitDecoratorMetadata not set to true (default): "use strict"; var __decorate = (this && this.__decorate) || function (decorators, target, key, desc) {     var c = arguments.length, r = c < 3 ? target : desc === null ? desc = Object.getOwnPropertyDescriptor(target, key) : desc, d;     if (typeof Reflect === "object" && typeof Reflect.decorate === "function") r = Reflect.decorate...

#Linter Checks A collection of extra checks, which somewhat cross the boundaries of compiler vs linter. You may prefer to use a tool like eslint over these options if you are looking for more in-depth rules. # No Fallthrough Cases In Switch - noFallthroughCasesInSwitch Report errors for fallthrough cases in switch statements. Ensures that any non-empty case inside a switch statement includes either break or return. This means you won’t accidentally ship a case fallthrough bug. const a: number = 6; switch (a) {   case 0: Fallthrough case in switch.     console.log("even");   case 1:     console.log("odd");     break; }Try Default: false Released: 1.8 # No Implicit Returns - noImplicitReturns When enabled, TypeScript will check all code paths in a function to ensure they return a value. function lookupHeadphonesManufacturer(color: "blue" | "black"): string { Function lacks ending return statement and return type does not i...

#Source Maps In order to provide rich debugging tools and crash reports which make sense to developers, TypeScript supports emitting additional files which conform to the JavaScript Source Map standards. These are emitted as .map files which live alongside the file they represent. # Inline Source Map - inlineSourceMap When set, instead of writing out a .js.map file to provide source maps, TypeScript will embed the source map content in the .js files. Although this results in larger JS files, it can be convenient in some scenarios. For example, you might want to debug JS files on a webserver that doesn’t allow .map files to be served. Mutually exclusive with sourceMap. For example, with this TypeScript: const helloWorld = "hi"; console.log(helloWorld); Converts to this JavaScript: "use strict"; const helloWorld = "hi"; console.log(helloWorld);Try Then enable building it with inlineSourceMap enabled there is a comment at the bottom of th...

#Module Resolution # Allow Synthetic Default Imports - allowSyntheticDefaultImports When set to true, allowSyntheticDefaultImports allows you to write an import like: import React from "react"; instead of: import * as React from "react"; When the module does not explicitly specify a default export. For example, without allowSyntheticDefaultImports as true: // @filename: utilFunctions.js Module '"utilFunctions"' can only be default-imported using the 'allowSyntheticDefaultImports' flag const getStringLength = (str) => str.length; module.exports = {   getStringLength, }; // @filename: index.ts import utils from "./utilFunctions"; const count = utils.getStringLength("Check JS");Try This code raises an error because there isn’t a default object which you can import. Even though it feels like it should. For convenience, transpilers like Babel will automatically create a default if one isn’t create...

#Strict Checks We recommend using the compiler option strict to opt-in to every possible improvement as they are built. TypeScript supports a wide spectrum of JavaScript patterns and defaults to allowing for quite a lot of flexibility in accommodating these styles. Often the safety and potential scalability of a codebase can be at odds with some of these techniques. Because of the variety of supported JavaScript, upgrading to a new version of TypeScript can uncover two types of errors: Errors which already exist in your codebase, which TypeScript has uncovered because the language has refined its understanding of JavaScript. A new suite of errors which tackle a new problem domain. TypeScript will usually add a compiler flag for the latter set of errors, and by default these are not enabled. # Always Strict - alwaysStrict Ensures that your files are parsed in the ECMAScript strict mode, and emit “use strict” for each source file. ECMAScript strict mode was introduced in ...

#Project Options These settings are used to define the runtime expectations of your project, how and where you want the JavaScript to be emitted and the level of integration you want with existing JavaScript code. # Allow JS - allowJs Allow JavaScript files to be imported inside your project, instead of just .ts and .tsx files. For example, this JS file: // @filename: card.js export const defaultCardDeck = "Heart";Try When imported into a TypeScript file will raise an error: // @filename: index.ts import { defaultCardDeck } from "./card"; console.log(defaultCardDeck);Try Imports fine with allowJs enabled: // @filename: index.ts import { defaultCardDeck } from "./card"; console.log(defaultCardDeck);Try This flag can be used as a way to incrementally add TypeScript files into JS projects by allowing the .ts and .tsx files to live along-side existing JavaScript files. Default: false Related: checkJs, emitDeclarationOnly Released: ...

#File Inclusion These settings help you ensure that TypeScript picks up the right files. # Exclude - exclude Specifies an array of filenames or patterns that should be skipped when resolving include. Important: exclude only changes which files are included as a result of the include setting. A file specified by exclude can still become part of your codebase due to an import statement in your code, a types inclusion, a /// <reference directive, or being specified in the files list. It is not a mechanism that prevents a file from being included in the codebase - it simply changes what the include setting finds. Default: ["node_modules", "bower_components", "jspm_packages"], plus the value of outDir if one is specified. Related: include, files # Extends - extends The value of extends is a string which contains a path to another configuration file to inherit from. The path may use Node.js style resolution. The configuration from the base f...