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.

    # 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

    # 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

    # Exact Optional Property Types - 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:

    # No Implicit Override - 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

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

    # 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

    # 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

    # 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);
    'usuarioLogado' is possibly 'undefined'.18048'usuarioLogado' is possibly 'undefined'.
    Try

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

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

    # Use Unknown In Catch Variables - 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: unknown) {
    // We have to verify err is an
    // error before using it as one.
    if (err instanceof Error) {
    console.log(err.message);
    }
    }
    Try

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

    • Recommended
    • Default:

      true if strict; false otherwise.

    • Related:
    • Released:

      4.4

    #Modules

    # Allow Arbitrary Extensions - allowArbitraryExtensions

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

    css
    /* app.css */
    .cookie-banner {
    display: none;
    }
    ts
    // app.d.css.ts
    declare const css: {
    cookieBanner: string;
    };
    export default css;
    ts
    // App.tsx
    import styles from "./app.css";
    styles.cookieBanner; // string

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

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

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

      # Allow Importing TS Extensions - allowImportingTsExtensions

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

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

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

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

          # Custom Conditions - customConditions

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

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

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

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

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

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

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

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

          # 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

          # 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

          # Module Suffixes - moduleSuffixes

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

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

          Given the above configuration, an import like the following:

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

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

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

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

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

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

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

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

                # Resolve package.json Exports - resolvePackageJsonExports

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

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

                # Resolve package.json Imports - resolvePackageJsonImports

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

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

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

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

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

                  # 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

                  # 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 ou inlineSourceMap para ser definido.

                  Por exemplo, com este TypeScript:

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

                  Por padrão, converte para este JavaScript:

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

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

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

                  # 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:

                      lf

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

                      # 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 (g && (g = 0, op[0] && (_ = 0)), _) try {
                      if (f = 1, y && (t = op[0] & 2 ? y["return"] : op[0] ? y["throw"] || ((t = y["return"]) && t.call(y), 0) : y.next) && !(t = t.call(y, op[1])).done) return t;
                      if (y = 0, t) op = [op[0] & 2, t.value];
                      switch (op[0]) {
                      case 0: case 1: t = op; break;
                      case 4: _.label++; return { value: op[1], done: false };
                      case 5: _.label++; y = op[1]; op = [0]; continue;
                      case 7: op = _.ops.pop(); _.trys.pop(); continue;
                      default:
                      if (!(t = _.trys, t = t.length > 0 && t[t.length - 1]) && (op[0] === 6 || op[0] === 2)) { _ = 0; continue; }
                      if (op[0] === 3 && (!t || (op[1] > t[0] && op[1] < t[3]))) { _.label = op[1]; break; }
                      if (op[0] === 6 && _.label < t[1]) { _.label = t[1]; t = op; break; }
                      if (t && _.label < t[2]) { _.label = t[2]; _.ops.push(op); break; }
                      if (t[2]) _.ops.pop();
                      _.trys.pop(); continue;
                      }
                      op = body.call(thisArg, _);
                      } catch (e) { op = [6, e]; y = 0; } finally { f = t = 0; }
                      if (op[0] & 5) throw op[1]; return { value: op[0] ? op[1] : void 0, done: true };
                      }
                      };
                      var getAPI = function (url) { return __awaiter(void 0, void 0, void 0, function () {
                      return __generator(this, function (_a) {
                      // Get API
                      return [2 /*return*/, {}];
                      });
                      }); };
                       
                      Try

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

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

                      # Não 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.

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

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

                      ts
                      "use strict";
                      var Album;
                      (function (Album) {
                      Album[Album["JimmyEatWorldFutures"] = 1] = "JimmyEatWorldFutures";
                      Album[Album["TubRingZooHypothesis"] = 2] = "TubRingZooHypothesis";
                      Album[Album["DogFashionDiscoAdultery"] = 3] = "DogFashionDiscoAdultery";
                      })(Album || (Album = {}));
                      const albumSelecionado = 1 /* Album.JimmyEatWorldFutures */;
                      if (albumSelecionado === 1 /* Album.JimmyEatWorldFutures */) {
                      console.log("Excelente escolha.");
                      }
                       
                      Try

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

                      # Preserve Value Imports - preserveValueImports

                      Deprecated in favor of verbatimModuleSyntax.

                      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. preserveValueImports will prevent TypeScript from removing the import, even if it appears unused.

                      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.

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

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

                          # 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
                            module.exports.pi = parseFloat(3.124);
                            Argument of type 'number' is not assignable to parameter of type 'string'.2345Argument of type 'number' is not assignable to parameter of type 'string'.
                             
                            // @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.

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

                                # 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:

                                    true

                                  # 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() {}
                                  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.

                                    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.

                                      # Verbatim Module Syntax - verbatimModuleSyntax

                                      By default, TypeScript does something called import elision. Basically, if you write something like

                                      ts
                                      import { Car } from "./car";
                                      export function drive(car: Car) {
                                      // ...
                                      }

                                      TypeScript detects that you’re only using an import for types and drops the import entirely. Your output JavaScript might look something like this:

                                      js
                                      export function drive(car) {
                                      // ...
                                      }

                                      Most of the time this is good, because if Car isn’t a value that’s exported from ./car, we’ll get a runtime error.

                                      But it does add a layer of complexity for certain edge cases. For example, notice there’s no statement like import "./car"; - the import was dropped entirely. That actually makes a difference for modules that have side-effects or not.

                                      TypeScript’s emit strategy for JavaScript also has another few layers of complexity - import elision isn’t always just driven by how an import is used - it often consults how a value is declared as well. So it’s not always clear whether code like the following

                                      ts
                                      export { Car } from "./car";

                                      should be preserved or dropped. If Car is declared with something like a class, then it can be preserved in the resulting JavaScript file. But if Car is only declared as a type alias or interface, then the JavaScript file shouldn’t export Car at all.

                                      While TypeScript might be able to make these emit decisions based on information from across files, not every compiler can.

                                      The type modifier on imports and exports helps with these situations a bit. We can make it explicit whether an import or export is only being used for type analysis, and can be dropped entirely in JavaScript files by using the type modifier.

                                      ts
                                      // This statement can be dropped entirely in JS output
                                      import type * as car from "./car";
                                      // The named import/export 'Car' can be dropped in JS output
                                      import { type Car } from "./car";
                                      export { type Car } from "./car";

                                      type modifiers are not quite useful on their own - by default, module elision will still drop imports, and nothing forces you to make the distinction between type and plain imports and exports. So TypeScript has the flag --importsNotUsedAsValues to make sure you use the type modifier, --preserveValueImports to prevent some module elision behavior, and --isolatedModules to make sure that your TypeScript code works across different compilers. Unfortunately, understanding the fine details of those 3 flags is hard, and there are still some edge cases with unexpected behavior.

                                      TypeScript 5.0 introduces a new option called --verbatimModuleSyntax to simplify the situation. The rules are much simpler - any imports or exports without a type modifier are left around. Anything that uses the type modifier is dropped entirely.

                                      ts
                                      // Erased away entirely.
                                      import type { A } from "a";
                                      // Rewritten to 'import { b } from "bcd";'
                                      import { b, type c, type d } from "bcd";
                                      // Rewritten to 'import {} from "xyz";'
                                      import { type xyz } from "xyz";

                                      With this new option, what you see is what you get.

                                      That does have some implications when it comes to module interop though. Under this flag, ECMAScript imports and exports won’t be rewritten to require calls when your settings or file extension implied a different module system. Instead, you’ll get an error. If you need to emit code that uses require and module.exports, you’ll have to use TypeScript’s module syntax that predates ES2015:

                                      Input TypeScript Output JavaScript
                                      ts
                                      import foo = require("foo");
                                      js
                                      const foo = require("foo");
                                      ts
                                      function foo() {}
                                      function bar() {}
                                      function baz() {}
                                      export = {
                                      foo,
                                      bar,
                                      baz,
                                      };
                                      js
                                      function foo() {}
                                      function bar() {}
                                      function baz() {}
                                      module.exports = {
                                      foo,
                                      bar,
                                      baz,
                                      };

                                      While this is a limitation, it does help make some issues more obvious. For example, it’s very common to forget to set the type field in package.json under --module node16. As a result, developers would start writing CommonJS modules instead of an ES modules without realizing it, giving surprising lookup rules and JavaScript output. This new flag ensures that you’re intentional about the file type you’re using because the syntax is intentionally different.

                                      Because --verbatimModuleSyntax provides a more consistent story than --importsNotUsedAsValues and --preserveValueImports, those two existing flags are being deprecated in its favor.

                                      For more details, read up on the original pull request and its proposal issue.

                                        #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 retornar string 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
                                        • 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.

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

                                          # 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 };
                                          Object literal may only specify known properties, and 'm' does not exist in type 'Point'.2353Object 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.

                                            # 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";
                                            Object.defineProperty(exports, "__esModule", { value: true });
                                            const jsx_runtime_1 = require("react/jsx-runtime");
                                            function App() {
                                            return (0, jsx_runtime_1.jsx)("h1", { children: "Hello World" });
                                            }
                                             
                                            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" });
                                            }
                                            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.

                                            # Module Detection - moduleDetection

                                            This setting controls how TypeScript determines whether a file is a script or a module.

                                            There are three choices:

                                            • "auto" (default) - TypeScript will not only look for import and export statements, but it will also check whether the "type" field in a package.json is set to "module" when running with module: nodenext or node16, and check whether the current file is a JSX file when running under jsx: react-jsx.

                                            • "legacy" - The same behavior as 4.6 and prior, usings import and export statements to determine whether a file is a module.

                                            • "force" - Ensures that every non-declaration file is treated as a module.

                                            • Default:

                                              "auto": Treat files with imports, exports, import.meta, jsx (with jsx: react-jsx), or esm format (with module: node16+) as modules.

                                            • Allowed:
                                              • legacy

                                              • auto

                                              • force

                                            • Released:

                                              4.7

                                            # Sem Biblioteca - noLib

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

                                            # 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

                                              • es2022

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

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

                                              #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

                                                # 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

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

                                                  # 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
                                                  • 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

                                                  # Synchronous Watch Directory - 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": {
                                                  }
                                                  }

                                                    # Exclude Directories - 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/*"]
                                                    }
                                                    }

                                                      # Exclude Files - 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

                                                        Disables automatic type acquisition in JavaScript projects:

                                                        json
                                                        {
                                                        "typeAcquisition": {
                                                        "enable": false
                                                        }
                                                        }

                                                          # 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"]
                                                          }
                                                          }

                                                          # Disable Filename Based Type Acquisition - 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
                                                          }
                                                          }