Se você estiver criando aplicativos da Web complexos, o TypeScript provavelmente é sua linguagem de programação preferida. O TypeScript é muito apreciado por seu forte sistema de tipos e recursos de análise estática, tornando-o uma ferramenta poderosa para garantir que seu código seja robusto e livre de erros.  Ele também acelera o processo de desenvolvimento por meio da integração com editores de código, permitindo que os desenvolvedores naveguem pelo código com mais eficiência e obtenham dicas e preenchimento automático mais precisos, além de possibilitar a refatoração segura de grandes quantidades de código.  O compilador é o coração do TypeScript, responsável por verificar a correção do tipo e transformar o código TypeScript em JavaScript. No entanto, para utilizar totalmente o poder do TypeScript, é importante configurar o compilador corretamente.  Cada projeto TypeScript tem um ou mais arquivos   que contêm todas as opções de configuração do compilador. tsconfig.json  A configuração do tsconfig é uma etapa crucial para obter segurança de tipo ideal e experiência do desenvolvedor em seus projetos TypeScript. Ao reservar um tempo para considerar cuidadosamente todos os principais fatores envolvidos, você pode acelerar o processo de desenvolvimento e garantir que seu código seja robusto e livre de erros.  Desvantagens da configuração padrão  A configuração padrão no tsconfig pode fazer com que os desenvolvedores percam a maioria dos benefícios do TypeScript. Isso ocorre porque ele não habilita muitos recursos poderosos de verificação de tipo. Por configuração "padrão", quero dizer uma configuração em que nenhuma opção do compilador de verificação de tipo é definida.  Por exemplo:   { "compilerOptions": { "target": "esnext", "module": "esnext", "esModuleInterop": true, "forceConsistentCasingInFileNames": true, "skipLibCheck": true, }, "include": ["src"] }  A ausência de várias opções de configuração de chave pode resultar em qualidade de código inferior por dois motivos principais. Em primeiro lugar, o compilador do TypeScript pode lidar incorretamente com tipos   e   em vários casos. null undefined  Em segundo lugar, o tipo   pode aparecer incontrolavelmente em sua base de código, levando à verificação de tipo desativada em torno desse tipo. any  Felizmente, esses problemas são fáceis de corrigir ajustando algumas opções na configuração.  O Modo Estrito   { "compilerOptions": { "strict": true } }  O modo estrito é uma opção de configuração essencial que fornece garantias mais fortes de correção do programa, permitindo uma ampla gama de comportamentos de verificação de tipo.  Habilitar o modo estrito no arquivo tsconfig é uma etapa crucial para alcançar a máxima segurança de tipo e uma melhor experiência do desenvolvedor.  Requer um pouco de esforço extra na configuração do tsconfig, mas pode ajudar muito a melhorar a qualidade do seu projeto.  A opção de compilador   ativa todas as opções de família de modo estrito, que incluem   ,   ,   , entre outros. strict noImplicitAny strictNullChecks strictFunctionTypes  Essas opções também podem ser configuradas separadamente, mas não é recomendável desativar nenhuma delas. Vejamos exemplos para ver o porquê.  Implícita Qualquer Inferência   { "compilerOptions": { "noImplicitAny": true } }  O tipo   é uma brecha perigosa no sistema de tipo estático e usá-lo desabilita todas as regras de verificação de tipo. Como resultado, todos os benefícios do TypeScript são perdidos: bugs são perdidos, as dicas do editor de código param de funcionar corretamente e assim por diante. any  O uso   é permitido apenas em casos extremos ou para necessidades de prototipagem. Apesar de nossos melhores esforços, o tipo   pode às vezes entrar em uma base de código implicitamente. any any  Por padrão, o compilador nos perdoa muitos erros em troca do aparecimento de   em uma base de código. Especificamente, TypeScript nos permite não especificar o tipo de variáveis, mesmo quando o tipo não pode ser inferido automaticamente. any  O problema é que podemos acidentalmente esquecer de especificar o tipo de uma variável, por exemplo, para um argumento de função. Em vez de mostrar um erro, o TypeScript inferirá automaticamente o tipo da variável como   . any   function parse(str) { // ^? any return str.split(''); } // TypeError: str.split is not a function const res1 = parse(42); const res2 = parse('hello'); // ^? any  Habilitar a opção do compilador   fará com que o compilador destaque todos os lugares onde o tipo de uma variável é inferido automaticamente como   . Em nosso exemplo, o TypeScript solicitará que especifiquemos o tipo do argumento da função. noImplicitAny any   function parse(str) { // ^ Error: Parameter 'str' implicitly has an 'any' type. return str.split(''); }  Quando especificamos o tipo, o TypeScript detecta rapidamente o erro de passar um número para um parâmetro de string. O valor de retorno da função, armazenado na variável   , também terá o tipo correto. res2   function parse(str: string) { return str.split(''); } const res1 = parse(42); // ^ Error: Argument of type 'number' is not // assignable to parameter of type 'string' const res2 = parse('hello'); // ^? string[]  Tipo desconhecido em variáveis de captura   { "compilerOptions": { "useUnknownInCatchVariables": true } }  A configuração de   permite a manipulação segura de exceções em blocos try-catch. Por padrão, o TypeScript assume que o tipo de erro em um bloco catch é   , o que nos permite fazer qualquer coisa com o erro. useUnknownInCatchVariables any  Por exemplo, poderíamos passar o erro detectado como está para uma função de registro que aceita uma instância de   . Error   function logError(err: Error) { // ... } try { return JSON.parse(userInput); } catch (err) { // ^? any logError(err); }  No entanto, na realidade, não há garantias sobre o tipo de erro e só podemos determinar seu verdadeiro tipo em tempo de execução quando o erro ocorre. Se a função de registro receber algo que não seja um   , isso resultará em um erro de tempo de execução. Error  Portanto, a opção   alterna o tipo de erro de   para   para nos lembrar de verificar o tipo de erro antes de fazer qualquer coisa com ele. useUnknownInCatchVariables any unknown   try { return JSON.parse(userInput); } catch (err) { // ^? unknown // Now we need to check the type of the value if (err instanceof Error) { logError(err); } else { logError(new Error('Unknown Error')); } }  Agora, o TypeScript solicitará que verifiquemos o tipo da variável   antes de passá-la para a função   , resultando em um código mais correto e seguro. Infelizmente, esta opção não ajuda com erros de digitação em funções   ou funções de retorno de chamada. err logError promise.catch()  Mas discutiremos maneiras de lidar com   desses casos no próximo artigo. any  Verificação de tipo para os métodos Call e Apply   { "compilerOptions": { "strictBindCallApply": true } }  Outra opção corrige a aparência de   chamada em função via   e   . Este é um caso menos comum do que os dois primeiros, mas ainda é importante considerar. Por padrão, o TypeScript não verifica os tipos nessas construções. any call apply  Por exemplo, podemos passar qualquer coisa como argumento para uma função e, no final, sempre receberemos o tipo   . any   function parse(value: string) { return parseInt(value, 10); } const n1 = parse.call(undefined, '10'); // ^? any const n2 = parse.call(undefined, false); // ^? any  Habilitar a opção   torna o TypeScript mais inteligente, portanto, o tipo de retorno será inferido corretamente como   . E ao tentar passar um argumento do tipo errado, o TypeScript apontará para o erro. strictBindCallApply number   function parse(value: string) { return parseInt(value, 10); } const n1 = parse.call(undefined, '10'); // ^? number const n2 = parse.call(undefined, false); // ^ Argument of type 'boolean' is not // assignable to parameter of type 'string'.  Tipos restritos para contexto de execução   { "compilerOptions": { "noImplicitThis": true } }  A próxima opção que pode ajudar a evitar o aparecimento de   em seu projeto corrige a manipulação do contexto de execução em chamadas de função. A natureza dinâmica do JavaScript torna difícil determinar estaticamente o tipo de contexto dentro de uma função. any  Por padrão, o TypeScript usa o tipo   para o contexto nesses casos e não fornece nenhum aviso. any   class Person { private name: string; constructor(name: string) { this.name = name; } getName() { return function () { return this.name; // ^ 'this' implicitly has type 'any' because // it does not have a type annotation. }; } }  Habilitar a opção de compilador   nos solicitará especificar explicitamente o tipo de contexto para uma função. Desta forma, no exemplo acima, podemos pegar o erro de acesso ao contexto da função ao invés do campo   da classe   . noImplicitThis name Person  Suporte nulo e indefinido em TypeScript   { "compilerOptions": { "strictNullChecks": true } }  Em seguida, várias opções incluídas no modo   não resultam na exibição de   tipo na base de código. No entanto, eles tornam o comportamento do compilador TS mais rígido e permitem que mais erros sejam encontrados durante o desenvolvimento. strict any  A primeira dessas opções corrige o tratamento de   e   no TypeScript. Por padrão, o TypeScript assume que   e   são valores válidos para qualquer tipo, o que pode resultar em erros de tempo de execução inesperados. null undefined null undefined  Habilitar a opção de compilador   força o desenvolvedor a lidar explicitamente com casos em que   e   podem ocorrer. strictNullChecks null undefined  Por exemplo, considere o seguinte código:   const users = [ { name: 'Oby', age: 12 }, { name: 'Heera', age: 32 }, ]; const loggedInUser = users.find(u => u.name === 'Max'); // ^? { name: string; age: number; } console.log(loggedInUser.age); // ^ TypeError: Cannot read properties of undefined  Este código irá compilar sem erros, mas pode gerar um erro de tempo de execução se o usuário com o nome “Max” não existir no sistema e   retornar   . Para evitar isso, podemos habilitar a opção de compilador   . users.find() undefined strictNullChecks  Agora, o TypeScript nos forçará a lidar explicitamente com a possibilidade de   ou   ser retornado por   . null undefined users.find()   const loggedInUser = users.find(u => u.name === 'Max'); // ^? { name: string; age: number; } | undefined if (loggedInUser) { console.log(loggedInUser.age); }  Ao manipular explicitamente a possibilidade de   e   , podemos evitar erros de tempo de execução e garantir que nosso código seja mais robusto e livre de erros. null undefiined  Tipos de funções estritas   { "compilerOptions": { "strictFunctionTypes": true } }  Habilitar   torna o compilador do TypeScript mais inteligente. Antes da versão 2.6, o TypeScript não verificava a   dos argumentos da função. Isso levará a erros de tempo de execução se a função for chamada com um argumento do tipo errado. strictFunctionTypes contravariância  Por exemplo, mesmo que um tipo de função seja capaz de lidar com strings e números, podemos atribuir a esse tipo uma função que só pode lidar com strings. Ainda podemos passar um número para essa função, mas receberemos um erro de tempo de execução.   function greet(x: string) { console.log("Hello, " + x.toLowerCase()); } type StringOrNumberFn = (y: string | number) => void; // Incorrect Assignment const func: StringOrNumberFn = greet; // TypeError: x.toLowerCase is not a function func(10);  Felizmente, habilitar a opção   corrige esse comportamento, e o compilador pode detectar esses erros em tempo de compilação, mostrando-nos uma mensagem detalhada da incompatibilidade de tipo nas funções. strictFunctionTypes   const func: StringOrNumberFn = greet; // ^ Type '(x: string) => void' is not assignable to type 'StringOrNumberFn'. // Types of parameters 'x' and 'y' are incompatible. // Type 'string | number' is not assignable to type 'string'. // Type 'number' is not assignable to type 'string'.  Inicialização da propriedade de classe   { "compilerOptions": { "strictPropertyInitialization": true } }  Por último, mas não menos importante, a opção   permite a verificação da inicialização de propriedade de classe obrigatória para tipos que não incluem   como um valor. strictPropertyInitialization undefined  Por exemplo, no código a seguir, o desenvolvedor esqueceu de inicializar a propriedade   . Por padrão, o TypeScript não detecta esse erro e pode ocorrer um problema no tempo de execução. email   class UserAccount { name: string; email: string; constructor(name: string) { this.name = name; // Forgot to assign a value to this.email } }  No entanto, quando a opção   estiver habilitada, o TypeScript destacará esse problema para nós. strictPropertyInitialization   email: string; // ^ Error: Property 'email' has no initializer and // is not definitely assigned in the constructor.  Assinaturas de índice seguras   { "compilerOptions": { "noUncheckedIndexedAccess": true } }  A opção   não faz parte do modo   , mas é outra opção que pode ajudar a melhorar a qualidade do código em seu projeto. Ele permite que a verificação de expressões de acesso ao índice tenham um tipo de retorno   ou   , o que pode evitar erros de tempo de execução. noUncheckedIndexedAccess strict null undefined  Considere o exemplo a seguir, onde temos um objeto para armazenar valores em cache. Em seguida, obtemos o valor de uma das chaves. Obviamente, não temos garantia de que o valor da chave desejada realmente exista no cache.  Por padrão, o TypeScript assumiria que o valor existe e tem o tipo   . Isso pode levar a um erro de tempo de execução. string   const cache: Record<string, string> = {}; const value = cache['key']; // ^? string console.log(value.toUpperCase()); // ^ TypeError: Cannot read properties of undefined  Habilitar a opção   no TypeScript requer a verificação das expressões de acesso ao índice para o tipo de retorno   , o que pode nos ajudar a evitar erros de tempo de execução. Isso também se aplica ao acesso a elementos em uma matriz. noUncheckedIndexedAccess undefined   const cache: Record<string, string> = {}; const value = cache['key']; // ^? string | undefined if (value) { console.log(value.toUpperCase()); }  Configuração recomendada  Com base nas opções discutidas, é altamente recomendável habilitar as opções   e   no arquivo   de seu projeto para segurança de tipo ideal. strict noUncheckedIndexedAccess tsconfig.json   { "compilerOptions": { "strict": true, "noUncheckedIndexedAccess": true, } }  Se você já ativou a opção   , considere remover as seguintes opções para evitar duplicar a opção   : strict strict: true   noImplicitAny   useUnknownInCatchVariables   strictBindCallApply   noImplicitThis   strictFunctionTypes   strictNullChecks   strictPropertyInitialization  Também é recomendável remover as seguintes opções que podem enfraquecer o sistema de tipos ou causar erros de tempo de execução:   keyofStringsOnly   noStrictGenericChecks   suppressImplicitAnyIndexErrors   suppressExcessPropertyErrors  Ao considerar e configurar cuidadosamente essas opções, você pode obter segurança de tipo ideal e uma melhor experiência do desenvolvedor em seus projetos TypeScript.  Conclusão  O TypeScript percorreu um longo caminho em sua evolução, melhorando constantemente seu compilador e sistema de tipos. No entanto, para manter a compatibilidade com versões anteriores, a configuração do TypeScript tornou-se mais complexa, com muitas opções que podem afetar significativamente a qualidade da verificação de tipos.  Ao considerar e configurar cuidadosamente essas opções, você pode obter segurança de tipo ideal e uma melhor experiência do desenvolvedor em seus projetos TypeScript. É importante saber quais opções ativar e remover de uma configuração de projeto.  Compreender as consequências de desabilitar certas opções permitirá que você tome decisões informadas para cada uma delas.  É importante ter em mente que a digitação estrita pode ter consequências. Para lidar efetivamente com a natureza dinâmica do JavaScript, você precisará ter um bom entendimento do TypeScript além de simplesmente especificar "número" ou "string" após uma variável.  Você precisará estar familiarizado com construções mais complexas e com o primeiro ecossistema de bibliotecas e ferramentas do TypeScript para resolver com mais eficácia os problemas relacionados a tipos que surgirão.  Como resultado, escrever código pode exigir um pouco mais de esforço, mas com base na minha experiência, esse esforço vale a pena para projetos de longo prazo.  Espero que você tenha aprendido algo novo com este artigo. Esta é a primeira parte de uma série. No próximo artigo, discutiremos como obter melhor segurança de tipos e qualidade de código aprimorando os tipos na biblioteca padrão do TypeScript. Fique ligado, e obrigado por ler!  Links Úteis   Referência TSConfig   Qualquer tipo   Nulo e Indefinido

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

This story will praise and/or roast a product, company, service, game, or anything else people like to review on the Internet.

Liberando o poder do TypeScript: principais considerações no tsconfig

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

Uma breve introdução à teoria do cérebro de Boltzmann

Guia do arquiteto para construir arquitetura de referência para um Datalake de IA/ML

Telegram: a ponte da Crypto Island para o continente

Modelo Bitcoin UTXO, alimentando um ecossistema único

Uma breve introdução à teoria do cérebro de Boltzmann

Guia do arquiteto para construir arquitetura de referência para um Datalake de IA/ML

Telegram: a ponte da Crypto Island para o continente

Modelo Bitcoin UTXO, alimentando um ecossistema único

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps