Menentukan daftar berkas yang diijinkan untuk disertakan dalam program. Kesalahan terjadi jika salah satu berkas tidak dapat ditemukan.

{
  "compilerOptions": {},
  "files": [
    "core.ts",
    "sys.ts",
    "types.ts",
    "scanner.ts",
    "parser.ts",
    "utilities.ts",
    "binder.ts",
    "checker.ts",
    "tsc.ts"
  ]
}

Ini berguna ketika Anda hanya memiliki sejumlah berkas kecil dan tidak perlu menggunakan glob untuk mereferensikan banyak berkas. Jika Anda membutuhkannya, gunakan include.

Nilai extends adalah string yang berisi jalur ke berkas konfigurasi lain untuk mewarisi. Jalur tersebut mungkin menggunakan resolusi gaya Node.js.

Konfigurasi dari berkas dasar dimuat terlebih dahulu, kemudian diganti dengan yang ada di berkas konfigurasi pewarisan. Semua jalur relatif yang ditemukan di berkas konfigurasi akan diselesaikan secara relatif terhadap berkas konfigurasi tempat asalnya.

Perlu diperhatikan bahwa files, include dan exclude dari berkas konfigurasi pewaris menimpa konfigurasi yang berasal dari berkas konfigurasi asal, dan sirkularitas antara berkas konfigurasi tidak diperbolehkan.

Saat ini, satu-satunya properti tingkat atas yang dikecualikan dari pewarisan adalah referensi.

Contoh

configs/base.json:

{
  "compilerOptions": {
    "noImplicitAny": true,
    "strictNullChecks": true
  }
}

tsconfig.json:

{
  "extends": "./configs/base",
  "files": ["main.ts", "supplemental.ts"]
}

tsconfig.nostrictnull.json:

{
  "extends": "./tsconfig",
  "compilerOptions": {
    "strictNullChecks": false
  }
}

Properti dengan jalur relatif yang ditemukan di berkas konfigurasi, yang tidak dikecualikan dari pewarisan, akan diresolusikan secara relatif terhadap berkas konfigurasi tempat asalnya.

Menentukan sebuah susunan nama berkas atau contoh berkas untuk dimasukkan ke dalam program. Nama berkas ini diselesaikan dengan direktori yang berisi berkas tsconfig.json.

json
{
  "include": ["src/**/*", "tests/**/*"]
}

Yang akan mencakup:

.
├── scripts                ⨯
│   ├── lint.ts            ⨯
│   ├── update_deps.ts     ⨯
│   └── utils.ts           ⨯
├── src                    ✓
│   ├── client             ✓
│   │    ├── index.ts      ✓
│   │    └── utils.ts      ✓
│   ├── server             ✓
│   │    └── index.ts      ✓
├── tests                  ✓
│   ├── app.test.ts        ✓
│   ├── utils.ts           ✓
│   └── tests.d.ts         ✓
├── package.json
├── tsconfig.json
└── yarn.lock

include dan exclude mendukung karakter untuk membuat pola global:

• * cocok dengan nol atau lebih karakter (tidak termasuk pemisah direktori)
• ? cocok dengan salah satu karakter (tidak termasuk pemisah direktori)
• **/ cocok dengan direktori apa pun yang bertingkat.

Jika contoh umum tidak menyertakan ekstensi berkas, maka hanya berkas dengan ekstensi yang didukung yang disertakan (misalnya .ts,.tsx, dan .d.ts secara default, dengan.js dan . jsx jika allowJs disetel ke true).

Menentukan array nama berkas atau pola yang harus dilewati saat menyelesaikan include.

Penting: exclude hanya mengubah berkas mana yang disertakan sebagai hasil dari pengaturan include. Berkas yang ditentukan oleh exclude masih bisa menjadi bagian dari basis kode Anda karena pernyataan import dalam kode Anda, penyertaan types, perintah /// <reference, atau ditentukan dalam daftar files.

Ini bukan mekanisme yang mencegah berkas untuk disertakan dalam basis kode - ini hanya mengubah apa yang ditemukan oleh setelan include.

Referensi proyek adalah cara untuk menyusun program TypeScript Anda menjadi bagian-bagian yang lebih kecil. Menggunakan Referensi Proyek dapat sangat meningkatkan waktu interaksi build dan editor, menerapkan pemisahan logika antar komponen, dan mengatur kode Anda dengan cara yang baru dan lebih baik.

Anda dapat membaca lebih lanjut tentang bagaimana cara kerja referensi di bagian Referensi Proyek dari buku pegangan

Kapan:

• undefined default memberikan saran sebagai peringatan kepada editor
• true kode yang tidak dapat dijangkau diabaikan
• false menimbulkan galat kompiler tentang kode yang tidak dapat dijangkau

Peringatan ini hanya tentang kode yang terbukti tidak dapat dijangkau karena penggunaan sintaks JavaScript, misalnya:

ts
function fn(n: number) {
  if (n > 5) {
    return true;
  } else {
    return false;
  }
  return true;
}

Dengan "allowUnreachableCode": false:

ts
function fn(n: number) {
  if (n > 5) {
    return true;
  } else {
    return false;
  }
  return true;
Unreachable code detected.7027Unreachable code detected.
}Try

Ini tidak mempengaruhi galat atas dasar kode yang muncul menjadi tidak dapat dijangkau karena menggolongkan uraian.

Setel ke false untuk menonaktifkan peringatan tentang label yang tidak digunakan.

Label sangat jarang di JavaScript dan biasanya menunjukkan upaya untuk menulis objek dengan tepat:

ts
function verifikasiUmur(umur: number) {
  // Lupa menulis pernyataan 'return'
  if (umur > 18) {
    terverifikasi: true;
Unused label.7028Unused label.
  }
}Try

Pastikan bahwa berkas Anda diurai di Mode strict EcmaScript, dan mengeluarkan “use strict” untuk setiap berkas asal.

ECMAScript strict mode strict diperkenalkan di ES5 dan memberikan perubahan perilaku pada waktu proses mesin JavaScript untuk meningkatkan kinerja dan membuat kesalahan muncul agar diabaikan.

With exactOptionalPropertyTypes enabled, TypeScript applies stricter rules around how it handles properties on type or interfaces which have a ? prefix.

For example, this interface declares that there is a property which can be one of two strings: ‘dark’ or ‘light’ or it should not be in the object.

ts
interface UserDefaults {
  // The absence of a value represents 'system'
  colorThemeOverride?: "dark" | "light";
}

Without this flag enabled, there are three values which you can set colorThemeOverride to be: “dark”, “light” and undefined.

Setting the value to undefined will allow most JavaScript runtime checks for the existence to fail, which is effectively falsy. However, this isn’t quite accurate; colorThemeOverride: undefined is not the same as colorThemeOverride not being defined. For example, "colorThemeOverride" in settings would have different behavior with undefined as the key compared to not being defined.

exactOptionalPropertyTypes makes TypeScript truly enforce the definition provided as an optional property:

ts
const settings = getUserSettings();
settings.colorThemeOverride = "dark";
settings.colorThemeOverride = "light";
 
// But not:
settings.colorThemeOverride = undefined;
Type 'undefined' is not assignable to type '"dark" | "light"' with 'exactOptionalPropertyTypes: true'. Consider adding 'undefined' to the type of the target.2412Type 'undefined' is not assignable to type '"dark" | "light"' with 'exactOptionalPropertyTypes: true'. Consider adding 'undefined' to the type of the target.Try

Report errors for fallthrough cases in switch statements. Ensures that any non-empty case inside a switch statement includes either break, return, or throw. This means you won’t accidentally ship a case fallthrough bug.

ts
const a: number = 6;
 
switch (a) {
  case 0:
Fallthrough case in switch.7029Fallthrough case in switch.
    console.log("even");
  case 1:
    console.log("odd");
    break;
}Try

Di beberapa kasus, dimana tidak ada anotasi tipe yang ada, TypeScript akan kembali ke suatu tipe dari any untuk suatu variabel yang saat itu tidakbisa simpulkan tipenya.

Ini dapat menyebabkan beberapa kesalahan untuk dilewatkan, sebagai contoh:

ts
function fn(s) {
  // Bukan kesalahan?
  console.log(s.subtr(3));
}
fn(42);Try

Menyalakan opsi noImplicitAny namun TypeScript akan mengeluarkan kesalahan setiap kali any yang ia simpulkan:

ts
function fn(s) {
Parameter 's' implicitly has an 'any' type.7006Parameter 's' implicitly has an 'any' type.
  console.log(s.subtr(3));
}Try

When working with classes which use inheritance, it’s possible for a sub-class to get “out of sync” with the functions it overloads when they are renamed in the base class.

For example, imagine you are modeling a music album syncing system:

ts
class Album {
  download() {
    // Default behavior
  }
}
 
class SharedAlbum extends Album {
  download() {
    // Override to get info from many sources
  }
}Try

Then when you add support for machine-learning generated playlists, you refactor the Album class to have a ‘setup’ function instead:

ts
class Album {
  setup() {
    // Default behavior
  }
}
 
class MLAlbum extends Album {
  setup() {
    // Override to get info from algorithm
  }
}
 
class SharedAlbum extends Album {
  download() {
    // Override to get info from many sources
  }
}Try

In this case, TypeScript has provided no warning that download on SharedAlbum expected to override a function in the base class.

Using noImplicitOverride you can ensure that the sub-classes never go out of sync, by ensuring that functions which override include the keyword override.

The following example has noImplicitOverride enabled, and you can see the error received when override is missing:

ts
class Album {
  setup() {}
}
 
class MLAlbum extends Album {
  override setup() {}
}
 
class SharedAlbum extends Album {
  setup() {}
This member must have an 'override' modifier because it overrides a member in the base class 'Album'.4114This member must have an 'override' modifier because it overrides a member in the base class 'Album'.
}Try

Saat diaktifkaan, TypeScript akan melakukan pengecekan semua jalur kode di suatu fungsi untuk memastikan mereka mengembalikan suatu nilai.

ts
function lookupHeadphonesManufacturer(color: "blue" | "black"): string {
Function lacks ending return statement and return type does not include 'undefined'.2366Function lacks ending return statement and return type does not include 'undefined'.
  if (color === "blue") {
    return "beats";
  } else {
    ("bose");
  }
}Try

Menimbulkan kesalahan kepada pernyataan ‘this’ dengan tersiratnya tipe ‘any’.

Sebagai contoh, class dibawah ini mengembalikan suatu fungsi yang mencoba mengakses this.width dan this.height – tapi konteksnya untuk this didalam fungsi yang didalam getAreaFunction ini, bukanlah instansi dari class Rectangle.

ts
class Rectangle {
  width: number;
  height: number;
 
  constructor(width: number, height: number) {
    this.width = width;
    this.height = height;
  }
 
  getAreaFunction() {
    return function () {
      return this.width * this.height;
'this' implicitly has type 'any' because it does not have a type annotation.
'this' implicitly has type 'any' because it does not have a type annotation.2683
2683'this' implicitly has type 'any' because it does not have a type annotation.
'this' implicitly has type 'any' because it does not have a type annotation.
    };
  }
}Try

This setting ensures consistency between accessing a field via the “dot” (obj.key) syntax, and “indexed” (obj["key"]) and the way which the property is declared in the type.

Without this flag, TypeScript will allow you to use the dot syntax to access fields which are not defined:

ts
interface GameSettings {
  // Known up-front properties
  speed: "fast" | "medium" | "slow";
  quality: "high" | "low";
 
  // Assume anything unknown to the interface
  // is a string.
  [key: string]: string;
}
 
const settings = getSettings();
settings.speed;
          
(property) GameSettings.speed: "fast" | "medium" | "slow"
settings.quality;
           
(property) GameSettings.quality: "high" | "low"
 
// Unknown key accessors are allowed on
// this object, and are `string`
settings.username;
            
(index) GameSettings[string]: stringTry

Turning the flag on will raise an error because the unknown field uses dot syntax instead of indexed syntax.

ts
const settings = getSettings();
settings.speed;
settings.quality;
 
// This would need to be settings["username"];
settings.username;
Property 'username' comes from an index signature, so it must be accessed with ['username'].4111Property 'username' comes from an index signature, so it must be accessed with ['username'].
            
(index) GameSettings[string]: stringTry

The goal of this flag is to signal intent in your calling syntax about how certain you are this property exists.

TypeScript has a way to describe objects which have unknown keys but known values on an object, via index signatures.

ts
interface EnvironmentVars {
  NAME: string;
  OS: string;
 
  // Unknown properties are covered by this index signature.
  [propName: string]: string;
}
 
declare const env: EnvironmentVars;
 
// Declared as existing
const sysName = env.NAME;
const os = env.OS;
      
const os: string
 
// Not declared, but because of the index
// signature, then it is considered a string
const nodeEnv = env.NODE_ENV;
        
const nodeEnv: stringTry

Turning on noUncheckedIndexedAccess will add undefined to any un-declared field in the type.

ts
declare const env: EnvironmentVars;
 
// Declared as existing
const sysName = env.NAME;
const os = env.OS;
      
const os: string
 
// Not declared, but because of the index
// signature, then it is considered a string
const nodeEnv = env.NODE_ENV;
        
const nodeEnv: string | undefinedTry

Report errors on unused local variables.

ts
const createKeyboard = (modelID: number) => {
  const defaultModelID = 23;
'defaultModelID' is declared but its value is never read.6133'defaultModelID' is declared but its value is never read.
  return { type: "keyboard", modelID };
};Try

Report errors on unused parameters in functions.

ts
const createDefaultKeyboard = (modelID: number) => {
'modelID' is declared but its value is never read.6133'modelID' is declared but its value is never read.
  const defaultModelID = 23;
  return { type: "keyboard", modelID: defaultModelID };
};Try

The strict flag enables a wide range of type checking behavior that results in stronger guarantees of program correctness. Turning this on is equivalent to enabling all of the strict mode family options, which are outlined below. You can then turn off individual strict mode family checks as needed.

Future versions of TypeScript may introduce additional stricter checking under this flag, so upgrades of TypeScript might result in new type errors in your program. When appropriate and possible, a corresponding flag will be added to disable that behavior.

When set, TypeScript will check that the built-in methods of functions call, bind, and apply are invoked with correct argument for the underlying function:

ts
// With strictBindCallApply on
function fn(x: string) {
  return parseInt(x);
}
 
const n1 = fn.call(undefined, "10");
 
const n2 = fn.call(undefined, false);
Argument of type 'boolean' is not assignable to parameter of type 'string'.2345Argument of type 'boolean' is not assignable to parameter of type 'string'.Try

Otherwise, these functions accept any arguments and will return any:

ts
// With strictBindCallApply off
function fn(x: string) {
  return parseInt(x);
}
 
// Note: No error; return type is 'any'
const n = fn.call(undefined, false);Try

When enabled, this flag causes functions parameters to be checked more correctly.

Here’s a basic example with strictFunctionTypes off:

ts
function fn(x: string) {
  console.log("Hello, " + x.toLowerCase());
}
 
type StringOrNumberFunc = (ns: string | number) => void;
 
// Unsafe assignment
let func: StringOrNumberFunc = fn;
// Unsafe call - will crash
func(10);Try

With strictFunctionTypes on, the error is correctly detected:

ts
function fn(x: string) {
  console.log("Hello, " + x.toLowerCase());
}
 
type StringOrNumberFunc = (ns: string | number) => void;
 
// Unsafe assignment is prevented
let func: StringOrNumberFunc = fn;
Type '(x: string) => void' is not assignable to type 'StringOrNumberFunc'.
  Types of parameters 'x' and 'ns' are incompatible.
    Type 'string | number' is not assignable to type 'string'.
      Type 'number' is not assignable to type 'string'.2322Type '(x: string) => void' is not assignable to type 'StringOrNumberFunc'.
  Types of parameters 'x' and 'ns' are incompatible.
    Type 'string | number' is not assignable to type 'string'.
      Type 'number' is not assignable to type 'string'.Try

During development of this feature, we discovered a large number of inherently unsafe class hierarchies, including some in the DOM. Because of this, the setting only applies to functions written in function syntax, not to those in method syntax:

ts
type Methodish = {
  func(x: string | number): void;
};
 
function fn(x: string) {
  console.log("Hello, " + x.toLowerCase());
}
 
// Ultimately an unsafe assignment, but not detected
const m: Methodish = {
  func: fn,
};
m.func(10);Try

When strictNullChecks is false, null and undefined are effectively ignored by the language. This can lead to unexpected errors at runtime.

When strictNullChecks is true, null and undefined have their own distinct types and you’ll get a type error if you try to use them where a concrete value is expected.

For example with this TypeScript code, users.find has no guarantee that it will actually find a user, but you can write code as though it will:

ts
declare const loggedInUsername: string;
 
const users = [
  { name: "Oby", age: 12 },
  { name: "Heera", age: 32 },
];
 
const loggedInUser = users.find((u) => u.name === loggedInUsername);
console.log(loggedInUser.age);Try

Setting strictNullChecks to true will raise an error that you have not made a guarantee that the loggedInUser exists before trying to use it.

ts
declare const loggedInUsername: string;
 
const users = [
  { name: "Oby", age: 12 },
  { name: "Heera", age: 32 },
];
 
const loggedInUser = users.find((u) => u.name === loggedInUsername);
console.log(loggedInUser.age);
'loggedInUser' is possibly 'undefined'.18048'loggedInUser' is possibly 'undefined'.Try

The second example failed because the array’s find function looks a bit like this simplification:

ts
// When strictNullChecks: true
type Array = {
  find(predicate: (value: any, index: number) => boolean): S | undefined;
};
// When strictNullChecks: false the undefined is removed from the type system,
// allowing you to write code which assumes it always found a result
type Array = {
  find(predicate: (value: any, index: number) => boolean): S;
};

When set to true, TypeScript will raise an error when a class property was declared but not set in the constructor.

ts
class UserAccount {
  name: string;
  accountType = "user";
 
  email: string;
Property 'email' has no initializer and is not definitely assigned in the constructor.2564Property 'email' has no initializer and is not definitely assigned in the constructor.
  address: string | undefined;
 
  constructor(name: string) {
    this.name = name;
    // Note that this.email is not set
  }
}Try

In the above case:

• this.name is set specifically.
• this.accountType is set by default.
• this.email is not set and raises an error.
• this.address is declared as potentially undefined which means it does not have to be set.

In TypeScript 4.0, support was added to allow changing the type of the variable in a catch clause from any to unknown. Allowing for code like:

ts
try {
  // ...
} catch (err: unknown) {
  // We have to verify err is an
  // error before using it as one.
  if (err instanceof Error) {
    console.log(err.message);
  }
}Try

This pattern ensures that error handling code becomes more comprehensive because you cannot guarantee that the object being thrown is a Error subclass ahead of time. With the flag useUnknownInCatchVariables enabled, then you do not need the additional syntax (: unknown) nor a linter rule to try enforce this behavior.

In TypeScript 5.0, when an import path ends in an extension that isn’t a known JavaScript or TypeScript file extension, the compiler will look for a declaration file for that path in the form of {file basename}.d.{extension}.ts. For example, if you are using a CSS loader in a bundler project, you might want to write (or generate) declaration files for those stylesheets:

css
/* app.css */
.cookie-banner {
  display: none;
}

ts
// app.d.css.ts
declare const css: {
  cookieBanner: string;
};
export default css;

ts
// App.tsx
import styles from "./app.css";
styles.cookieBanner; // string

By default, this import will raise an error to let you know that TypeScript doesn’t understand this file type and your runtime might not support importing it. But if you’ve configured your runtime or bundler to handle it, you can suppress the error with the new --allowArbitraryExtensions compiler option.

Note that historically, a similar effect has often been achievable by adding a declaration file named app.css.d.ts instead of app.d.css.ts - however, this just worked through Node’s require resolution rules for CommonJS. Strictly speaking, the former is interpreted as a declaration file for a JavaScript file named app.css.js. Because relative files imports need to include extensions in Node’s ESM support, TypeScript would error on our example in an ESM file under --moduleResolution node16 or nodenext.

For more information, read up the proposal for this feature and its corresponding pull request.

--allowImportingTsExtensions allows TypeScript files to import each other with a TypeScript-specific extension like .ts, .mts, or .tsx.

This flag is only allowed when --noEmit or --emitDeclarationOnly is enabled, since these import paths would not be resolvable at runtime in JavaScript output files. The expectation here is that your resolver (e.g. your bundler, a runtime, or some other tool) is going to make these imports between .ts files work.

Jika disetel ke true, allowUmdGlobalAccess memungkinkan Anda mengakses ekspor UMD sebagai global dari dalam berkas modul. Berkas modul adalah berkas yang telah diimpor dan/atau diekspor. Tanpa opsi ini, menggunakan ekspor dari modul UMD memerlukan deklarasi impor.

Contoh kasus penggunaan untuk opsi ini adalah proyek web yang anda tahu bahwa pustaka tertentu (seperti jQuery atau Lodash) akan selalu tersedia saat runtime, tetapi Anda tidak dapat mengaksesnya dengan impor.

Memungkinkan Anda menyetel direktori dasar untuk menyelesaikan nama modul dengan benar.

Anda dapat menentukan folder root di mana Anda dapat melakukan keputusan berkas yang sesungguhnya, misalnya :

baseUrl
├── ex.ts
├── hello
│   └── world.ts
└── tsconfig.json

Dengan "baseUrl": "./" di dalam proyek ini TypeScript akan mencari berkas yang dimulai dari folder yang sama dengan tsconfig.json.

ts
import { helloWorld } from "hello/world";
console.log(helloWorld);

Jika Anda lelah cara impor selalu seperti "../" atau "./". Atau harus untuk merubah saat Anda memindahkan berkas, ini adalah cara terbaik untuk memperbaikinya.

--customConditions takes a list of additional conditions that should succeed when TypeScript resolves from an exports or imports field of a package.json. These conditions are added to whatever existing conditions a resolver will use by default.

For example, when this field is set in a tsconfig.json as so:

jsonc
{
  "compilerOptions": {
    "target": "es2022",
    "moduleResolution": "bundler",
    "customConditions": ["my-condition"]
  }
}

Any time an exports or imports field is referenced in package.json, TypeScript will consider conditions called my-condition.

So when importing from a package with the following package.json

jsonc
{
  // ...
  "exports": {
    ".": {
      "my-condition": "./foo.mjs",
      "node": "./bar.mjs",
      "import": "./baz.mjs",
      "require": "./biz.mjs"
    }
  }
}

TypeScript will try to look for files corresponding to foo.mjs.

This field is only valid under the node16, nodenext, and bundler options for --moduleResolution.

Sets the module system for the program. See the theory behind TypeScript’s module option and its reference page for more information. You very likely want "nodenext" for modern Node.js projects and preserve or esnext for code that will be bundled.

Changing module affects moduleResolution which also has a reference page.

Here’s some example output for this file:

ts
// @filename: index.ts
import { valueOfPi } from "./constants";
 
export const twoPi = valueOfPi * 2;Try

CommonJS

ts
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.twoPi = void 0;
const constants_1 = require("./constants");
exports.twoPi = constants_1.valueOfPi * 2;
 Try

UMD

ts
(function (factory) {
    if (typeof module === "object" && typeof module.exports === "object") {
        var v = factory(require, exports);
        if (v !== undefined) module.exports = v;
    }
    else if (typeof define === "function" && define.amd) {
        define(["require", "exports", "./constants"], factory);
    }
})(function (require, exports) {
    "use strict";
    Object.defineProperty(exports, "__esModule", { value: true });
    exports.twoPi = void 0;
    const constants_1 = require("./constants");
    exports.twoPi = constants_1.valueOfPi * 2;
});
 Try

AMD

ts
define(["require", "exports", "./constants"], function (require, exports, constants_1) {
    "use strict";
    Object.defineProperty(exports, "__esModule", { value: true });
    exports.twoPi = void 0;
    exports.twoPi = constants_1.valueOfPi * 2;
});
 Try

System

ts
System.register(["./constants"], function (exports_1, context_1) {
    "use strict";
    var constants_1, twoPi;
    var __moduleName = context_1 && context_1.id;
    return {
        setters: [
            function (constants_1_1) {
                constants_1 = constants_1_1;
            }
        ],
        execute: function () {
            exports_1("twoPi", twoPi = constants_1.valueOfPi * 2);
        }
    };
});
 Try

ESNext

ts
import { valueOfPi } from "./constants";
export const twoPi = valueOfPi * 2;
 Try

ES2015/ES6/ES2020/ES2022

ts
import { valueOfPi } from "./constants";
export const twoPi = valueOfPi * 2;
 Try

In addition to the base functionality of ES2015/ES6, ES2020 adds support for dynamic imports, and import.meta while ES2022 further adds support for top level await.

node16/nodenext

Available from 4.7+, the node16 and nodenext modes integrate with Node’s native ECMAScript Module support. The emitted JavaScript uses either CommonJS or ES2020 output depending on the file extension and the value of the type setting in the nearest package.json. Module resolution also works differently. You can learn more in the handbook and Modules Reference.

preserve

In --module preserve (added in TypeScript 5.4), ECMAScript imports and exports written in input files are preserved in the output, and CommonJS-style import x = require("...") and export = ... statements are emitted as CommonJS require and module.exports. In other words, the format of each individual import or export statement is preserved, rather than being coerced into a single format for the whole compilation (or even a whole file).

ts
import { valueOfPi } from "./constants";
const constants = require("./constants");
export const piSquared = valueOfPi * constants.valueOfPi;
 Try

While it’s rare to need to mix imports and require calls in the same file, this module mode best reflects the capabilities of most modern bundlers, as well as the Bun runtime.

Why care about TypeScript’s module emit with a bundler or with Bun, where you’re likely also setting noEmit? TypeScript’s type checking and module resolution behavior are affected by the module format that it would emit. Setting module gives TypeScript information about how your bundler or runtime will process imports and exports, which ensures that the types you see on imported values accurately reflect what will happen at runtime or after bundling.

None

ts
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.twoPi = void 0;
const constants_1 = require("./constants");
exports.twoPi = constants_1.valueOfPi * 2;
 Try

Specify the module resolution strategy:

• 'node16' or 'nodenext' for modern versions of Node.js. Node.js v12 and later supports both ECMAScript imports and CommonJS require, which resolve using different algorithms. These moduleResolution values, when combined with the corresponding module values, picks the right algorithm for each resolution based on whether Node.js will see an import or require in the output JavaScript code.
• 'node10' (previously called 'node') for Node.js versions older than v10, which only support CommonJS require. You probably won’t need to use node10 in modern code.
• 'bundler' for use with bundlers. Like node16 and nodenext, this mode supports package.json "imports" and "exports", but unlike the Node.js resolution modes, bundler never requires file extensions on relative paths in imports.
• 'classic' was used in TypeScript before the release of 1.6. classic should not be used.

There are reference pages explaining the theory behind TypeScript’s module resolution and the details of each option.

Provides a way to override the default list of file name suffixes to search when resolving a module.

{
  "compilerOptions": {
    "moduleSuffixes": [".ios", ".native", ""]
  }
}

Given the above configuration, an import like the following:

ts
import * as foo from "./foo";

TypeScript will look for the relative files ./foo.ios.ts, ./foo.native.ts, and finally ./foo.ts.

Note the empty string "" in moduleSuffixes which is necessary for TypeScript to also look-up ./foo.ts.

This feature can be useful for React Native projects where each target platform can use a separate tsconfig.json with differing moduleSuffixes.

By default, TypeScript will examine the initial set of files for import and <reference directives and add these resolved files to your program.

If noResolve is set, this process doesn’t happen. However, import statements are still checked to see if they resolve to a valid module, so you’ll need to make sure this is satisfied by some other means.

In JavaScript it’s possible to import a module without actually importing any values from it.

ts
import "some-module";

These imports are often called side effect imports because the only useful behavior they can provide is by executing some side effect (like registering a global variable, or adding a polyfill to a prototype).

By default, TypeScript will not check these imports for validity. If the import resolves to a valid source file, TypeScript will load and check the file. If no source file is found, TypeScript will silently ignore the import.

This is surprising behavior, but it partially stems from modeling patterns in the JavaScript ecosystem. For example, this syntax has also been used with special loaders in bundlers to load CSS or other assets. Your bundler might be configured in such a way where you can include specific .css files by writing something like the following:

tsx
import "./button-component.css";
export function Button() {
  // ...
}

Still, this masks potential typos on side effect imports.

When --noUncheckedSideEffectImports is enabled, TypeScript will error if it can’t find a source file for a side effect import.

ts
import "oops-this-module-does-not-exist";
//     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// error: Cannot find module 'oops-this-module-does-not-exist' or its corresponding
//        type declarations.

When enabling this option, some working code may now receive an error, like in the CSS example above. To work around this, users who want to just write side effect imports for assets might be better served by writing what’s called an ambient module declaration with a wildcard specifier. It would go in a global file and look something like the following:

ts
// ./src/globals.d.ts
// Recognize all CSS files as module imports.
declare module "*.css" {}

In fact, you might already have a file like this in your project! For example, running something like vite init might create a similar vite-env.d.ts.

A series of entries which re-map imports to lookup locations relative to the baseUrl if set, or to the tsconfig file itself otherwise. There is a larger coverage of paths in the moduleResolution reference page.

paths lets you declare how TypeScript should resolve an import in your require/imports.

{
  "compilerOptions": {
    "paths": {
      "jquery": ["./vendor/jquery/dist/jquery"]
    }
  }
}

This would allow you to be able to write import "jquery", and get all of the correct typing locally.

{
  "compilerOptions": {
    "paths": {
        "app/*": ["./src/app/*"],
        "config/*": ["./src/app/_config/*"],
        "environment/*": ["./src/environments/*"],
        "shared/*": ["./src/app/_shared/*"],
        "helpers/*": ["./src/helpers/*"],
        "tests/*": ["./src/tests/*"]
    },
}

In this case, you can tell the TypeScript file resolver to support a number of custom prefixes to find code.

Note that this feature does not change how import paths are emitted by tsc, so paths should only be used to inform TypeScript that another tool has this mapping and will use it at runtime or when bundling.

Memperbolehkan mengimpor modul dengan ekstensi ‘.json’ merupakan praktik umum pada proyek node. Ini termasuk membuat jenis untuk import berdasarkan bentuk JSON statis.

TypeScript tidak mendukung penyelesaian berkas JSON secara bawaan:

ts
// @filename: settings.json
{
    "repo": "TypeScript",
    "dry": false,
    "debug": false
}
// @filename: index.ts
import settings from "./settings.json";
Cannot find module './settings.json'. Consider using '--resolveJsonModule' to import module with '.json' extension.2732Cannot find module './settings.json'. Consider using '--resolveJsonModule' to import module with '.json' extension.
 
settings.debug === true;
settings.dry === 2;Try

Mengaktifkan opsi memungkinkan impor JSON, dan memvalidasi jenis dalam berkas JSON tersebut.

ts
// @filename: settings.json
{
    "repo": "TypeScript",
    "dry": false,
    "debug": false
}
// @filename: index.ts
import settings from "./settings.json";
 
settings.debug === true;
settings.dry === 2;
This comparison appears to be unintentional because the types 'boolean' and 'number' have no overlap.2367This comparison appears to be unintentional because the types 'boolean' and 'number' have no overlap.Try

--resolvePackageJsonExports forces TypeScript to consult the exports field of package.json files if it ever reads from a package in node_modules.

This option defaults to true under the node16, nodenext, and bundler options for --moduleResolution.

--resolvePackageJsonImports forces TypeScript to consult the imports field of package.json files when performing a lookup that starts with # from a file whose ancestor directory contains a package.json.

This option defaults to true under the node16, nodenext, and bundler options for --moduleResolution.

Bawaan: Jalur umum terpanjang dari semua berkas masukan non-deklarasi. Jika composite disetel, bawaannya adalah direktori yang berisi berkas tsconfig.json.

Ketika TypeScript mengkompilasi berkas, ia mempertahankan struktur direktori yang sama pada direktori keluaran seperti struktur di direktori masukan.

Misalnya, Anda memiliki beberapa berkas masukan:

MyProj
├── tsconfig.json
├── core
│   ├── a.ts
│   ├── b.ts
│   ├── sub
│   │   ├── c.ts
├── types.d.ts

Kesimpulan untuk rootDir adalah jalur umum terpanjang dari semua berkas masukan non-deklarasi, yang dalam hal ini adalahcore/.

Jika nilai outDir anda adalah dist, maka TypeScript akan membuat struktur direktori seperti ini:

MyProj
├── dist
│   ├── a.ts
│   ├── b.ts
│   ├── sub
│   │   ├── c.ts

Namun, anda mungkin mengharapkan core menjadi bagian dari struktur direktori keluaran. Dengan menyetel rootDir: "." pada tsconfig.json, TypeScript akan menghasilkan struktur direktori seperti ini:

MyProj
├── dist
│   ├── core
│   │   ├── a.js
│   │   ├── b.js
│   │   ├── sub
│   │   │   ├── c.js

Yang terpenting, rootDir tidak memengaruhi berkas mana yang menjadi bagian dari kompilasi. rootDir tidak memiliki hubungan dengan pengaturan include, exclude, atau files pada tsconfig.json

Perhatikan bahwa TypeScript tidak akan pernah menulis berkas keluaran (file output) ke direktori di luar dari outDir, dan tidak akan pernah melewatkan pengeluaran berkas. Karena alasan ini, rootDir mengharuskan semua berkas yang perlu dikeluarkan berada dibawah jalur rootDir.

Misalnya, Anda memiliki struktur direktori seperti ini:

MyProj
├── tsconfig.json
├── core
│   ├── a.ts
│   ├── b.ts
├── helpers.ts

Ini akan menimbulkan galat ketika menentukan rootDir sebagai core dan include sebagai * karena ini membuat berkas (helpers.ts) yang perlu diletakkan di luar dari outDir (yaitu ../helpers.js)

Dengan menggunakan rootDirs, Anda dapat memberi tahu kompilator bahwa ada banyak direktori “virtual” yang bertindak sebagai salah satu akar (root). Hal ini memungkinkan kompilator untuk menyelesaikan impor pada modul relatif dalam direktori “virtual”, seolah-olah digabungkan menjadi satu direktori.

Sebagai contoh:

 src
 └── views
     └── view1.ts (bisa impor "./template1", "./view2`)
     └── view2.ts (bisa impor "./template1", "./view1`)
 generated
 └── templates
         └── views
             └── template1.ts (bisa impor "./view1", "./view2")

{
  "compilerOptions": {
    "rootDirs": ["src/views", "generated/templates/views"]
  }
}

Ini tidak memengaruhi bagaimana Typescript menghasilkan Javascript, ini hanya mengemulasi asumsi bahwa mereka akan mampu melakukan perkerjaan melalui Jalur relatif tersebut saat runtime.

By default all visible ”@types” packages are included in your compilation. Packages in node_modules/@types of any enclosing folder are considered visible. For example, that means packages within ./node_modules/@types/, ../node_modules/@types/, ../../node_modules/@types/, and so on.

If typeRoots is specified, only packages under typeRoots will be included. For example:

{
  "compilerOptions": {
    "typeRoots": ["./typings", "./vendor/types"]
  }
}

This config file will include all packages under ./typings and ./vendor/types, and no packages from ./node_modules/@types. All paths are relative to the tsconfig.json.

Secara default, semua visible package ”@types” diikutsertakan dalam kompilasi Anda. Package dalam node_modules/@types yang terletak dalam folder lain dianggap sebagai visible. Sebagai contoh, package yang berada di ./node_modules/@types/, ../node_modules/@types/, ../../node_modules/@types/, dan seterusnya dianggap sebagai visible.

Jika types telah ditentukan, hanya package yang didaftarkan yang akan disertakan pada lingkup global, misalnya:

{
  "compilerOptions": {
    "types": ["node", "jest", "express"]
  }
}

Berkas tsconfig.json ini hanya akan menyertakan ./node_modules/@types/node, ./node_modules/@types/jest dan ./node_modules/@types/express. Package lainnya di bawah direktori node_modules/@types/* tidak akan diikutsertakan.

Apa dampaknya?

Opsi ini tidak memengaruhi bagaimana @types/* diikutsertakan dalam kode aplikasi Anda, Sebagai contoh, apabila Anda memiliki compilerOptions seperti di pada contoh di atas dan kode seperti berikut:

ts
import * as moment from "moment";
moment().format("MMMM Do YYYY, h:mm:ss a");

Import moment akan sepenuhnya diketik.

Ketika Anda memiliki opsi ini pada pengaturan tanpa menyertakan sebuah modul dalam array types, maka:

• globals tidak akan ditambahkan ke dalam proyek Anda (contoh: process pada node atau expect pada Jest)
• Ekspor tidak akan muncul sebagai rekomendasi auto-import

Pengaturan pada fitur ini hanya tentang menentukan types yang ingin Anda sertakan, sedangkan typeRoots mendukung apabila Anda hanya menginginkan folder-folder tertentu saja.

Buat berkas .d.ts untuk setiap berkas TypeScript atau JavaScript di dalam proyek Anda. Berkas .d.ts ini adalah berkas definisi tipe yang menjelaskan API eksternal modul Anda. Dengan berkas .d.ts, alat seperti TypeScript dapat menyediakan tipe yang masuk akal di dalam sumber kode tanpa definisi tipe data.

Jika declaration disetel ketrue, jalankan compiler dengan kode TypeScript:

ts
export let helloWorld = "hi";Try

Akan menghasilkan berkas index.js seperti ini:

ts
export let helloWorld = "hi";
 Try

Dengan helloWorld.d.ts yang sesuai:

ts
export declare let helloWorld: string;
 Try

Saat bekerja dengan berkas .d.ts untuk file JavaScript, Anda mungkin ingin menggunakan emitDeclarationOnly atau menggunakan outDir untuk memastikan bahwa berkas JavaScript tidak ditimpa.

Menawarkan cara untuk mengonfigurasi direktori root tempat berkas deklarasi dihasilkan.

example
├── index.ts
├── package.json
└── tsconfig.json

dengan tsconfig.json;

{
  "compilerOptions": {
    "declaration": true,
    "declarationDir": "./types"
  }
}

Akan menempatkan d.ts untuk index.ts di direktori types:

example
├── index.js
├── index.ts
├── package.json
├── tsconfig.json
└── types
    └── index.d.ts

Menghasilkan peta sumber untuk berkas .d.ts yang mengarahkan kembali ke berkas sumber .ts asli. Ini akan memungkinkan editor seperti VS Code untuk pergi ke file .ts asli saat menggunakan fitur seperti Go to Definition.

Anda harus mempertimbangkan untuk mengaktifkan ini jika Anda menggunakan referensi proyek.

Downleveling adalah istilah TypeScript untuk mentranspilasi ke versi JavaScript yang lebih lama. Saran ini untuk mengaktifkan dukungan implementasi yang lebih akurat tentang bagaimana JavaScript modern melakukan iterasi melalui konsep baru di runtime JavaScript yang lebih lama.

ECMAScript 6 menambahkan beberapa iterasi primitif baru: loop for / of (for (el of arr)), Array spread ([a, ...b]), penyebaran argumen (fn(...args)), dan Symbol.iterator. --downlevelIteration memungkinkan iterasi primitif ini digunakan secara lebih akurat dalam lingkungan ES5 jika ada implementasi Symbol.iterator.

Contoh: Efek pada for / of

Tanpa downlevelIteration aktif, loop for / of pada objek apa pun diturunkan levelnya menjadi loop for tradisional:

ts
"use strict";
var str = "Hello!";
for (var _i = 0, str_1 = str; _i < str_1.length; _i++) {
    var s = str_1[_i];
    console.log(s);
}
 Try

Hal ini sering kali diharapkan orang, tetapi tidak 100% sesuai dengan perilaku ECMAScript 6. String tertentu, seperti emoji (😜), memiliki .length 2 (atau bahkan lebih!), Tetapi harus diiterasi sebagai 1 unit dalam loop for-of. Lihat postingan blog oleh Jonathan New untuk penjelasan yang lebih lengkap.

Jika downlevelIteration diaktifkan, TypeScript akan menggunakan fungsi bantuan yang memeriksa implementasi Symbol.iterator (baik native maupun polyfill). Jika implementasi ini hilang, Anda akan kembali ke iterasi berbasis indeks.

ts
"use strict";
var __values = (this && this.__values) || function(o) {
    var s = typeof Symbol === "function" && Symbol.iterator, m = s && o[s], i = 0;
    if (m) return m.call(o);
    if (o && typeof o.length === "number") return {
        next: function () {
            if (o && i >= o.length) o = void 0;
            return { value: o && o[i++], done: !o };
        }
    };
    throw new TypeError(s ? "Object is not iterable." : "Symbol.iterator is not defined.");
};
var e_1, _a;
var str = "Hello!";
try {
    for (var str_1 = __values(str), str_1_1 = str_1.next(); !str_1_1.done; str_1_1 = str_1.next()) {
        var s = str_1_1.value;
        console.log(s);
    }
}
catch (e_1_1) { e_1 = { error: e_1_1 }; }
finally {
    try {
        if (str_1_1 && !str_1_1.done && (_a = str_1.return)) _a.call(str_1);
    }
    finally { if (e_1) throw e_1.error; }
}
 Try

Catatan: memungkinkan downlevelIteration tidak meningkatkan kepatuhan jika Symbol.iterator tidak ada saat runtime.

Contoh: Efek pada Array Spreads

ini adalah array spread:

js
// Buat array baru yang elemennya 1 diikuti dengan elemen arr2
const arr = [1, ...arr2];

Berdasarkan uraian tersebut, sepertinya mudah untuk menurunkan ke ES5:

js
// Sama kan?
const arr = [1].concat(arr2);

Namun, ini sangat berbeda dalam kasus tertentu yang jarang terjadi. Misalnya, jika sebuah array memiliki “lubang” di dalamnya, indeks yang hilang akan membuat properti own jika disebarkan, tetapi tidak akan jika dibuat menggunakan concat:

js
// Buatlah array dimana elemen '1' hilang
let missing = [0, , 1];
let spreaded = [...missing];
let concated = [].concat(missing);
// benar
"1" in spreaded;
// salah
"1" in concated;

Seperti halnya dengan for / of, downlevelIteration akan menggunakan Symbol.iterator (jika ada) untuk meniru perilaku ES 6 dengan lebih akurat.

Mengontrol apakah TypeScript akan menghasilkan tanda urutan byte (byte order mark - BOM) saat menulis berkas output. Beberapa lingkungan runtime memerlukan BOM untuk menafsirkan berkas JavaScript dengan benar; yang lain mengharuskan itu tidak ada. Nilai bawaan dari false umumnya paling baik kecuali Anda memiliki alasan untuk mengubahnya.

Hanya menghasilkan berkas .d.ts; jangan mengirimkan berkas .js.

Pengaturan ini berguna dalam dua kasus:

• Anda menggunakan transpiler selain TypeScript untuk membuat JavaScript Anda.
• Anda menggunakan TypeScript hanya untuk menghasilkan berkas d.ts untuk konsumen Anda.

Untuk operasi penurunan tingkat tertentu, TypeScript menggunakan beberapa kode penunjang untuk operasi seperti memperluas kelas, himpunan(spread) susunan atau objek, dan menyambungkan operasi. Secara umum, penunjang ini dimasukkan ke dalam berkas yang menggunakannya. Ini dapat mengakibatkan duplikasi kode jika penunjang yang sama digunakan di banyak berkas yang berbeda.

Jika importHelpers kode ini aktif, fungsi penunjang ini diimpor dari tslib modul. Anda perlu memastikan bahwa berkas tslib modul dapat diimpor saat dijalankan. Ini hanya mempengaruhi modul, berkas kode tidak akan mencoba mengimpor modul.

Misalnya, dengan TypeScript:

ts
export function fn(arr: number[]) {
  const arr2 = [1, ...arr];
}

Memasang downlevelIteration dan importHelpers masih salah:

ts
var __read = (this && this.__read) || function (o, n) {
    var m = typeof Symbol === "function" && o[Symbol.iterator];
    if (!m) return o;
    var i = m.call(o), r, ar = [], e;
    try {
        while ((n === void 0 || n-- > 0) && !(r = i.next()).done) ar.push(r.value);
    }
    catch (error) { e = { error: error }; }
    finally {
        try {
            if (r && !r.done && (m = i["return"])) m.call(i);
        }
        finally { if (e) throw e.error; }
    }
    return ar;
};
var __spreadArray = (this && this.__spreadArray) || function (to, from, pack) {
    if (pack || arguments.length === 2) for (var i = 0, l = from.length, ar; i < l; i++) {
        if (ar || !(i in from)) {
            if (!ar) ar = Array.prototype.slice.call(from, 0, i);
            ar[i] = from[i];
        }
    }
    return to.concat(ar || Array.prototype.slice.call(from));
};
export function fn(arr) {
    var arr2 = __spreadArray([1], __read(arr), false);
}
 Try

Lalu aktifkan keduanya downlevelIteration dan importHelpers:

ts
import { __read, __spreadArray } from "tslib";
export function fn(arr) {
    var arr2 = __spreadArray([1], __read(arr), false);
}
 Try

Anda bisa menggunakan noEmitHelpers saat menyediakan implementasi untuk fungsi-fungsi ini.

Jika disetel, ketika menulis berkas .js.map untuk menyediakan peta sumber, TypeScript akan menyematkan konten peta sumber di berkas .js. Meskipun ini menghasilkan berkas JS yang lebih besar, tapi dapat memudahkan dalam beberapa tahap. Misalnya anda mungkin ingin mencoba berkas JS pada server web, tapi tidak mengizinkan berkas .map untuk ditampilkan.

Saling terpisah dengan sourceMap.

Misalnya, dengan TypeScript:

ts
const helloWorld = "hi";
console.log(helloWorld);

Di ubah menjadi JavaScript:

ts
"use strict";
const helloWorld = "hi";
console.log(helloWorld);
 Try

Kemudian aktifkan pembuatannya dengan inlineSourceMap, ada komentar di bagian bawah berkas yang menyertakan peta sumber untuk berkas tersebut.

ts
"use strict";
const helloWorld = "hi";
console.log(helloWorld);
//# sourceMappingURL=data:application/json;base64,eyJ2ZXJzaW9uIjozLCJmaWxlIjoiaW5kZXguanMiLCJzb3VyY2VSb290IjoiIiwic291cmNlcyI6WyJpbmRleC50cyJdLCJuYW1lcyI6W10sIm1hcHBpbmdzIjoiO0FBQUEsTUFBTSxVQUFVLEdBQUcsSUFBSSxDQUFDO0FBQ3hCLE9BQU8sQ0FBQyxHQUFHLENBQUMsVUFBVSxDQUFDLENBQUMifQ==Try

Jika dilihat, TypeScript akan menyertakan konten asli dari berkas .ts sebagai string yang disematkan di peta sumber. Ini sering kali berguna dalam kasus yang sama seperti inlineSourceMap.

Membutuhkan sourceMap atau inlineSourceMap untuk disetel.

Misalnya, dengan TypeScript:

ts
const helloWorld = "hi";
console.log(helloWorld);Try

Di ubah menjadi JavaScript:

ts
"use strict";
const helloWorld = "hi";
console.log(helloWorld);
 Try

Kemudian dengan inlineSources dan inlineSourceMap diaktifkan, ada komentar di bagian bawah berkas yang menyertakan peta sumber untuk berkas tersebut. Perhatikan bahwa ada yang berbeda di akhir [inlineSourceMap] (# inlineSourceMap) karena peta sumber sekarang berisi kode sumber asli.

ts
"use strict";
const helloWorld = "hi";
console.log(helloWorld);
//# sourceMappingURL=data:application/json;base64,eyJ2ZXJzaW9uIjozLCJmaWxlIjoiaW5kZXguanMiLCJzb3VyY2VSb290IjoiIiwic291cmNlcyI6WyJpbmRleC50cyJdLCJuYW1lcyI6W10sIm1hcHBpbmdzIjoiO0FBQUEsTUFBTSxVQUFVLEdBQUcsSUFBSSxDQUFDO0FBQ3hCLE9BQU8sQ0FBQyxHQUFHLENBQUMsVUFBVSxDQUFDLENBQUMiLCJzb3VyY2VzQ29udGVudCI6WyJjb25zdCBoZWxsb1dvcmxkID0gXCJoaVwiO1xuY29uc29sZS5sb2coaGVsbG9Xb3JsZCk7Il19Try

Specify the location where debugger should locate map files instead of generated locations. This string is treated verbatim inside the source-map, for example:

{
  "compilerOptions": {
    "sourceMap": true,
    "mapRoot": "https://my-website.com/debug/sourcemaps/"
  }
}

Would declare that index.js will have sourcemaps at https://my-website.com/debug/sourcemaps/index.js.map.

Specify the end of line sequence to be used when emitting files: ‘CRLF’ (dos) or ‘LF’ (unix).

Do not emit compiler output files like JavaScript source code, source-maps or declarations.

This makes room for another tool like Babel, or swc to handle converting the TypeScript file to a file which can run inside a JavaScript environment.

You can then use TypeScript as a tool for providing editor integration, and as a source code type-checker.

Instead of importing helpers with importHelpers, you can provide implementations in the global scope for the helpers you use and completely turn off emitting of helper functions.

For example, using this async function in ES5 requires a await-like function and generator-like function to run:

ts
const getAPI = async (url: string) => {
  // Get API
  return {};
};Try

Which creates quite a lot of JavaScript:

ts
"use strict";
var __awaiter = (this && this.__awaiter) || function (thisArg, _arguments, P, generator) {
    function adopt(value) { return value instanceof P ? value : new P(function (resolve) { resolve(value); }); }
    return new (P || (P = Promise))(function (resolve, reject) {
        function fulfilled(value) { try { step(generator.next(value)); } catch (e) { reject(e); } }
        function rejected(value) { try { step(generator["throw"](value)); } catch (e) { reject(e); } }
        function step(result) { result.done ? resolve(result.value) : adopt(result.value).then(fulfilled, rejected); }
        step((generator = generator.apply(thisArg, _arguments || [])).next());
    });
};
var __generator = (this && this.__generator) || function (thisArg, body) {
    var _ = { label: 0, sent: function() { if (t[0] & 1) throw t[1]; return t[1]; }, trys: [], ops: [] }, f, y, t, g = Object.create((typeof Iterator === "function" ? Iterator : Object).prototype);
    return g.next = verb(0), g["throw"] = verb(1), g["return"] = verb(2), typeof Symbol === "function" && (g[Symbol.iterator] = function() { return this; }), g;
    function verb(n) { return function (v) { return step([n, v]); }; }
    function step(op) {
        if (f) throw new TypeError("Generator is already executing.");
        while (g && (g = 0, op[0] && (_ = 0)), _) try {
            if (f = 1, y && (t = op[0] & 2 ? y["return"] : op[0] ? y["throw"] || ((t = y["return"]) && t.call(y), 0) : y.next) && !(t = t.call(y, op[1])).done) return t;
            if (y = 0, t) op = [op[0] & 2, t.value];
            switch (op[0]) {
                case 0: case 1: t = op; break;
                case 4: _.label++; return { value: op[1], done: false };
                case 5: _.label++; y = op[1]; op = [0]; continue;
                case 7: op = _.ops.pop(); _.trys.pop(); continue;
                default:
                    if (!(t = _.trys, t = t.length > 0 && t[t.length - 1]) && (op[0] === 6 || op[0] === 2)) { _ = 0; continue; }
                    if (op[0] === 3 && (!t || (op[1] > t[0] && op[1] < t[3]))) { _.label = op[1]; break; }
                    if (op[0] === 6 && _.label < t[1]) { _.label = t[1]; t = op; break; }
                    if (t && _.label < t[2]) { _.label = t[2]; _.ops.push(op); break; }
                    if (t[2]) _.ops.pop();
                    _.trys.pop(); continue;
            }
            op = body.call(thisArg, _);
        } catch (e) { op = [6, e]; y = 0; } finally { f = t = 0; }
        if (op[0] & 5) throw op[1]; return { value: op[0] ? op[1] : void 0, done: true };
    }
};
var getAPI = function (url) { return __awaiter(void 0, void 0, void 0, function () {
    return __generator(this, function (_a) {
        // Get API
        return [2 /*return*/, {}];
    });
}); };
 Try

Which can be switched out with your own globals via this flag:

ts
"use strict";
var getAPI = function (url) { return __awaiter(void 0, void 0, void 0, function () {
    return __generator(this, function (_a) {
        // Get API
        return [2 /*return*/, {}];
    });
}); };
 Try

Do not emit compiler output files like JavaScript source code, source-maps or declarations if any errors were reported.

This defaults to false, making it easier to work with TypeScript in a watch-like environment where you may want to see results of changes to your code in another environment before making sure all errors are resolved.

Jika ditentukan, berkas-berkas .js (maupun .d.ts, .js.map, dsb.) akan disertakan ke dalam direktori ini. Struktur direktori dari sumber awal berkas-berkas juga dipertahankan; lihat rootDir jika akar yang di perhitungkan bukan yang anda inginkan.

Jika tidak ditentukan, berkas-berkas .js akan disertakan di direktori yang sama dengan berkas-berkas .ts dari mana mereka di hasilkan:

sh
$ tsc
contoh
├── index.js
└── index.ts

Dengan suatu tsconfig.json seperti ini:

{
  "compilerOptions": {
    "outDir": "dist"
  }
}

Menjalankan tsc dengan pengaturan ini dapat memindahkan berkas-berkas ke direktori dist:

sh
$ tsc
contoh
├── dist
│   └── index.js
├── index.ts
└── tsconfig.json

Jika ditentukan, semua berkas global (non-module) akan digabung menjadi satu berkas keluaran tertentu.

Jika module adalah system atau amd, semua berkas modul juga akan digabungkan menjadi berkas ini setelah semua konten global.

Catatan: outFile tidak dapat digunakan kecuali module adalah None, System, atau AMD. Opsi ini tidak bisa digunakan untuk membundel modul CommonJS atau ES6.

Do not erase const enum declarations in generated code. const enums provide a way to reduce the overall memory footprint of your application at runtime by emitting the enum value instead of a reference.

For example with this TypeScript:

ts
const enum Album {
  JimmyEatWorldFutures = 1,
  TubRingZooHypothesis = 2,
  DogFashionDiscoAdultery = 3,
}
 
const selectedAlbum = Album.JimmyEatWorldFutures;
if (selectedAlbum === Album.JimmyEatWorldFutures) {
  console.log("That is a great choice.");
}Try

The default const enum behavior is to convert any Album.Something to the corresponding number literal, and to remove a reference to the enum from the JavaScript completely.

ts
"use strict";
const selectedAlbum = 1 /* Album.JimmyEatWorldFutures */;
if (selectedAlbum === 1 /* Album.JimmyEatWorldFutures */) {
    console.log("That is a great choice.");
}
 Try

With preserveConstEnums set to true, the enum exists at runtime and the numbers are still emitted.

ts
"use strict";
var Album;
(function (Album) {
    Album[Album["JimmyEatWorldFutures"] = 1] = "JimmyEatWorldFutures";
    Album[Album["TubRingZooHypothesis"] = 2] = "TubRingZooHypothesis";
    Album[Album["DogFashionDiscoAdultery"] = 3] = "DogFashionDiscoAdultery";
})(Album || (Album = {}));
const selectedAlbum = 1 /* Album.JimmyEatWorldFutures */;
if (selectedAlbum === 1 /* Album.JimmyEatWorldFutures */) {
    console.log("That is a great choice.");
}
 Try