Introdução: por que o TypeScript morde os iniciantes, ou como não fracassar no primeiro projeto
\n\nVocê já sentiu que o TypeScript é como um professor rigoroso que dá notas baixas por cada detalhe? Se sim — bem-vindo ao clube. Cada segundo iniciante que migra do JavaScript para o TypeScript comete os mesmos erros. E isso é normal: o TypeScript é realmente mais difícil, exige disciplina e compreensão de tipos.
\n\nMas há uma boa notícia: a maioria dos erros ao aprender TypeScript pode ser prevista e evitada. Neste artigo, reuni os 7 erros mais comuns que desenvolvedores iniciantes cometem. Analisaremos cada erro com exemplos de código, explicaremos por que é ruim e mostraremos como fazer corretamente.
\n\nSe você está começando a aprender TypeScript ou já cometeu alguns erros — este artigo economizará horas de depuração e estresse. Vamos lá!
\n\nErro nº1: Uso descontrolado de any (a fonte de todos os males)
\n\nO que os iniciantes fazem
\nO erro mais comum entre quem estuda TypeScript é escrever any em todo lugar. Parece: "Ah, não especifiquei o tipo, mas o código funciona!".
// ❌ Ruim: any destrói todo o benefício do TypeScript\nfunction processData(data: any) {\n console.log(data.name.toUpperCase());\n return data.price * 2;\n}\n\nconst result = processData({ name: "notebook", price: 500 });\n// Funciona... até você passar null\nprocessData(null); // Erro em tempo de execução!\n\nPor que isso é um erro
\nany é um buraco negro do TypeScript. Quando você escreve any, está dizendo ao compilador: "Sai daqui, eu me viro". E ele sai. Você perde autocomplete, verificação de tipos e proteção contra erros bobos. O TypeScript se transforma de volta em JavaScript — com todas as suas falhas.
Como corrigir
\nUse tipos específicos. Se o tipo for desconhecido antecipadamente — unknown é seu amigo. Ele forçará você a verificar os dados antes de usá-los.
// ✅ Bom: tipos específicos e unknown\nfunction processData(data: { name: string; price: number }) {\n console.log(data.name.toUpperCase());\n return data.price * 2;\n}\n\n// Ou se o tipo realmente for desconhecido:\nfunction safeProcess(data: unknown) {\n if (typeof data === 'object' && data !== null && 'name' in data) {\n // Agora o TypeScript sabe que data é um objeto com o campo name\n console.log((data as { name: string }).name);\n }\n}\n\nDica: Ative a regra no-explicit-any no ESLint — ela impedirá o uso de any sem um motivo válido.
Erro nº2: Ignorar o strict mode (ou "por que tudo funciona, mas não como esperado")
\n\nO que os iniciantes fazem
\nMuitos desenvolvedores iniciantes ao aprender TypeScript desativam o modo estrito no tsconfig.json ou nem o ativam. Tipo, "já serve, menos erros de compilação".
// ❌ Ruim: strict: false\n// tsconfig.json\n{\n "compilerOptions": {\n "strict": false, // Erro!\n "noImplicitAny": false,\n "strictNullChecks": false\n }\n}\n\n// Agora este código compila sem erros:\nfunction greet(name: string | null) {\n console.log(name.toUpperCase()); // Potencial null!\n}\ngreet(null); // Erro em tempo de execução: Cannot read properties of null\n\nPor que isso é um erro
\nSem o modo estrito, o TypeScript perde metade de sua força. Você não recebe avisos sobre potenciais null e undefined, não verifica tipos de argumentos — e acaba pegando bugs em produção.
Como corrigir
\nSempre ative strict: true. Isso ativa todas as verificações estritas de uma vez.
// ✅ Bom: strict: true\n{\n "compilerOptions": {\n "strict": true,\n "target": "ES2020",\n "module": "ESNext"\n }\n}\n\n// Agora o TypeScript forçará você a tratar o null:\nfunction g