Especifica uma lista de arquivos permitidos para incluir no programa. Um erro ocorre se qualquer um dos arquivos não puder ser encontrado.

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

Esta opção é útil quando você tem uma quantia pequena de arquivos e não precisa utilizar um glob para se referir a diversos arquivos. Se você precisa utilizar glob, então use include.

O valor de extends é uma string que contém o caminho para outro arquivo de configuração do qual ele herdará. O caminho pode usar o estilo de resolução do Node.Js

A configuração do aquivo base é carregada primeiro, e então sobrescrita por aquelas presentes no arquivo de configuração herdado. Todos os caminhos relativos encontrados no arquivo de configuração serão resolvidos relativamente ao arquivo de configuração em que estes se originaram.

Vale notar que files, include e exclude da configuração que está sendo estendida sobrescreve aquelas definidas na configuração base, e circularidade entre arquivos de configuração não é permitida.

Atualmente, a única propriedade de top-level que é excluída da herança é references.

Exemplo

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
  }
}

Propriedades com caminhos relativos encontrados no arquivo de configuração, e que não sejam excluídas da herança, serão resolvidos relativamente ao arquivo de configuração em que estas se originaram.

Especifica um array de nomes de arquivos ou padrões a serem incluídos no programa. Esses nomes de arquivo são resolvidos em relação ao diretório que contém o arquivo tsconfig.json.

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

Isso incluirá:

.
├── 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 e exclude suporta caracteres curinga para criar padrões globais:

• * corresponde a zero ou mais caracteres (excluindo separadores de diretório)
• ? corresponde a qualquer caractere (excluindo separadores de diretório)
• **/ corresponde a qualquer diretório aninhado a qualquer nível

Se um padrão global não incluir uma extensão de arquivo, apenas os arquivos com extensões compatíveis serão incluídos (por exemplo: .ts, .tsx, e .d.ts por padrão, com .js e .jsx se allowJs for definido como verdadeiro).

Especifica uma array de nomes de arquivos ou padrões que devem ser ignorando durante o include.

Importante: exclude altera apenas os arquivos que estão nos resultados da configuração include. Um arquivo marcado como exclude ainda pode fazer parte do seu código através de uma instrução import, uma inclusão de types, uma diretiva /// <reference ou sendo relacionado na lista de files.

Não é um mecanismo que impede um arquivo ser incluído no código base - apenas altera o que a configuração include pode selecionar.

As referências de projetos são uma forma de estruturar seus programas TypeScript em partes menores. Usar referências de projetos pode melhorar muito o tempo de construção e de interação com o editor, forçar uma separação lógica entre os elementos e organizar seu código de novas formas e métodos mais aprimorados.

Você pode ler mais sobre como as referências funcionam na seção Referências de Projetos.

Quando:

• undefined (padrão) dá sugestões como avisos para o editor
• true todo o código não executável é ignorado
• false exibe um erro de compilação quando código não executável é detectado

Mude para false para desabilitar os avisos sobre código não executável. Estes avisos são somente sobre código que são provavelmente inalcançáveis e nunca serão executados por conta do uso da sintaxe do JavaScript como, por exemplo:

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

Com "allowUnreachableCode": false:

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

Isso não afeta os erros exibidos com base em código que parece ser inalcançável devido à análise de tipos.

Defina como false para desabilitar os avisos sobre labels não utilizadas.

Labels são muito raras no JavaScript e, tipicamente, indicam uma tentativa de escrever um objeto literal:

ts
function verificarIdade(idade: number) {
  // Esquecemos o 'return'
  if (idade > 18) {
    verificado: true;
Unused label.7028Unused label.
  }
}Try

Garante que seus arquivos sejam analisados no modo estrito do ECMAScript e emitam “use strict” para cada arquivo fonte.

O modo estrito do ECMAScript foi introduzido no ES5 e fornece ajustes de comportamento para o runtime do engine JavaScript para melhorar o desempenho e faz um conjunto de erros serem lançados em vez de ignorá-los silenciosamente.

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

Reportar erros para casos de fallthrough em instruções switch. Garante que qualquer caso não vazio dentro de uma instrução switch inclua break oureturn. Isso significa que você não enviará acidentalmente um bug de fallthrough.

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

Em alguns casos, onde nenhuma anotação de tipo está presente, o TypeScript retornará o tipo any para uma variável, quando não puder inferir o tipo.

Isto pode fazer com que alguns erros sejam omitidos, por exemplo:

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

Ativando noImplicitAny no entanto, o TypeScript irá emitir um erro sempre que inferir any:

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

Quando habilitado, o TypeScript verificará todos os caminhos de código em uma função para garantir que eles retornem um valor.

ts
function procurarFabricanteDeFonesDeOuvido(cor: "azul" | "preto"): 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 (cor === "azul") {
    return "beats";
  } else {
    ("bose");
  }
}Try

Emite erro nas expressões ‘this’ com tipo ‘any’ implícito.

Por exemplo, a classe abaixo retorna uma função que tenta acessar this.largura e this.area – mas o contexto para this dentro da função dentro de funcaoObterArea não é a instância de Retangulo.

ts
class Retangulo {
  largura: number;
  altura: number;
 
  constructor(largura: number, altura: number) {
    this.largura = largura;
    this.altura = altura;
  }
 
  funcaoObterArea() {
    return function () {
      return this.largura * this.altura;
'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

Esta configuração garante a consistência entre acessar o campo pela sintaxe “ponto” (obj.chave), e “indexado” (obj["chave"]) e a forma que a propriedade é declarada no tipo.

Sem esta flag, o Typescript irá permitir que você use a sintaxe de ponto para acessar os campos que não estão definidos:

ts
interface ConfiguracoesDoJogo {
  // Propriedades diretamente conhecidas
  velocidade: "rápido" | "médio" | "lento";
  qualidade: "alta" | "baixa";
 
  // Assume qualquer coisa desconhecida para a interface
  // como um string.
  [chave: string]: string;
}
 
const configuracoes = obterConfiguracoes();
configuracoes.velocidade;
     
const configuracoes: ConfiguracoesDoJogo
configuracoes.qualidade;
     
const configuracoes: ConfiguracoesDoJogo
 
// Acessadores de chaves desconhecidas são permitidas
// neste projeto, e são do tipo `string`
configuracoes.nomeDeUsuario;
     
const configuracoes: ConfiguracoesDoJogoTry

Ativar esta flag irá gerar um erro porque o campo desconhecido usa a sintaxe ponto invés da sintaxe indexada.

ts
const configuracoes = obterConfiguracoes();
configuracoes.velocidade;
configuracoes.qualidade;
 
// Este precisa ser configuracoes["nomeDeUsuario"]
configuracoes.nomeDeUsuario;
Property 'nomeDeUsuario' comes from an index signature, so it must be accessed with ['nomeDeUsuario'].4111Property 'nomeDeUsuario' comes from an index signature, so it must be accessed with ['nomeDeUsuario'].
     
const configuracoes: ConfiguracoesDoJogoTry

O objetivo desta flag é para sinalizar a intenção em sua sintaxe de chamada sobre quão certo você está sobre a existência desta propriedade.

TypeScript tem uma maneira para descrever objetos que têm chaves desconhecidas, mas valores conhecidos, através da assinatura de índice.

ts
interface EnvironmentVars {
  NAME: string;
  OS: string;
 
  // Propriedades desconhecidas são cobertas por esta assinatura de índice.
  [propName: string]: string;
}
 
declare const env: EnvironmentVars;
 
// Declarada como existente
const sysName = env.NAME;
const os = env.OS;
      
const os: string
 
// Não declarada, mas por causa da assinatura
// de índice, é considerada uma string
const nodeEnd = env.NODE_ENV;
        
const nodeEnd: stringTry

Ativar noUncheckedIndexedAccess adicionará undefined para qualquer campo não declarado no tipo.

ts
declare const env: EnvironmentVars;
 
// Declarada como existente
const sysName = env.NAME;
const os = env.OS;
      
const os: string
 
// Não declarada, mas por causa da assinatura
// de índice, é considerada uma string
const nodeEnd = env.NODE_ENV;
        
const nodeEnd: string | undefinedTry

Reporta erros em variáveis locais não utilizadas.

ts
const criaTeclado = (modeloID: number) => {
  const modeloPadraoID = 23;
'modeloPadraoID' is declared but its value is never read.6133'modeloPadraoID' is declared but its value is never read.
  return { tipo: "teclado", modeloID };
};Try

Reporta erros em parâmetros não utilizados em funções.

ts
const criaTecladoPadrao = (modeloID: number) => {
'modeloID' is declared but its value is never read.6133'modeloID' is declared but its value is never read.
  const modeloPadraoID = 23;
  return { tipo: "teclado", modeloID: modeloPadraoID };
};Try

A opção strict permite uma ampla gama de comportamento de verificação de tipo que resulta em melhores garantias de correção do programa. Ativar isso equivale a ativar todas as opções da família do modo restrito, que são descritas abaixo. Você pode desativar as verificações de família de modo restrito individualmente conforme necessário.

Versões futuras do TypeScript podem introduzir verificação rigorosas adicionais dentro desta opção, portanto, as atualizações do TypeScript podem resultar em novos erros de tipo em seu programa. Quando apropriado e possível, uma opção correspondente será adicionado para desativar esse comportamento.

Quando definido, o TypeScript verificará se os métodos integrados das funções call, bind e apply são invocados com os argumentos corretos para a função subjacente:

ts
// Com strictBindCallApply ativado
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

Caso contrário, essas funções aceitarão qualquer argumento e retornarão any:

ts
// Com strictBindCallApply desativado
function fn(x: string) {
  return parseInt(x);
}
 
// Nota: Sem erro; tipo do retorno é 'any'
const n = fn.call(undefined, false);Try

Quando ativado, esta opção faz com que os parâmetros das funções sejam verificados mais corretamente.

Aqui está um exemplo básico com strictFunctionTypes desativado:

ts
function fn(x: string) {
  console.log("Hello, " + x.toLowerCase());
}
 
type StringOrNumberFunc = (ns: string | number) => void;
 
// Atribuição não segura
let func: StringOrNumberFunc = fn;
// Chamada não segura - vai quebrar
func(10);Try

Com strictFunctionTypes ativado, o erro é detectado corretamente:

ts
function fn(x: string) {
  console.log("Olá, " + x.toLowerCase());
}
 
type StringOuNumeroFn = (ns: string | number) => void;
 
// Atribuição não segura é prevenida
let func: StringOuNumeroFn = fn;
Type '(x: string) => void' is not assignable to type 'StringOuNumeroFn'.
  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 'StringOuNumeroFn'.
  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

Durante o desenvolvimento desse recurso, descobrimos um grande número de hierarquias de classes profundamente não seguras, incluindo algumas no DOM. Por causa disso, a configuração apenas se aplica a funções escritas na sintaxe function, não àquelas na sintaxe method:

ts
type PareceUmMetodo = {
  func(x: string | number): void;
};
 
function fn(x: string) {
  console.log("Olá, " + x.toLowerCase());
}
 
// Por fim, uma atribuição insegura, porém não detectada.
const m: PareceUmMetodo = {
  func: fn,
};
m.func(10);Try

Quando strictNullChecks é false, null e undefined são efetivamentes ignorados pela linguagem. Isso pode levar a erros inesperados em tempo de execução.

Quando strictNullChecks é true, null e undefined têm seus próprios tipos distintos e você obterá um erro de tipo se tentar usá-los onde um valor concreto é esperado.

Por exemplo, com este código TypeScript, usuarios.find você não tem garantia de que realmente encontrará um usuário, mas você pode escrever o código como se ele fosse:

ts
declare const nomeDeUsuarioLogado: string;
 
const usuarios = [
  { nome: "Henrique", idade: 12 },
  { nome: "Carol", idade: 32 },
];
 
const usuarioLogado = usuarios.find((u) => u.nome === nomeDeUsuarioLogado);
console.log(usuarioLogado.idade);Try

Configurar strictNullChecks para true irá gerar um erro de que você não garantiu a existência de usuarioLogado antes de tentar usá-lo.

ts
declare const nomeDeUsuarioLogado: string;
 
const usuarios = [
  { nome: "Henrique", idade: 12 },
  { nome: "Carol", idade: 32 },
];
 
const usuarioLogado = usuarios.find((u) => u.nome === nomeDeUsuarioLogado);
console.log(usuarioLogado.idade);
'usuarioLogado' is possibly 'undefined'.18048'usuarioLogado' is possibly 'undefined'.Try

O segundo exemplo falhou porque a função find do array se parece um pouco com esta simplificação:

ts
// Quando strictNullChecks: true
type Array = {
  find(predicate: (value: any, index: number) => boolean): S | undefined;
};
// Quando strictNullChecks: false, o undefined é removido do sistema de tipos,
// permitindo que você escreva um código que assume que sempre encontrou um resultado
type Array = {
  find(predicate: (value: any, index: number) => boolean): S;
};

Quando definido como true, o TypeScript gerará um erro quando uma propriedade de classe for declarada, mas não definida no construtor.

ts
class Conta {
  nome: string;
  tipo = "usuario";
 
  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.
  endereco: string | undefined;
 
  constructor(nome: string) {
    this.nome = nome;
    // Note que this.email não foi atribuído
  }
}Try

No caso acima:

• this.nome é atribuído especificamente.
• this.tipo é atribuído por padrão.
• this.email não é atribuído e gera um erro.
• this.endereco é declarado como possível undefined, o que significa que não precisa ser atribuído.

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.

Quando setado para true, a flag allowUmdGlobalAccess deixa que você acesse todos os exports UMD como globais de dentro dos arquivos de módulo. Um arquivo de módulo é um arquivo que tem imports e/ou exports. Sem essa configuração, usando um export de dentro de um módulo UMD vai pedir uma declaração de import.

Um caso de exemplo para essa flag seria um projeto web onde você sabe que uma biblioteca em particular (como o jQuery ou Lodash) vai estar sempre disponível em runtime, mas você não pode acessá-la com um import.

Permite definir um diretório base para resolver nomes de módulo não absolutos.

Você pode definir uma pasta raiz na qual pode fazer a resolução absoluta do arquivo. Por exemplo.

URLBase
├── ex.ts
├── ola
│   └── mundo.ts
└── tsconfig.json

Com "baseUrl": "./" no projeto, o TypeScript vai procurar por arquivos começando na mesma pasta do tsconfig.json.

ts
import { olaMundo } from "ola/mundo";
console.log(olaMundo);

Se você estiver cansado de importações sempre parecidas com "../" ou "./", ou precisando alterá-las à medida que move arquivos, essa é uma ótima maneira de simplificar isso.

--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.

Define o sistema de módulo para o programa. Consulte o capítulo Módulos do manual para obter mais informações. Você provavelmente deseja "CommonJS".

Aqui está um exemplo de saída para este arquivo:

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

CommonJS

ts
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

ES2020

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

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

Especifica a estratégia de resolução de módulos: node (Node.js) ou classic (utilizada no TypeScript antes da versão 1.6). Você provavelmente não vai precisar utilizar classic em código mais recente.

Veja a página de referência em: Resolução de Módulos

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.

Por padrão, o TypeScript examinará o conjunto inicial de arquivos para as diretivas import e<reference e adicionará esses arquivos resolvidos ao seu programa.

Se noResolve estiver definido, este processo não acontecerá. No entanto, as instruções import ainda são verificadas para ver se elas resolvem para um módulo válido, então você precisa ter certeza de que isso é satisfeito por algum outro meio.

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.

Uma série de entradas que remapeiam as importações para locais de pesquisa relativos à baseUrl, há uma cobertura mais abrangente de paths no manual.

paths permite que você declare como o TypeScript deve resolver importações nos seus requires e imports.

{
  "compilerOptions": {
    "baseUrl": ".", // isto deve ser especificado se "paths" está especificado.
    "paths": {
      "jquery": ["node_modules/jquery/dist/jquery"] // este mapeamento é relativo à "baseUrl"
    }
  }
}

Isto permitiria que você escreva import "jquery", e obtenha toda a digitação correta localmente.

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

Neste caso, você pode infomar o resolvedor de arquivos do TypeScript para dar suporte à vários prefixos personalizados para encontrar código. Este padrão pode ser usado para evitar caminhos relativos longos no seu código base.

Permite importar módulos com um uma extensão ‘.json’, que é uma prática comum em projetos node. Isso inclui gerar um arquivo import baseado na forma estática do JSON.

O TypeScript não suporta a resolução de arquivos JSON por padrão:

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

Ativar essa opção permite importar JSON e validar os tipos nesse arquivo JSON.

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.

Padrão: O caminho mais longo em comum entre todos os arquivos que não são de declaração. Se composite está definido, o padrão será o diretório contendo o arquivo tsconfig.json.

Quando TypeScript compila os arquivos, ele mantém a estrutura dos diretório de saída igual a dos diretório de entrada.

Por exemplo, suponhamos que você tenha alguns arquivos de entrada:

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

O valor inferido para rootDir é o caminho mais longo em comum entre todos os arquivos que não são de declaração, que neste caso é core/.

Se o seu outDir fosse dist, TypeScript escreveria esta árvore:

MeuProj
├── dist
│   ├── a.js
│   ├── b.js
│   ├── sub
│   │   ├── c.js

Contudo, você pode ter a intenção de que core seja parte da estrutura do diretório de saída. Ao definir rootDir: "." em tsconfig.json, TypeScript escreveria esta árvore:

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

Importante, a opção rootDir não altera quais arquivos se tornam parte da compilação, pois não há interação com include, exclude, ou com a propriedade files em tsconfig.json.

Note que TypeScript nunca irá escrever um arquivo de saída em um diretório fora de outDir, e nunca irá pular a emissão de um arquivo. Por este motivo, rootDir também impõe que todos arquivos que precisam ser emitidos estejam abaixo do caminho rootDir.

Por exemplo, digamos que você tivesse esta árvore:

MeuProj
├── tsconfig.json
├── core
│   ├── a.ts
│   ├── b.ts
├── ajudantes.ts

Seria um erro especificar rootDir como core e include como *, porque estaria sendo criado um arquivo (ajudantes.ts) que precisaria ser emitido fora do outDir (i.e. ../ajudantes.js).

Usando rootDirs, você pode informar ao compilador que existem vários diretórios raiz agindo como um único diretório raiz “virtual”. Isso faz com que o compilador resolva importações relativas de módulos como se estes diretórios fossem um único diretório raiz.

Por exemplo:

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

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

Esta propriedade não altera como TypeScript emite JavaScript, mas apenas emula a suposição de que os arquivos JavaScript poderão trabalhar através desses caminhos relativos em tempo de execução.

Por padrão todos pacotes @types visíveis são incluídos na sua compilação. Pacotes em node_modules/@types de qualquer diretório adjacente são considerados visíveis. Por exemplo, isso significa pacotes dentro de ./node_modules/@types/, ../node_modules/@types/, ../../node_modules/@types/, e assim por diante.

Se typeRoots está especificado, somente pacotes dentro de typeRoots serão incluídos. Por exemplo:

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

Este arquivo de configuração vai incluir todos os pacotes definidos em ./typings e ./vendor/types , e nenhum pacote de ./node_modules/@types. Todo os caminhos são relativos ao arquivo tsconfig.json.

Por padrão todos pacotes @types visíveis são incluídos na sua compilação. Pacotes em node_modules/@types de qualquer diretório adjacente são considerados visíveis. Por exemplo, isso significa pacotes dentro de ./node_modules/@types/, ../node_modules/@types/, ../../node_modules/@types/, e assim por diante.

Se types está especificado, somente pacotes listados serão incluídos no escopo global. Por exemplo:

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

Este arquivo tsconfig.json somente irá incluir ./node_modules/@types/node, ./node_modules/@types/jest e ./node_modules/@types/express. Outros pacotes dentro de node_modules/@types/* não serão incluídos.

O que isto reflete?

Esta opção não altera como @types/* são incluídos no código da sua aplicação, por exemplo se você tivesse o compilerOptions acima, com o seguinte código:

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

O import moment estaria completamente tipado.

Quando você tem esta opção definida, ao não incluir um módulo no vetor de types, ela:

• Não vai adicionar globais ao seu projeto (p. ex. process no node, ou expect no Jest)
• Não vai fazer com que exports apareçam como recomendações de auto-import

Esta opção difere de typeRoots, pois serve para especificar somente os tipos exatos a serem incluídos, enquanto typeRoots permite que você defina diretórios específicos.

Gere arquivos .d.ts para cada arquivo TypeScript ou JavaScript dentro do seu projeto. Esses arquivos .d.ts são arquivos de definição de tipo que descrevem a API externa do seu módulo. Com arquivos .d.ts, ferramentas como o TypeScript podem fornecer intellisense e tipos mais precisos para código que ainda não foi digitado.

Quando a opção declaration é definida como true, executando o compilador com este código TypeScript:

ts
export let olaMundo = "olá!";Try

Vai gerar um arquivo index como este:

ts
export let olaMundo = "olá!";
 Try

Com um outro arquivo correspondente olaMundo.d.ts:

ts
export declare let olaMundo: string;
 Try

Ao trabalhar com arquivos .d.ts para arquivos JavaScript, você pode usar emitDeclarationOnly ou usar outDir para garantir que os arquivos JavaScript não sejam sobrescritos.

Oferece uma maneira de configurar o diretório raiz para onde os arquivos de declaração são emitidos.

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

com este tsconfig.json:

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

Colocaria o d.ts para o index.ts em uma pastatipos:

exemplo
├── index.js
├── index.ts
├── package.json
├── tsconfig.json
└── tipos
    └── index.d.ts

Gera um sourcemap para arquivos .d.ts, que são mapeados de volta para o arquivo original .ts. Isso permitirá que editores como o VS Code acessem o arquivo .ts original ao usar recursos como Ir para definição.

Você deve fortemente considerar ativar essa opção se estiver usando referências de projeto.

Downleveling é o termo do TypeScript para transpilar para uma versão mais antiga do JavaScript. Esse sinalizador permite que, em runtimes mais antigos do JavaScript, haja o suporte a uma implementação mais precisa de como o JavaScript moderno interage com novos conceitos.

O ECMAScript 6 adicionou várias novas primitivas de iteração: o loop for / of (for (el of arr)), operador de spread ([a, ...b]), spread de argumento (fn (... args)) e o Symbol.iterator. --downlevelIteration permite que essas primitivas de iteração sejam usadas com mais precisão nos ambientes ES5 se uma implementação do Symbol.iterator estiver presente.

Exemplo: Efeitos no for / of

Sem a flag downlevelIteration ativa, um loop for / of em qualquer objeto sofre um downlevel para um loop for tradicional:

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

Isso geralmente é o que as pessoas esperam, mas não é 100% compatível com o comportamento do ECMAScript 6. Certas strings, como emoji (😜), têm um .length de 2 (ou até mais!), Mas devem iterar como 1 unidade em um loop for-of. Consulte esta postagem no blog de Jonathan New para obter uma explicação mais detalhada.

Quando o downlevelIteration estiver ativado, o TypeScript usará uma função auxiliar que verifica a implementação do Symbol.iterator (nativo ou polyfill). Se essa implementação estiver ausente, ela retornará à iteração baseada em índice.

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 = "Olá!";
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

Nota: ativar o downlevelIteration não melhora a compatibilidade se o Symbol.iterator não estiver presente no runtime.

Exemplo: Efeitos em Spreads de Arrays

Isso é um operador spread em um array:

js
// Cria um novo array onde os elementos são: 1 seguido por todos os elementos do arr2
const arr = [1, ...arr2];

Baseado nas descrições, parece fácil fazer um downlevel para ES6:

js
// Mesma coisa, certo?
const arr = [1].concat(arr2);

No entanto, isso é claramente diferente em certos casos bem raros. Por exemplo, se o array tiver um “buraco” no meio, o índice faltante vai criar uma propriedade própria quando sofrer o spread, mas isso não acontece quando usamos concat:

js
// Fazemos um array onde temos o elemento do índice '1' faltando
let faltando = [0, , 1];
let spread = [...faltando];
let concatenado = [].concat(faltando);
// true
"1" in spread;
// false
"1" in concatenado;

Assim como for / of, downlevelIteration vai usar o Symbol.iterator (se presente) para emular de forma mais precisa o comportamento do ES 6.

Controla se o TypeScript emitirá uma BOM (byte order mark) ao gravar arquivos de saída. Alguns runtimes exigem uma BOM para interpretar corretamente os arquivos JavaScript; outros exigem que ele não esteja presente. O valor padrão de false é geralmente melhor, a menos que você tenha um motivo para alterá-lo.

Só emite arquivos .d.ts; não emite arquivos .js.

Essa configuração é útil em dois casos:

• Você está usando um transpilador diferente do TypeScript para gerar seu JavaScript.
• Você está usando o TypeScript para gerar apenas arquivos d.ts para seus consumidores.

Para algumas operações de mais baixo nível, o TypeScript pode usar alguns códigos auxiliares para operações como extensão de classes, fazer spread de arrays ou objetos e para operações async. Por padrão esses auxiliares são inseridos em cada arquivo utilizado. Isso pode provocar duplicação de códigos se o mesmo auxiliar for usado em diferentes módulos.

Se importHelpers estiver ligado, as funções auxiliares serão importadas do módulo tslib. Você precisa ter certeza que o módulo tslib pode ser importado no runtime. Isso afeta apenas módulos; Os arquivos de scripts globais não tentarão importar módulos.

Exemplo com esse TypeScript:

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

Ligando downlevelIteration e mantendo o importHelpers como falso:

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

Em seguida, ativando downlevelIteration e importHelpers:

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

Você pode utilizar noEmitHelpers quando fornecer suas próprias implementações dessas funções.

Quando definido, em vez de escrever um arquivo .js.map para fornecer mapas de origem, o TypeScript irá embutir o conteúdo do mapa de origem nos arquivos.js. Embora isso resulte em arquivos JS maiores, pode ser conveniente em alguns cenários. Por exemplo, você pode querer depurar arquivos JS em um servidor web que não permite que arquivos .map sejam servidos.

Mutuamente exclusivo com sourceMap.

Por exemplo, com este TypeScript:

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

Converte para este JavaScript:

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

Em seguida, habilite a construção com inlineSourceMap habilitado, há um comentário na parte inferior do arquivo que inclui um mapa de origem para o arquivo.

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

Quando definido o TypeScript incluirá o conteúdo original do arquivo .ts como uma string incorporada no mapa de origem. Isso geralmente é util nos mesmos casos que inlineSourceMap.

Requer sourceMap ou inlineSourceMap para ser definido.

Por exemplo, com este TypeScript:

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

Por padrão, converte para este JavaScript:

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

Em seguida, habilite a compilação com inlineSources e inlineSourceMap habilitados, há um comentário na parte inferior do arquivo que inclui um mapa de origem para o arquivo. Observe que o final é diferente do exemplo em inlineSourceMap porque o mapa-fonte agora contém o código-fonte original também.

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

Especifique o local onde o depurador deve localizar os arquivos de mapa em vez dos locais gerados. Esta string é tratada literalmente dentro do source-map, por exemplo:

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

Declararia que index.js terá mapas de origem em https://my-website.com/debug/sourcemaps/index.js.map.

Especifique a sequência de fim de linha a ser usada ao emitir arquivos: ‘CRLF’ (dos) ou ‘LF’ (unix).

Não emita arquivos de saída do compilador como código-fonte JavaScript, source-maps ou declarações.

Isso abre espaço para outra ferramenta como Babel ou swc para lidar com a conversão do arquivo TypeScript em um arquivo que pode ser executado dentro de um ambiente JavaScript.

Você pode então usar o TypeScript como uma ferramenta para fornecer integração com o editor e como um verificador de tipo de código-fonte.

Em vez de importar auxiliares com importHelpers, você pode fornecer implementações no escopo global para os auxiliares que você usa e desligar completamente a emissão de funções auxiliares.

Por exemplo, usar esta função async no ES5 requer uma função do tipo await e uma função do tipo generator para executar:

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

O que cria bastante 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

Que pode ser alternado com seus próprios globais por meio deste sinalizador:

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

Não emita arquivos de saída do compilador como código JavaScript, source-maps ou declarações se algum erro for relatado.

O padrão é false, tornando mais fácil trabalhar com o TypeScript em um ambiente semelhante a um relógio, onde você pode ver os resultados das alterações em seu código em outro ambiente antes de garantir que todos os erros sejam resolvidos.

Se especificado, os arquivos .js (como o .d.ts, e .js.map, etc.) serão emitidos para este diretório. A estrutura de diretório dos arquivos de origem originais é preservada; consulte rootDir se a raiz calculada não for o que você pretendia.

Se não for especificado, os arquivos .js serão emitidos no mesmo diretório que os arquivos .ts de onde foram gerados:

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

Com um tsconfig.json como este:

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

Executar tsc com essas configurações move os arquivos para a pasta dist especificada:

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

Se especificado, todos os arquivos global (não módulos) serão concatenados no único arquivo de saída especificado.

Se module for system ou amd, todos os arquivos do módulo também serão concatenados neste arquivo após todo o conteúdo global.

Nota: outFile não pode ser usado a menos que module seja None, System, ou AMD. Esta opção não pode pode ser usada para agrupar módulos CommonJS ou ES6.

Não apaga as declarações const enum em seu código gerado. const enum provê uma maneira de reduzir a quantidade de memória utilizada por sua aplicação em tempo de execução emitindo o valor do enum ao invés de sua referência.

Por exemplo nesse código TypeScript:

ts
const enum Album {
  JimmyEatWorldFutures = 1,
  TubRingZooHypothesis = 2,
  DogFashionDiscoAdultery = 3,
}
 
const albumSelecionado = Album.JimmyEatWorldFutures;
if (albumSelecionado === Album.JimmyEatWorldFutures) {
  console.log("Excelente escolha.");
}Try

O comportamento padrão const enum é converter qualquer Album.AlgumaCoisa para o literal correspondente, além de remover a referência do enum do JavaScript completamente.

ts
"use strict";
const albumSelecionado = 1 /* Album.JimmyEatWorldFutures */;
if (albumSelecionado === 1 /* Album.JimmyEatWorldFutures */) {
    console.log("Excelente escolha.");
}
 Try

Com a opção preserveConstEnums definida como true, o enum existe em tempo de execução e os números ainda são emitidos.

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 albumSelecionado = 1 /* Album.JimmyEatWorldFutures */;
if (albumSelecionado === 1 /* Album.JimmyEatWorldFutures */) {
    console.log("Excelente escolha.");
}
 Try

Isso essencialmente faz com que const enums seja uma funcionalidade apenas do código-fonte.

Remove todos os comentários do TypeScript ao converter para JavaScript. O padrão é false.

Por exemplo, esse documento TypeScript que tem um comentário JSDoc:

ts
/** Tradução de 'Hello World' para português. */
export const helloWorldPTBR = "Olá Mundo";

Quando removeComments é definido para true:

ts
export const helloWorldPTBR = "Olá Mundo";
 Try

Sem a opção removeComments ou com ela definida para false:

ts
/** Tradução de 'Hello World' para português. */
export const helloWorldPTBR = "Olá Mundo";
 Try

Isso significa que seu comentário vai aparecer no código JavaScript.

Permite a geração de mapas de código. Esses arquivos permitem que depuradores e outras ferramentas exibam o código fonte TypeScript original ao trabalhar com os arquivos JavaScript emitidos. Mapas de código são emitidos como arquivos js.map (ou jsx.map) ao lado dos arquivos de saída .js correspondentes.

Os arquivos .js recebem um container com comentários do mapa de código, indicando para as ferramentas externas onde os arquivos estão. Por exemplo:

ts
// helloWorld.ts
export declare const helloWorld = "Olá";

Compilando com o sourceMap configurado como true, a criação do arquivo JavaScript seguirá assim:

js
// helloWorld.js
"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.helloWorld = "Olá";
//# sourceMappingURL=// helloWorld.js.map

E isso irá gerar o seguinte arquivo json do mapa:

json
// helloWorld.js.map
{
  "version": 3,
  "file": "ex.js",
  "sourceRoot": "",
  "sources": ["../ex.ts"],
  "names": [],
  "mappings": ";;AAAa,QAAA,UAAU,GAAG,IAAI,CAAA"
}