Compiler Options

"compilerOptions"

JavaScript Support
  1. allowJs,
  2. checkJs and
  3. maxNodeModuleJsDepth
Editor Support
  1. disableSizeLimit and
  2. plugins
Linha de comando

    Root Fields

    Starting up are the root options in the TSConfig - these options relate to how your TypeScript or JavaScript project is set up.

    # Arquivos - files

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

    {
    "": [
    "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.

    # Estender - extends

    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:

    tsconfig.json:

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

    tsconfig.nostrictnull.json:

    {
    "": "./tsconfig",
    }
    }

    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.

    • Default:

      false

    • Released:

      2.1

    # Incluir - include

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

    # Excluir - exclude

    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.

    # Referências - references

    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.

    • Default:

      false

    Opções do compilador

    Essas são a maioria das opções do TypeScript e descrevem como o compilador deve funcionar.

    #Type Checking

    # Permitir Código Não Executado - allowUnreachableCode

    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.

    • Default:

      undefined

    • Released:

      1.8

    # Permitir Labels Não Utilizadas - allowUnusedLabels

    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
    • Default:

      undefined

    • Released:

      1.8

    # Sempre Estrito - alwaysStrict

    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.

    • Recommended
    • Default:
      • true if strict,

      • false otherwise.

    • Related:
    • Released:

      2.1

    # exactOptionalPropertyTypes - exactOptionalPropertyTypes

    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
    • Recommended
    • Released:

      4.4

    # Sem casos de Fallthrough no Switch - noFallthroughCasesInSwitch

    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

    # Sem 'Any' Implícito - noImplicitAny

    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
    • Recommended
    • Default:
      • true if strict,

      • false otherwise.

    • Related:

    # noImplicitOverride - noImplicitOverride

    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

    # Sem Retornos Implícitos - noImplicitReturns

    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
    • Default:

      false

    • Released:

      1.8

    # Sem 'This' Implícito - noImplicitThis

    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
    • Recommended
    • Default:
      • true if strict,

      • false otherwise.

    • Related:
    • Released:

      2.0

    # Sem acesso a propriedade pela assinatura do índice - noPropertyAccessFromIndexSignature

    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: ConfiguracoesDoJogo
    Try

    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: ConfiguracoesDoJogo
    Try

    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.

    • Default:

      false

    • Released:

      4.2

    # noUncheckedIndexedAccess - noUncheckedIndexedAccess

    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: string
    Try

    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 | undefined
    Try

    # Sem Variáveis Locais Não Utilizadas - noUnusedLocals

    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
    • Default:

      false

    • Released:

      2.0

    # Sem Parâmetros Não Utilizados - noUnusedParameters

    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
    • Default:

      false

    • Released:

      2.0

    # Modo estrito - strict

    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.

    # Bind Call Apply Restritos - strictBindCallApply

    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
    • Recommended
    • Default:
      • true if strict,

      • false otherwise.

    • Related:
    • Released:

      3.2

    # Tipo de Funções Restritos - strictFunctionTypes

    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
    • Recommended
    • Default:
      • true if strict,

      • false otherwise.

    • Related:
    • Released:

      2.6

    # Checagem estrita de nulos - strictNullChecks

    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);
    Object is possibly 'undefined'.2532Object 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;
    };
    • Recommended
    • Default:
      • true if strict,

      • false otherwise.

    • Related:
    • Released:

      2.0

    # Inicialização restrita de propriedade - strictPropertyInitialization

    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.
    • Recommended
    • Default:
      • true if strict,

      • false otherwise.

    • Related:
    • Released:

      2.7

    # useUnknownInCatchVariables - useUnknownInCatchVariables

    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) {
    // 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.

    #Modules

    # Permitir Acesso Global UMD - allowUmdGlobalAccess

    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.

    • Default:

      false

    • Released:

      3.5

    # URL Base - baseUrl

    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.

      # Módulo - module

      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
      • Default:
        • CommonJS if target is ES3 or ES5,

        • ES6/ES2015 otherwise.

      • Allowed:
        • none

        • commonjs

        • amd

        • umd

        • system

        • es6/es2015

        • es2020

        • es2022

        • esnext

        • node12

        • nodenext

      • Related:
      • Released:

        1.0

      # Resolução de Módulos - moduleResolution

      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

      • Default:
        • Classic if module is AMD, UMD, System or ES6/ES2015,

        • Matches if module is node12 or nodenext,

        • Node otherwise.

      • Allowed:
        • classic

        • node

      • Related:

      # Sem Resolução - noResolve

      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.

      • Default:

        false

      # Caminhos - paths

      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.

      {
      "": ".", // isto deve ser especificado se "paths" está especificado.
      "": {
      "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.

      {
      "": "src",
      "": {
      "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.

        # Resolução de módulo JSON - resolveJsonModule

        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
        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.
        {
        "repo": "TypeScript",
        "dry": false,
        "debug": false
        }
        // @filename: index.ts
        import settings from "./settings.json";
         
        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,
        This condition will always return 'false' since the types 'boolean' and 'number' have no overlap.2367This condition will always return 'false' since the types 'boolean' and 'number' have no overlap.
        "debug": false
        }
        // @filename: index.ts
        import settings from "./settings.json";
         
        settings.debug === true;
        settings.dry === 2;
        Try
        • Default:

          false

        # Diretório Raiz - rootDir

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

        • Default:

          Computed from the list of input files.

        • Released:

          1.5

        # Diretórios Raiz - rootDirs

        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")
        {
        "": ["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.

        • Default:

          Computed from the list of input files.

        • Released:

          2.0

        # Raizes de Tipo - typeRoots

        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:

        {
        "": ["./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.

        # Tipos - types

        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:

        {
        "": ["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.

        #Emit

        # Declarações - declaration

        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.

        # Diretório de declarações - declarationDir

        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:

        {
        "": true,
        "": "./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

        # Mapa de declarações - declarationMap

        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.

        • Default:

          false

        • Released:

          2.9

        # Iteração Downlevel - downlevelIteration

        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.

        # Emitir BOM - emitBOM

        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.

        • Default:

          false

        # Emitir Somente Declarações - emitDeclarationOnly

        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.

        # Importar Auxiliares - importHelpers

        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.

        # Importações não utilizadas como valores - importsNotUsedAsValues

        Essa opção controla como o import funciona, são 3 opções diferentes:

        • remove: O comportamento padrão para descartar os import que apenas referenciam tipos.

        • preserve: Preserva todas as declarações import que os valores ou tipos nunca são usados. Isso pode permitir que importações/efeitos colaterais sejam mantidos.

        • error: Isso mantém todas as importações (as mesmas que a opção de preservar), mas apresentará um erro quando o valor da importação usada for apenas como tipo. Isto pode ser útil se você quiser garantir que nenhum valor vai ser acidentalmente importado, mas ainda vai manter os efeitos colaterais da importação explícitos.

        Essa opção funciona porque você pode usar import type para criar explicitamente uma regra import que nunca seja emitida em Javascript.

        • Allowed:
          • remove

          • preserve

          • error

        • Released:

          3.8

        # Mapa de origem embutido - inlineSourceMap

        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
        • Default:

          false

        • Released:

          1.5

        # Origens Embutidas - inlineSources

        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 ouinlineSourceMap 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 einlineSourceMap 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,eyJ2ZXJzaW9uIjozLCJmaWxlIjoiaW5kZXguanMiLCJzb3VyY2VSb290IjoiIiwic291cmNlcyI6WyJpbmRleC50cyJdLCJuYW1lcyI6W10sIm1hcHBpbmdzIjoiO0FBQUEsTUFBTSxVQUFVLEdBQUcsSUFBSSxDQUFDO0FBQ3hCLE9BQU8sQ0FBQyxHQUFHLENBQUMsVUFBVSxDQUFDLENBQUMiLCJzb3VyY2VzQ29udGVudCI6WyJjb25zdCBoZWxsb1dvcmxkID0gXCJoaVwiO1xuY29uc29sZS5sb2coaGVsbG9Xb3JsZCk7Il19
        Try
        • Default:

          false

        • Released:

          1.5

        # Raiz do mapa - mapRoot

        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.

          # Nova linha - newLine

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

          • Default:

            Platform specific.

          • Allowed:
            • crlf

            • lf

          • Released:

            1.5

          # Não Emita - noEmit

          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.

          • Default:

            false

          # No Emit Helpers - noEmitHelpers

          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;
          return g = { next: verb(0), "throw": verb(1), "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 (_) 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 emitir em caso de erro - noEmitOnError

          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.

          • Default:

            false

          • Released:

            1.4

          # Diretório de saída - outDir

          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

          # Arquivo de saída - outFile

          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.

          # Manter Enums Constantes - preserveConstEnums

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

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

          # preserveValueImports - preserveValueImports

          There are some cases where TypeScript can’t detect that you’re using an import. For example, take the following code:

          ts
          import { Animal } from "./animal.js";
          eval("console.log(new Animal().isDangerous())");

          or code using ‘Compiles to HTML’ languages like Svelte or Vue.

          When combined with isolatedModules: imported types must be marked as type-only because compilers that process single files at a time have no way of knowing whether imports are values that appear unused, or a type that must be removed in order to avoid a runtime crash.

          For example, in the following code TitleComponent is a function and TitleComponentProps is a type with isolatedModules and preserveValueImports are enabled:

          ts
          import { TitleComponent, TitleComponentProps } from "./TitleComponent.js";
          Try

          Which can be fixed by prefixing TitleComponentProps with type to mark it as a type-only import:

          ts
          import { TitleComponent, type TitleComponentProps } from "./TitleComponent.js";
          Try

          # Remover Comentários - removeComments

          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.

          • Default:

            false

          # Mapas de código - sourceMap

          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"
          }
          • Default:

            false

          # Raiz do código-fonte - sourceRoot

          Especifica a localização onde o depurador deve encontrar os arquivos TypeScript ao invés de outros locais relativos de origem. Essa string é processada literalmente dentro do mapa de origem, onde você pode utilizar um caminho ou uma URL:

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

          Declara que o index.js tem um arquivo fonte em https://my-website.com/debug/source/index.ts.

            # Remover internal - stripInternal

            Não emite declarações para códigos que tenham uma anotação @internal em seu comentário JSDoc. Esta é uma opção interna do compilador; use por sua conta em risco, porque o compilador não verifica se o resultado é válido. Se você estiver procurando por uma ferramenta para lidar com níveis adicionais de visibilidade dentro de seus arquivos d.ts, veja o api-extractor.

            ts
            /**
            * Dias disponíveis na semana
            * @internal
            */
            export const diasNaSemana = 7;
             
            /** Calcule quanto alguém ganha em uma semana */
            export function salarioSemanal(porDia: number) {
            return diasNaSemana * porDia;
            }
            Try

            Com a opção definida como false (padrão):

            ts
            /**
            * Dias disponíveis na semana
            * @internal
            */
            export declare const diasNaSemana = 7;
            /** Calcule quanto alguém ganha em uma semana */
            export declare function salarioSemanal(porDia: number): number;
             
            Try

            Com stripInternal definido como true o d.ts emitido será editado.

            ts
            /** Calcule quanto alguém ganha em uma semana */
            export declare function selarioSemanal(porDia: number): number;
             
            Try

            A JavaScript emitido ainda é o mesmo.

            • Internal

            #JavaScript Support

            # Permitir JS - allowJs

            Permite que arquivos JavaScript sejam importados dentro do seu projeto ao invés de só permitir arquivos .ts e .tsx. Por exemplo, este arquivo JS:

            js
            // @filename: carta.js
            export const naipePadrao = "Copas";
            Try

            Quando importado em um arquivo TypeScript, vai emitir um erro:

            ts
            // @filename: index.ts
            import { naipePadrao } from "./carta";
             
            console.log(naipePadrao);
            Try

            Mas é importado normalmente com a opção allowJS ativada:

            ts
            // @filename: index.ts
            import { naipePadrao } from "./carta";
             
            console.log(naipePadrao);
            Try

            Esta opção pode ser utilizada como uma forma de migrar um projeto JavaScript para TypeScript de forma incremental. Permitindo que arquivos .ts e .tsx coexistam no mesmo projeto que os arquivos JavaScript.

            # Checar JS - checkJs

            Funciona em conjunto com o allowJs. Quando o checkJs está ativado, os erros são relatados também nos arquivos JavaScript. Isto é o equivalente a incluir // @ts-check na parte superior de todos os arquivos JavaScript incluídos no seu projeto.

            Por exemplo, este é um JavaScript incorreto, de acordo com a definição do tipo parseFloat que acompanha o TypeScript:

            js
            // parseFloat só recebe uma string
            module.exports.pi = parseFloat(3.124);

            Quando importado em um módulo TypeScript:

            ts
            // @filename: constantes.js
            module.exports.pi = parseFloat(3.124);
             
            // @filename: index.ts
            import { pi } from "./constantes";
            console.log(pi);
            Try

            Você não vai obter nenhum erro. No entanto, se você ativar o checkJs então voce também terá mensagens de erro no seu arquivo JavaScript.

            ts
            // @filename: constantes.js
            Argument of type 'number' is not assignable to parameter of type 'string'.2345Argument of type 'number' is not assignable to parameter of type 'string'.
            module.exports.pi = parseFloat(3.124);
             
            // @filename: index.ts
            import { pi } from "./constantes";
            console.log(pi);
            Try

            # Profundidade JS do módulo de nó máximo - maxNodeModuleJsDepth

            A profundidade máxima de dependência para pesquisar em node_modules e carregar arquivos JavaScript.

            Este sinalizador só pode ser usado quando allowJs está habilitado, e é usado se você quiser ter tipos de inferência TypeScript para todo o JavaScript dentro de seu node_modules.

            Idealmente, isso deve ficar em 0 (o padrão), e os arquivos d.ts devem ser usados para definir explicitamente a forma dos módulos. No entanto, há casos em que você pode querer ativar isso em detrimento da velocidade e da precisão potencial.

            • Default:

              0

            #Editor Support

            # Desativar limite de tamanho - disableSizeLimit

            Para evitar um possível problema de inchaço da memória ao trabalhar com projetos JavaScript muito grandes, há um limite superior para a quantidade de memória que o TypeScript alocará. Ativar este sinalizador removerá o limite.

            • Default:

              false

            # Plugins - plugins

            Lista de plugins de serviço de linguagem a serem executados dentro do editor.

            Os plugins de serviço de linguagem são uma forma de fornecer informações adicionais a um usuário com base em arquivos TypeScript existentes. Eles podem aprimorar as mensagens existentes entre o TypeScript e um editor ou fornecer suas próprias mensagens de erro.

            Por exemplo:

            VS Code tem a capacidade de uma extensão para incluir automaticamente plugins de serviço de linguagem, e assim você pode ter alguns rodando em seu editor sem precisar defini-los em seu tsconfig.json.

              #Interop Constraints

              # Permitir Imports Sintéticos Padrão - allowSyntheticDefaultImports

              Quando está ativo, allowSyntheticDefaultImports permite que você escreva um import como:

              ts
              import React from "react";

              Ao invés de:

              ts
              import * as React from "react";

              Quando o módulo não especifica um export padrão.

              Isso não afeta o JavaScript que será emitido no TypeScript, somente a checagem de tipos Essa opção traz o comportamento do TypeScript in-line com o Babel, onde código extra é emitido no final para que o uso de um export padrão seja mais ergonômico.

              # Interoperabilidade de Módulo ES - esModuleInterop

              Permite interoperabilidade de emição entre Módulos CommonJS e ES através da criação de namespaces para todas as importações.

              TypeScript adere ao padrão EcmaScript para módulos, o que significa que um arquivo com exportações teria que especificamente incluir uma exportação default para dar suporte à sintaxes como import React from "react". Este padrão de exportação é raro em módulos para CommonJS. Por exemplo, sem esModuleInterop como true:

              ts
              // @filename: utilitarios.js
              const obterTamanhoDaString = (str) => str.length;
               
              module.exports = {
              obterTamanhoDaString,
              };
               
              // @filename: index.ts
              import utils from "./utilitarios";
               
              const count = utils.obterTamanhoDaString("Checagem JS");
              Try

              Isto não vai funcionar porque não existe um objeto default o qual você pode importar. Apesar de parecer que deveria. Por conveniência, transpiladores como Babel vão criar um default automaticamente se não encontrarem um existente. Fazendo com que o módulo se pareça um pouco mais com isto:

              js
              // @filename: utilitarios.js
              const obterTamanhoDaString = (str) => str.length;
              const todasAsFuncoes = {
              obterTamanhoDaString,
              };
              module.exports = todasAsFuncoes;

              Ativando esta flag no compilador, a opção allowSyntheticDefaultImports também será habilitada.

              # Manter a consistência nos nomes do arquivo - forceConsistentCasingInFileNames

              TypeScript diferencia letras maiúsculas e minúsculas no arquivo que está sendo executado. Isso pode se tornar um problema se alguns desenvolvedores trabalharem com diferenciação de letras maiúsculas e minúsculas no arquivo, e outros não. Se um arquivo tentar importar fileManager.ts especificando ./FileManager.ts em sistemas que não fazem a diferenciação de maiúsculas e minúsculas, vai encontrar o arquivo, porém, em sistemas que fazem essa diferenciação, o arquivo não será encontrado.

              Quando essa opção está definida, o TypeScript vai gerar um erro caso o programa tente incluir um arquivo com padrão diferente - de diferenciação maiúsculas e minúsculas - no sistema.

              • Recommended
              • Default:

                false

              # Módulos Isolados - isolatedModules

              Embora você possa usar o TypeScript para produzir código JavaScript a partir do código TypeScript, também é comum usar outros transpilers como Babel para fazer isso. No entanto, outros transpilers operam apenas em um único arquivo por vez, o que significa que eles não podem aplicar transformações de código que dependem da compreensão de todo o sistema de tipos. Esta restrição também se aplica à API ts.transpileModule do TypeScript que é usada por algumas ferramentas de construção.

              Essas limitações podem causar problemas de tempo de execução com alguns recursos do TypeScript, como const enums enamespaces. Definir o sinalizador isolatedModules diz ao TypeScript para avisá-lo se você escrever certo código que não pode ser interpretado corretamente por um processo de transpilação de arquivo único.

              Isso não altera o comportamento do seu código ou, de outra forma, altera o comportamento do processo de verificação e emissão do TypeScript

              Alguns exemplos de código que não funcionam quando isolatedModules está habilitado.

              Exportações de identificadores sem valor

              No TypeScript, você pode importar um type e depois exportá-lo:

              ts
              import { someType, someFunction } from "someModule";
               
              someFunction();
               
              export { someType, someFunction };
              Try

              Como não há valor para someType, oexport emitido não tentará exportá-lo (isso seria um erro de tempo de execução em JavaScript):

              js
              export { someFunction };

              Transpiladores de arquivo único não sabem se someType produz um valor ou não, então é um erro exportar um nome que se refere apenas a um tipo.

              Arquivos Non-Module

              Se isolatedModules estiver definido, todos os arquivos de implementação devem ser modules (o que significa que tem alguma forma deimport / export). Ocorre um erro se algum arquivo não for um módulo:

              ts
              function fn() {}
              'index.ts' cannot be compiled under '--isolatedModules' because it is considered a global script file. Add an import, export, or an empty 'export {}' statement to make it a module.1208'index.ts' cannot be compiled under '--isolatedModules' because it is considered a global script file. Add an import, export, or an empty 'export {}' statement to make it a module.
              Try

              Esta restrição não se aplica a arquivos .d.ts

              Referências a membros const enum

              No TypeScript, quando você faz referência a um membro const enum, a referência é substituída por seu valor real no JavaScript emitido. Alterando este TypeScript:

              ts
              declare const enum Numbers {
              Zero = 0,
              One = 1,
              }
              console.log(Numbers.Zero + Numbers.One);
              Try

              Para este JavaScript:

              ts
              "use strict";
              console.log(0 + 1);
               
              Try

              Sem o conhecimento dos valores desses membros, outros transpiladores não podem substituir as referências a Number, o que seria um erro de tempo de execução se deixado sozinho (uma vez que não há objeto Numbers em tempo de execução). Por causa disso, quando isolatedModules é definido, é um erro fazer referência a um membro ambiente const enum.

              • Default:

                false

              Esta opção serve para refletir a mesma flag do Node.js; que não resolve o caminho real de links simbólicos.

              Esta flag também exibe o comportamento oposto ao da opção resolve.symlinks do Webpack (ou seja, definir preserveSymlinks do TypeScript para true é o mesmo que definir resolve.symlinks do Webpack para false, e vice-versa).

              Com esta opção habilitada, as referências para módulos e pacotes (ex. diretivas import e /// <reference type="..." />) são todas resolvidas em relação ao local do symlink em si, em vez de relativas ao caminho que o symlink resolve.

              • Default:

                n/a

              #Backwards Compatibility

              # Charset - charset

              Nas versões anteriores do TypeScript, isso controlava qual codificação era usada ao ler arquivos de texto do disco. Hoje, o TypeScript assume a codificação UTF-8, mas detectará corretamente as codificações UTF-16 (BE e LE) ou UTF-8 com BOMs.

              • Deprecated
              • Default:

                utf8

              # Somente Strings em KeyOf - keyofStringsOnly

              Este sinalizador muda o operador do tipo keyof para retornarstring em vez de string | number quando aplicado a um tipo com uma assinatura de índice de string.

              Este sinalizador é usado para ajudar as pessoas a evitar esse comportamento de before TypeScript 2.9’s release.

              • Deprecated
              • Default:

                false

              • Released:

                2.9

              # Sem 'Use Strict' Implícito - noImplicitUseStrict

              Você não deveria precisar disso. Por padrão, ao emitir um arquivo de módulo para um destino não ES6, o TypeScript emite um prólogo "use strict"; no topo do arquivo. Esta configuração desabilita o prólogo.

              ts
              define(["require", "exports"], function (require, exports) {
              exports.__esModule = true;
              exports.fn = void 0;
              function fn() { }
              exports.fn = fn;
              });
               
              Try
              ts
              define(["require", "exports"], function (require, exports) {
              "use strict";
              exports.__esModule = true;
              exports.fn = void 0;
              function fn() { }
              exports.fn = fn;
              });
               
              Try
              • Default:

                false

              # Sem Verificações Genéricas Estritas - noStrictGenericChecks

              O TypeScript unificará os parâmetros de tipo ao comparar duas funções genéricas.

              ts
              type A = <T, U>(x: T, y: U) => [T, U];
              type B = <S>(x: S, y: S) => [S, S];
               
              function f(a: A, b: B) {
              b = a; // Ok
              a = b; // Erro
              Type 'B' is not assignable to type 'A'. Types of parameters 'y' and 'y' are incompatible. Type 'U' is not assignable to type 'T'. 'T' could be instantiated with an arbitrary type which could be unrelated to 'U'.2322Type 'B' is not assignable to type 'A'. Types of parameters 'y' and 'y' are incompatible. Type 'U' is not assignable to type 'T'. 'T' could be instantiated with an arbitrary type which could be unrelated to 'U'.
              }
              Try

              Esta flag pode ser usada para remover essa verificação.

              • Default:

                false

              • Released:

                2.4

              # Saída - out

              Use outFile ao invés.

              A opção out calcula a localização final do arquivo de uma forma que não é previsível ou consistente. Esta opção foi mantida apenas para compatibilidade com versões anteriores e foi descontinuada.

              # Prevenir erros de propriedades em excesso - suppressExcessPropertyErrors

              Desativa o relatório de erros de propriedades em excesso, como o mostrado no exemplo a seguir:

              ts
              type Point = { x: number; y: number };
              const p: Point = { x: 1, y: 3, m: 10 };
              Type '{ x: number; y: number; m: number; }' is not assignable to type 'Point'. Object literal may only specify known properties, and 'm' does not exist in type 'Point'.2322Type '{ x: number; y: number; m: number; }' is not assignable to type 'Point'. Object literal may only specify known properties, and 'm' does not exist in type 'Point'.
              Try

              Esta opção foi adicionada para ajudar as pessoas a migrar para a verificação mais rigorosa de novos objetos literais no TypeScript 1.6.

              Não recomendamos o uso dessa sinalização em uma base de código moderna, você pode prevenir casos únicos em que precise dela usando // @ts-ignore.

              • Default:

                false

              # Prevenir erros de implicit any index - suppressImplicitAnyIndexErrors

              Ativando suppressImplicitAnyIndexErrors previne o relato do erros sobre qualquer implícito ao indexar objetos, conforme mostrado no exemplo a seguir:

              ts
              const obj = { x: 10 };
              console.log(obj["foo"]);
              Element implicitly has an 'any' type because expression of type '"foo"' can't be used to index type '{ x: number; }'. Property 'foo' does not exist on type '{ x: number; }'.7053Element implicitly has an 'any' type because expression of type '"foo"' can't be used to index type '{ x: number; }'. Property 'foo' does not exist on type '{ x: number; }'.
              Try

              Usar suppressImplicitAnyIndexErrors é uma abordagem bastante extrema. É recomendado usar um comentário @ts-ignore ao invés:

              ts
              const obj = { x: 10 };
              // @ts-ignore
              console.log(obj["foo"]);
              Try

              #Language and Environment

              # Emitir Metadados de Decorators - emitDecoratorMetadata

              Ativa o suporte experimental para a emissão de metadados de tipo para decorators que funcionam com o módulo reflect-metadata.

              Por exemplo, aqui está o JavaScript

              ts
              function LogarMetodo(
              alvo: any,
              chaveDaPropriedade: string | symbol,
              descritor: PropertyDescriptor
              ) {
              console.log(alvo);
              console.log(chaveDaPropriedade);
              console.log(descritor);
              }
               
              class Demo {
              @LogarMetodo
              public foo(bar: number) {
              // não faz nada
              }
              }
               
              const demo = new Demo();
              Try

              Com emitDecoratorMetadata não ativo (padrão):

              ts
              "use strict";
              var __decorate = (this && this.__decorate) || function (decorators, target, key, desc) {
              var c = arguments.length, r = c < 3 ? target : desc === null ? desc = Object.getOwnPropertyDescriptor(target, key) : desc, d;
              if (typeof Reflect === "object" && typeof Reflect.decorate === "function") r = Reflect.decorate(decorators, target, key, desc);
              else for (var i = decorators.length - 1; i >= 0; i--) if (d = decorators[i]) r = (c < 3 ? d(r) : c > 3 ? d(target, key, r) : d(target, key)) || r;
              return c > 3 && r && Object.defineProperty(target, key, r), r;
              };
              function LogarMetodo(alvo, chaveDaPropriedade, descritor) {
              console.log(alvo);
              console.log(chaveDaPropriedade);
              console.log(descritor);
              }
              class Demo {
              foo(bar) {
              // não faz nada
              }
              }
              __decorate([
              LogarMetodo
              ], Demo.prototype, "foo", null);
              const demo = new Demo();
               
              Try

              Com emitDecoratorMetadata em true:

              ts
              "use strict";
              var __decorate = (this && this.__decorate) || function (decorators, target, key, desc) {
              var c = arguments.length, r = c < 3 ? target : desc === null ? desc = Object.getOwnPropertyDescriptor(target, key) : desc, d;
              if (typeof Reflect === "object" && typeof Reflect.decorate === "function") r = Reflect.decorate(decorators, target, key, desc);
              else for (var i = decorators.length - 1; i >= 0; i--) if (d = decorators[i]) r = (c < 3 ? d(r) : c > 3 ? d(target, key, r) : d(target, key)) || r;
              return c > 3 && r && Object.defineProperty(target, key, r), r;
              };
              var __metadata = (this && this.__metadata) || function (k, v) {
              if (typeof Reflect === "object" && typeof Reflect.metadata === "function") return Reflect.metadata(k, v);
              };
              function LogarMetodo(alvo, chaveDaPropriedade, descritor) {
              console.log(alvo);
              console.log(chaveDaPropriedade);
              console.log(descritor);
              }
              class Demo {
              foo(bar) {
              // não faz nada
              }
              }
              __decorate([
              LogarMetodo,
              __metadata("design:type", Function),
              __metadata("design:paramtypes", [Number]),
              __metadata("design:returntype", void 0)
              ], Demo.prototype, "foo", null);
              const demo = new Demo();
               
              Try

              # Decorators experimentais - experimentalDecorators

              Habilita suporte experimental a decorators, o qual está em stage 2 do processo de padronização do TC39.

              Decorators é uma funcionalidade da linguagem ainda não totalmente ratificada na especificação do JavaScript. Isso significa que a versão implementada no TypeScript pode diferir da implementação em JavaScript quando ela for definitivamente decidida pelo TC39.

              Você pode encontrar mais sobre o suporte a decorators no TypeScript no guia.

              # JSX - jsx

              Define como a sintaxe JSX é gerada em um arquivo JavaScript. Isso afeta apenas a saída JS para arquivos que terminam em .tsx.

              • preserve: Gera um arquivo .jsx sem alterar o JSX
              • react: Converte JSX em equivalente React.createElement e gera arquivo.js
              • react-native: Gera arquivo .js sem alterar o JSX

              # Fabrica JSX - jsxFactory

              Altera a função chamada em arquivos .js ao compilar elementos JSX. A alteração mais comum é usar "h" ou "preact.h" ao invés do padrão "React.createElement" se estiver usando preact.

              Esta opção pode ser usada por arquivo muito semelhante a directiva /** @jsx h */ do Babel.

              # Fábrica de fragmentos JSX - jsxFragmentFactory

              Especifique a função que será a fábrica de fragmentos JSX para ser acionada ao usar o react JSX com a opção do compilador jsxFactory especificada, por exemplo Fragment.

              Esta opção pode ser usada por arquivo, muito semelhante a diretiva /** @jsxFrag h */ do Babel.).

              Por exemplo, com esse TSConfig:

              json
              {
              "compilerOptions": {
              "target": "esnext",
              "module": "commonjs",
              "jsx": "react",
              "jsxFactory": "h",
              "jsxFragmentFactory": "Fragment"
              }
              }

              Temos esse arquivo TSX:

              tsx
              import { h, Fragment } from "preact";
              const OlaMundo = () => (
              <>
              <div>Olá</div>
              </>
              );

              Que seria equivalente, a esse arquivo TSX:

              tsx
              const preact_1 = require("preact");
              const OlaMundo = () => ((0, preact_1.h)(preact_1.Fragment, null,
              (0, preact_1.h)("div", null, "Ol\u00E1")));
               
              Try

              # Fonte de importação jsx - jsxImportSource

              Declara o especificador de módulo a ser usado para importar as funções factory jsx e jsxs ao usar jsx como "react-jsx" ou "react-jsxdev" que foi introduzido no TypeScript 4.1.

              Com React 17, a biblioteca suporta uma nova forma de transformação JSX através de uma importação separada.

              Por exemplo com este código:

              tsx
              import React from "react";
              function App() {
              return <h1>Olá Mundo</h1>;
              }

              Usando este TSConfig:

              {
              "": "esnext",
              "": "commonjs",
              "": "react-jsx"
              }
              }

              O JavaScript gerado pelo TypeScript é:

              tsx
              "use strict";
              var __importDefault = (this && this.__importDefault) || function (mod) {
              return (mod && mod.__esModule) ? mod : { "default": mod };
              };
              Object.defineProperty(exports, "__esModule", { value: true });
              const jsx_runtime_1 = require("react/jsx-runtime");
              const react_1 = __importDefault(require("react"));
              function App() {
              return (0, jsx_runtime_1.jsx)("h1", { children: "Hello World" }, void 0);
              }
               
              Try

              Por exemplo se você quiser usar "jsxImportSource": "preact", você precisa de um tsconfig como:

              {
              "": "esnext",
              "": "commonjs",
              "": "react-jsx",
              "": "preact",
              "": ["preact"]
              }
              }

              Que gera um código como:

              tsx
              function App() {
              return (0, jsx_runtime_1.jsx)("h1", { children: "Ol\u00E1 Mundo" }, void 0);
              }
              exports.App = App;
               
              Try

              Ao invés disso, voce pode usar um pragma por arquivo para definir esta opção, por exemplo:

              tsx
              /** @jsxImportSource preact */
              export function App() {
              return <h1>Olá Mundo</h1>;
              }

              Adicionaria preact/jsx-runtime como uma importação para a factory _jsx

              Nota: Para que isso funcione como você esperava, seu arquivo tsx deve incluir um export ou import para que seja considerado um módulo.

              # Biblioteca - lib

              O TypeScript inclui um conjunto padrão de definições de tipo para APIs JS embutidas (como Math), bem como definições de tipo para coisas encontradas em ambientes de navegador (como document). TypeScript também inclui APIs para recursos JS mais recentes que correspondem ao target que você especifica; por exemplo, a definição para Map está disponível se target for ES6 ou mais recente.

              Você pode querer alterá-los por alguns motivos:

              • Seu programa não roda em um navegador, então você não quer as definições do tipo "dom"
              • Sua plataforma de tempo de execução fornece certos objetos de API JavaScript (talvez por meio de polyfills), mas ainda não suporta a sintaxe completa de uma determinada versão ECMAScript
              • Você tem polyfills ou implementações nativas para alguns, mas não todos, de uma versão ECMAScript de nível superior

              Bibliotecas de alto nível

              Name Contents
              ES5 Definições básicas para todas as funcionalidades ES3 e ES5
              ES2015 APIs adicionais disponíveis no ES2015 (também conhecido como ES6) - array.find, Promise, Proxy, Symbol, Map, Set, Reflect, etc.
              ES6 Alias for “ES2015”
              ES2016 APIs adicionais disponíveis no ES2016 - array.include, etc.
              ES7 Alias for “ES2016”
              ES2017 APIs adicionais disponíveis no ES2017 - Object.entries, Object.values, Atomics, SharedArrayBuffer, date.formatToParts, typed arrays, etc.
              ES2018 APIs adicionais disponíveis no ES2018 - async iterables, promise.finally, Intl.PluralRules, rexexp.groups, etc.
              ES2019 APIs adicionais disponíveis no ES2019 - array.flat,array.flatMap, Object.fromEntries, string.trimStart, string.trimEnd, etc.
              ES2020 APIs adicionais disponíveis no ES2020 - string.matchAll, etc.
              ESNext APIs adicionais disponíveis no ESNext - Isso muda conforme a especificação do JavaScript evolui
              DOM DOM definitions - window, document, etc.
              WebWorker APIs disponíveis em Web Worker contexts
              ScriptHost APIs para o Windows Script Hosting System

              Individual library components

              Name
              DOM.Iterable
              ES2015.Core
              ES2015.Collection
              ES2015.Generator
              ES2015.Iterable
              ES2015.Promise
              ES2015.Proxy
              ES2015.Reflect
              ES2015.Symbol
              ES2015.Symbol.WellKnown
              ES2016.Array.Include
              ES2017.object
              ES2017.Intl
              ES2017.SharedMemory
              ES2017.String
              ES2017.TypedArrays
              ES2018.Intl
              ES2018.Promise
              ES2018.RegExp
              ES2019.Array
              ES2019.Full
              ES2019.Object
              ES2019.String
              ES2019.Symbol
              ES2020.Full
              ES2020.String
              ES2020.Symbol.wellknown
              ESNext.AsyncIterable
              ESNext.Array
              ESNext.Intl
              ESNext.Symbol

              Esta lista pode estar desatualizada, você pode ver a lista completa no TypeScript source code.

              # Sem Biblioteca - noLib

              Desabilita a inclusão automática de qualquer arquivo de biblioteca. Se esta opção estiver definida, lib é ignorada.

              • Default:

                false

              • Related:

              # Namespace do React - reactNamespace

              Use --jsxFactory ao invés disso. Especifica o objeto invocado por createElement ao direcionar react para arquivos TSX.

              • Default:

                React

              # Runtime alvo - target

              Navegadores modernos suportam todas as funcionalidades ES6, então ES6 é uma boa escolha. Você pode definir um alvo (target) mais baixo se o deploy do seu código for feito em ambientes antigos, ou um alvo mais alto se o seu código é garantido de rodar em ambientes mais novos.

              A configuração target altera quais funcionalidades JS serão niveladas para baixo e quais ficarão inalteradas. Por exemplo, a arrow function () => this será transformada na expressão function equivalente se o target for ES5 ou mais baixo.

              Alterando o target também alterará o valor da lib. Você pode “misturar e combinar” as configurações target e lib da forma que quiser, mas você pode definir apenas o target, por conveniência.

              Se você está trabalhando apenas com Node.js, esses são os targets recomendados para essas versões do Node:

              Name Supported Target
              Node 8 ES2017
              Node 10 ES2018
              Node 12 ES2019

              Eles são baseados no banco de dados de suporte do node.green.

              O valor especial ESNext se refere a versão mais alta que a sua versão do TypeScript suporta. Essa configuração deve ser utilizada com precaução, pois não significa a mesma coisa entre diferentes versões do TypeScript e pode tornar atualizações menos previsíveis.

              • Default:

                ES3

              • Allowed:
                • es3

                • es5

                • es6/es2015

                • es2016

                • es2017

                • es2018

                • es2019

                • es2020

                • es2021

                • esnext

              • Released:

                1.0

              # Usar Define para Propriedades de Classes - useDefineForClassFields

              Esta flag é utilizada para realizar a migração para as próximas versões padrões da especificação de propriedades de classe. O TypeScript introduziu propriedades de classe muitos anos antes de elas serem ratificadas pelo TC39. A última versão da especificação do JavaScript tem um comportamento diferente da implementação do TypeScript em tempo de execução, mas a mesma sintaxe.

              Essa flag altera esse comportamento para o comportamento do ECMA.

              Você pode ler mais sobre essa transição nas notas de release da versão 3.7.

              • Default:
                • true if target is ES2022 or higher, including ESNext,

                • false otherwise.

              • Released:

                3.7

              #Compiler Diagnostics

              # Diagnósticos - diagnostics

              Usado para gerar informações de diagnóstico para depuração. Este comando é um subconjunto de extendedDiagnostics, apenas com resultados voltados para o usuário e mais fáceis de interpretar.

              Se você tiver sido solicitado por um engenheiro do compilador do TypeScript para fornecer os resultados usando esse sinalizador em uma compilação, não há mal algum em usar --extendedDiagnostics durante o processo.

              # explainFiles - explainFiles

              Imprime os nomes dos arquivos que o TypeScript reconhece como parte do seu projeto e a razão pela qual são partes da compilação.

              Por exemplo, neste projeto com apenas um simples arquivo index.ts

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

              Usando um tsconfig.json que tem explainFiles configurado como true:

              json
              {
              "compilerOptions": {
              "target": "es5",
              "module": "commonjs",
              "explainFiles": true
              }
              }

              Executando o TypeScript nesta pasta teremos uma saída semelhante à essa:

              ❯ tsc node_modules/typescript/lib/lib.d.ts Default library for target 'es5' node_modules/typescript/lib/lib.es5.d.ts Library referenced via 'es5' from file 'node_modules/typescript/lib/lib.d.ts' node_modules/typescript/lib/lib.dom.d.ts Library referenced via 'dom' from file 'node_modules/typescript/lib/lib.d.ts' node_modules/typescript/lib/lib.webworker.importscripts.d.ts Library referenced via 'webworker.importscripts' from file 'node_modules/typescript/lib/lib.d.ts' node_modules/typescript/lib/lib.scripthost.d.ts Library referenced via 'scripthost' from file 'node_modules/typescript/lib/lib.d.ts' index.ts Matched by include pattern '**/*' in 'tsconfig.json'

              A saída acima mostra:

              • A busca lib.d.ts inicial baseada em target, e a cadeia de arquivos .d.ts que são referenciados
              • O arquivo index.ts localizado através do pattern padrão de include

              Esta opção é destinada à depurar como um arquivo se tornou parte de sua compilação.

              # Diagnóstico estendido - extendedDiagnostics

              Você pode usar esta flag para descobrir em que o compilador TypeScript está utilizando o tempo de compilação. Esta é uma ferramenta utilizada para compreender as características da performance da sua base de código.

              Você pode aprender mais sobre como medir e compreender as informações retornadas por esta flag na sessão de performance da wiki.

              # Gerar Perfil de CPU - generateCpuProfile

              Essa opção permite que o TypeScript emita um perfil de CPU durante a depuração. O perfil de CPU pode oferecer informações sobre o porquê das suas compilações estarem lentas.

              Essa opção só pode ser utilizada no CLI pelo comando: --generateCpuProfile tsc-output.cpuprofile.

              sh
              npm run tsc --generateCpuProfile tsc-output.cpuprofile

              Esse arquivo pode ser aberto em um navegador baseado no Chromium, como o Chrome ou Microsoft Edge na seção de perfil de CPU. Para saber mais sobre o desempenho dos compiladores, pode visitar a wiki do TypeScript sobre performance.

              • Default:

                profile.cpuprofile

              • Released:

                3.7

              # Listar arquivos emitidos - listEmittedFiles

              Imprime nomes de arquivos gerados parte da compilação para o terminal.

              Este sinalizador é útil em dois casos:

              • Você deseja transpilar o TypeScript como parte de uma cadeia de construção no terminal onde os nomes dos arquivos são processados no próximo comando.
              • Você não tem certeza de que o TypeScript incluiu um arquivo que você esperava, como parte da depuração das configurações de inclusão de arquivo.

              Por exemplo:

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

              Com:

              json
              {
              "compilerOptions": {
              "declaration": true,
              "listFiles": true
              }
              }

              Ecoaria caminhos como:

              $ npm run tsc path/to/example/index.js path/to/example/index.d.ts

              Normalmente, o TypeScript retornaria silenciosamente em caso de sucesso.

              • Default:

                false

              # Lista de arquivos - listFiles

              Imprime nomes de arquivos que fazem parte da compilação. Isso é útil quando você não tem certeza de que o TypeScript tem incluiu um arquivo que você esperava.

              Por exemplo:

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

              Com:

              json
              {
              "compilerOptions": {
              "listFiles": true
              }
              }

              Ecoaria caminhos como::

              $ npm run tsc path/to/example/node_modules/typescript/lib/lib.d.ts path/to/example/node_modules/typescript/lib/lib.es5.d.ts path/to/example/node_modules/typescript/lib/lib.dom.d.ts path/to/example/node_modules/typescript/lib/lib.webworker.importscripts.d.ts path/to/example/node_modules/typescript/lib/lib.scripthost.d.ts path/to/example/index.ts

              # Resolução de rastreamento - traceResolution

              Quando você estiver tentando depurar o motivo de um módulo não ter sido incluso, você pode definir o traceResolutions para true para que o TypeScript imprima informações sobre o seu processo de resolução de cada arquivo processado.

              Você pode ler mais sobre projetos compostos nesse guia.

              • Default:

                false

              • Released:

                2.0

              #Projects

              # Composição - composite

              A opção composite aplica certas restrições que possibilitam que ferramentas de build (incluindo o TypeScript no modo --build) determinem rapidamente se um projeto já foi construído.

              Quando esta configuração está ativada:

              • A configuração rootDir, se não foi setada explicitamente, é o diretório que contém o arquivo tsconfig.json.

              • Todos os arquivos de implementação devem corresponder a um padrão do include ou listados no array files. Se esta restrição for violada, o tsc informará quais arquivos não foram especificados.

              • declaration é setado como true

              Você pode encontrar a documentação de projetos TypeScript no guia.

              # Desabilitar o carregamento do projeto referenciado - disableReferencedProjectLoad

              Em aplicações Typescript de multi projetos, o TypeScript irá carregar todos os projetos disponíveis na memória com o objetivo de fornecer resultados mais precisos para as respostas do editor que requerem um gráfico de conhecimento completo como ‘Localizar todas as referências’.

              Se o seu projeto for grande, você pode utilizar a flag disableReferencedProjectLoad para desabilitar o carregamento automático de todos os projetos. Com isso, os projetos serão carregados dinamicamente quando você abrir os arquivos através do seu editor.

              # Desabilitar Busca por Soluções - disableSolutionSearching

              Ao trabalhar com projetos TypeScript compostos, esta opção fornece uma maneira de declarar que você não deseja que um projeto seja incluído ao usar recursos como encontrar todas as referências ou pular para definição em um editor.

              Esse sinalizador é algo que você pode usar para aumentar a capacidade de resposta em grandes projetos compostos.

              # Desabilitar Redirecionamento de Referências no Projeto de Origem - disableSourceOfProjectReferenceRedirect

              Ao trabalhar com projetos TypeScript compostos, esta opção fornece uma maneira de voltar ao comportamento pré-3.7 em que os arquivos d.ts eram usados como limites entre os módulos.

              Na versão 3.7, a fonte da verdade são agora os arquivos TypeScript.

              # Incremental - incremental

              Diz ao TypeScript para salvar informações sobre o grafo do projeto da última compilação em arquivos armazenados no disco. Este cria uma série de arquivos .tsbuildinfo na mesma pasta de sua saída de compilação. Eles não são usados por seu JavaScript em tempo de execução e pode ser excluído com segurança. Você pode ler mais sobre a bandeira no 3.4 notas de lançamento.

              Para controlar em quais pastas você deseja que os arquivos sejam construídos, use a opção de configuração tsBuildInfoFile.

              # Arquivo de informações da build do TS - tsBuildInfoFile

              Essa configuração possibilita a você especificar um arquivo para armazenar informações incrementais de compilação como parte de projetos compostos que habilitam builds rápidas de grandes bases de código TypeScript. Você pode ler mais sobre projetos compostos nesse guia.

              Essa opção oferece uma forma de configurar o local onde o TypeScript se mantém informado sobre os arquivos que armazena no disco para indicar o estado de build de um projeto — por padrão, eles estão na mesma pasta dos seus JavaScripts emitidos.

              #Output Formatting

              # Sem truncamento de erro - noErrorTruncation

              Não truncar mensagens de erro

              Com false, o padrão.

              ts
              var x: {
              propertyWithAnExceedinglyLongName1: string;
              propertyWithAnExceedinglyLongName2: string;
              propertyWithAnExceedinglyLongName3: string;
              propertyWithAnExceedinglyLongName4: string;
              propertyWithAnExceedinglyLongName5: string;
              };
               
              // A representação da string do tipo 'x' deve ser truncada na mensagem de erro
              var s: string = x;
              Type '{ propertyWithAnExceedinglyLongName1: string; propertyWithAnExceedinglyLongName2: string; propertyWithAnExceedinglyLongName3: string; propertyWithAnExceedinglyLongName4: string; propertyWithAnExceedinglyLongName5: string; }' is not assignable to type 'string'.
              Variable 'x' is used before being assigned.
              2322
              2454
              Type '{ propertyWithAnExceedinglyLongName1: string; propertyWithAnExceedinglyLongName2: string; propertyWithAnExceedinglyLongName3: string; propertyWithAnExceedinglyLongName4: string; propertyWithAnExceedinglyLongName5: string; }' is not assignable to type 'string'.
              Variable 'x' is used before being assigned.
              Try

              Com true

              ts
              var x: {
              propertyWithAnExceedinglyLongName1: string;
              propertyWithAnExceedinglyLongName2: string;
              propertyWithAnExceedinglyLongName3: string;
              propertyWithAnExceedinglyLongName4: string;
              propertyWithAnExceedinglyLongName5: string;
              };
               
              // A representação da string do tipo 'x' deve ser truncada na mensagem de erro
              var s: string = x;
              Type '{ propertyWithAnExceedinglyLongName1: string; propertyWithAnExceedinglyLongName2: string; propertyWithAnExceedinglyLongName3: string; propertyWithAnExceedinglyLongName4: string; propertyWithAnExceedinglyLongName5: string; }' is not assignable to type 'string'.
              Variable 'x' is used before being assigned.
              2322
              2454
              Type '{ propertyWithAnExceedinglyLongName1: string; propertyWithAnExceedinglyLongName2: string; propertyWithAnExceedinglyLongName3: string; propertyWithAnExceedinglyLongName4: string; propertyWithAnExceedinglyLongName5: string; }' is not assignable to type 'string'.
              Variable 'x' is used before being assigned.
              Try
              • Default:

                false

              # Manter as saídas observadas - preserveWatchOutput

              Mantém as saídas desatualizadas no console durante o modo de observação, ao invés de limpar a tela toda vez que ocorrer alguma modificação.

              • Internal
              • Default:

                n/a

              # Embelezar - pretty

              Estiliza erros e mensagens utilizando cores e contexto, isso é ativado por padrão — oferece a você a oportunidade de receber do compilador menos mensagens concisas e de uma única cor.

              • Default:

                true

              #Completeness

              # Ignorar a verificação da biblioteca padrão - skipDefaultLibCheck

              Usar --skipLibCheck no lugar dessa. Ignora a checagem dos tipos de arquivos de declaração na biblioteca padrão.

              • Default:

                false

              # Ignorar a verificação de biblioteca - skipLibCheck

              Ignora a verificação dos arquivos de declaração.

              Isso pode economizar tempo durante a compilação, porém, às custas da precisão do sistema de tipos. Por exemplo, duas bibliotecas podem definir duas cópias do mesmo type de modo inconsistente. Em vez de fazer uma verificação completa de todos os arquivos d.ts, o TypeScript irá verificar o código ao qual você se refere no código-fonte do aplicativo.

              Um uso comum para se usar o skipLibCheck é quando há duas cópias de uma biblioteca no seu node_modules. Nesses casos você deve considerar usar um recurso como as resoluções do yarn para garantir que há apenas uma única cópia de cada dependência na sua árvore, ou descobrir como se certificar, entendendo as resoluções de dependência, como manter uma única cópia sem utilizar nenhuma ferramenta adicional.

              • Recommended
              • Default:

                false

              • Released:

                2.0

              #Linha de comando

              #Watch Options

              O TypeScript 3.8 lançou uma nova estratégia para monitorar as pastas, que é crucial para obter as mudanças no node_modules.

              Nos sistemas operacionais como Linux, o Typescript instala monitores de diretórios (ao contrário dos monitores de arquivos) no node_modules e muitos dos seus sub-diretórios para detectar mudanças nas suas dependências. Isto é devido a quantidade de monitores de arquivos disponíveis que é eclipsado pelo número de arquivos no node_modules, enquanto há muito poucos diretórios para rastrear.

              Como cada projeto deve funcionar melhor com diferentes estratégias, e esta nova abordagem pode não funcionar para o seu fluxo de trabalho, o TypeScript 3.8 introduziu o novo campo watchOptions que permite que o usuário diga ao compilador/serviço de linguagem quais estratégias de monitoramento devem ser utilizadas para manter o controle dos diretórios e arquivos.

              # Assume que as alterações afetem apenas dependências diretas - assumeChangesOnlyAffectDirectDependencies

              Quando essa opção está ativada, o TypeScript apenas verifica/reconstrói os arquivos que foram alterados, bem como os arquivos que os importam diretamente. Evitando assim a verificação/reconstrução de todos os arquivos que realmente podem ter sido afetados pelas alterações.

              Isso pode ser considerado uma implementação ‘rápida’ do algoritmo de observação, que pode reduzir drasticamente os tempos de reconstrução incremental às custas de ter que executar a compilação completa ocasionalmente para obter todas as mensagens de erro do compilador.

              # Observar Arquivo - watchFile

              Define a estratégia como arquivos individuais devem ser observados por mudanças.

              • fixedPollingInterval: Checa todos os arquivos por mudanças várias vezes por segundo a um intervalo pré-determinado.
              • priorityPollingInterval: Checa todos os arquivos por mudanças várias vezes por segundo, mas usando heurísticas para checar alguns tipos de arquivos mais frequentemente que outros.
              • dynamicPriorityPolling: Usa uma fila dinâmica onde arquivos menos modificados são checados menos frequentemente.
              • useFsEvents (padrão): Tenta utilizar a funcionalidade nativa de eventos de modificação de arquivos do sistema operacional.
              • useFsEventsOnParentDirectory: Tenta utilizar a implementação de eventos de modificação nativa do sistema operacional para detectar mudanças no diretório pai de um arquivo.
              • Allowed:
                • fixedpollinginterval

                • prioritypollinginterval

                • dynamicprioritypolling

                • fixedchunksizepolling

                • usefsevents

                • usefseventsonparentdirectory

              • Released:

                3.8

              # Observar Diretório - watchDirectory

              Determina a estratégia que rege como árvores de diretório são observadas por mudanças em sistemas que não possuem a funcionalidade de observação recursiva de arquivos.

              • fixedPollingInterval: Checa por mudanças nos arquivos várias vezes por segundo a um intervalo pré-determinado.
              • dynamicPriorityPolling: Usa uma fila dinâmica onde diretórios que são menos alterados serão checados menos vezes.
              • useFsEvents (padrão): Tenta utilizar os eventos de modificação de diretórios/arquivos do próprio sistema operacional.
              • Allowed:
                • usefsevents

                • fixedpollinginterval

                • dynamicprioritypolling

                • fixedchunksizepolling

              • Released:

                3.8

              # Alternativas na ausência de observadores - fallbackPolling

              Quando utilizar eventos de arquivos do sistema, essa opção indica as estratégias de verificação que o sistema deve executar quando estiver sem observadores e/ou não suportar os observadores nativos.

              • fixedPollingInterval: Checa por mudanças nos arquivos várias vezes por segundo a um intervalo pré-determinado.
              • priorityPollingInterval: Checa todos os arquivos por mudanças várias vezes por segundo, mas usando heurísticas para checar alguns tipos de arquivos mais frequentemente que outros.
              • dynamicPriorityPolling: Usa uma fila dinâmica onde diretórios que são menos alterados serão checados menos vezes.
              • synchronousWatchDirectory: Desativa a checagem adiada nos diretórios. Adiar a checagem é útil quando muitas mudanças podem acontecer de uma vez só (ex.: uma mudança em node_modules por executar o npm install), mas você pode querer desativar isso para configurações menos comuns.
              • Allowed:
                • fixedinterval

                • priorityinterval

                • dynamicpriority

                • fixedchunksize

              • Released:

                3.8

              # synchronousWatchDirectory - synchronousWatchDirectory

              Synchronously call callbacks and update the state of directory watchers on platforms that don`t support recursive watching natively. Instead of giving a small timeout to allow for potentially multiple edits to occur on a file.

              {
              "watchOptions": {
              }
              }

                # excludeDirectories - excludeDirectories

                You can use excludeFiles to drastically reduce the number of files which are watched during --watch. This can be a useful way to reduce the number of open file which TypeScript tracks on Linux.

                {
                "watchOptions": {
                "": ["**/node_modules", "_build", "temp/*"]
                }
                }

                  # excludeFiles - excludeFiles

                  You can use excludeFiles to remove a set of specific files from the files which are watched.

                  {
                  "watchOptions": {
                  "": ["temp/file.ts"]
                  }
                  }

                    Type Acquisition

                    Type Acquisition is only important for JavaScript projects. In TypeScript projects you need to include the types in your projects explicitly. However, for JavaScript projects, the TypeScript tooling will download types for your modules in the background and outside of your node_modules folder.

                    # enable - enable

                    Offers a config for disabling type-acquisition in JavaScript projects:

                    ts
                    {
                    "typeAcquisition": {
                    "enable": false
                    }
                    }

                    This could potentially remove all of the editor auto-completion for your project, if you want to get them back, you can use the Type Search to find @types packages or packages with types in them.

                      # Include - include

                      If you have a JavaScript project where TypeScript needs additional guidance to understand global dependencies, or have disabled the built-in inference via disableFilenameBasedTypeAcquisition.

                      You can use include to specify which types should be used from DefinitelyTyped:

                      json
                      {
                      "typeAcquisition": {
                      "include": ["jquery"]
                      }
                      }

                      # Exclude - exclude

                      Offers a config for disabling the type-acquisition for a certain module in JavaScript projects. This can be useful for projects which include other libraries in testing infrastructure which aren’t needed in the main application.

                      json
                      {
                      "typeAcquisition": {
                      "exclude": ["jest", "mocha"]
                      }
                      }

                      # disableFilenameBasedTypeAcquisition - disableFilenameBasedTypeAcquisition

                      TypeScript’s type acquisition can infer what types should be added based on filenames in a project. This means that having a file like jquery.js in your project would automatically download the types for JQuery from DefinitelyTyped.

                      You can disable this via disableFilenameBasedTypeAcquisition.

                      json
                      {
                      "typeAcquisition": {
                      "disableFilenameBasedTypeAcquisition": true
                      }
                      }