TypeScript afirma ser uma linguagem de programação fortemente tipada construída sobre JavaScript, fornecendo melhores ferramentas em qualquer escala. No entanto, inclui tipo, que muitas vezes pode entrar implicitamente em uma base de código e levar à perda de muitas das vantagens do TypeScript. o TypeScript any Este artigo explora maneiras de assumir o controle de tipo em projetos TypeScript. Prepare-se para liberar o poder do TypeScript, alcançando o máximo em segurança de tipo e melhorando a qualidade do código. any Desvantagens de usar qualquer um no TypeScript TypeScript fornece uma variedade de ferramentas adicionais para aprimorar a experiência e a produtividade do desenvolvedor: Ajuda a detectar erros no início do estágio de desenvolvimento. Oferece excelente preenchimento automático para editores de código e IDEs. Ele permite a refatoração fácil de grandes bases de código por meio de fantásticas ferramentas de navegação de código e refatoração automática. Ele simplifica a compreensão de uma base de código, fornecendo semântica adicional e estruturas de dados explícitas por meio de tipos. No entanto, assim que você começar a usar tipo em sua base de código, você perderá todos os benefícios listados acima. O type é uma brecha perigosa no sistema de tipos e usá-lo desativa todos os recursos de verificação de tipo, bem como todas as ferramentas que dependem da verificação de tipo. Como resultado, todos os benefícios do TypeScript são perdidos: erros são perdidos, editores de código tornam-se menos úteis e muito mais. any any Por exemplo, considere o seguinte exemplo: function parse(data: any) { return data.split(''); } // Case 1 const res1 = parse(42); // ^ TypeError: data.split is not a function // Case 2 const res2 = parse('hello'); // ^ any No código acima: Você perderá o preenchimento automático dentro da função . Quando você digita em seu editor, você não receberá sugestões corretas sobre os métodos disponíveis para . parse data. data No primeiro caso, há um erro porque passamos um número em vez de uma string. O TypeScript não consegue destacar o erro porque desativa a verificação de tipo. TypeError: data.split is not a function any No segundo caso, a variável também possui o tipo . Isso significa que um único uso de pode ter um efeito cascata em uma grande parte de uma base de código. res2 any any Usar é aceitável apenas em casos extremos ou para necessidades de prototipagem. Em geral, é melhor evitar o uso para aproveitar ao máximo o TypeScript. any any De onde vem qualquer tipo É importante estar ciente das fontes do tipo em uma base de código porque escrever explicitamente não é a única opção. Apesar de nossos melhores esforços para evitar o uso de tipo, às vezes ele pode entrar implicitamente em uma base de código. any any any Existem quatro fontes principais de tipo em uma base de código: any Opções do compilador em tsconfig. Biblioteca padrão do TypeScript. Dependências do projeto. Uso explícito de em uma base de código. any Já escrevi artigos sobre e para os dois primeiros pontos. Verifique-os se quiser melhorar a segurança de tipo em seus projetos. Considerações Chave em tsconfig Melhorando Tipos de Biblioteca Padrão Desta vez, focaremos em ferramentas automáticas para controlar a aparência de tipo em uma base de código. any Etapa 1: usando ESLint é uma ferramenta popular de análise estática usada por desenvolvedores web para garantir melhores práticas e formatação de código. Ele pode ser usado para impor estilos de codificação e localizar códigos que não atendem a determinadas diretrizes. ESLint ESLint também pode ser usado com projetos TypeScript, graças ao plugin . Muito provavelmente, este plugin já foi instalado no seu projeto. Mas se não, você pode seguir o . typesctipt-eslint guia oficial de primeiros passos A configuração mais comum para é a seguinte: typescript-eslint module.exports = { extends: [ 'eslint:recommended', 'plugin:@typescript-eslint/recommended', ], plugins: ['@typescript-eslint'], parser: '@typescript-eslint/parser', root: true, }; Essa configuração permite que entenda o TypeScript no nível da sintaxe, permitindo que você escreva regras eslint simples que se aplicam a tipos escritos manualmente em um código. Por exemplo, você pode proibir o uso explícito de . eslint any A predefinição contém um conjunto cuidadosamente selecionado de regras ESLint destinadas a melhorar a correção do código. Embora seja recomendado usar a predefinição inteira, para os fins deste artigo, nos concentraremos apenas na regra . recommended no-explicit-any não-explícito-qualquer O modo estrito do TypeScript impede o uso de implícito, mas não impede que seja usado explicitamente. A regra ajuda a proibir a gravação manual qualquer lugar em uma base de código. any any no-explicit-any any // ❌ Incorrect function loadPokemons(): any {} // ✅ Correct function loadPokemons(): unknown {} // ❌ Incorrect function parsePokemons(data: Response<any>): Array<Pokemon> {} // ✅ Correct function parsePokemons(data: Response<unknown>): Array<Pokemon> {} // ❌ Incorrect function reverse<T extends Array<any>>(array: T): T {} // ✅ Correct function reverse<T extends Array<unknown>>(array: T): T {} O objetivo principal desta regra é evitar o uso de em toda a equipe. Este é um meio de fortalecer o acordo da equipe de que o uso de no projeto é desencorajado. any any Este é um objetivo crucial porque mesmo um único uso de pode ter um impacto em cascata em uma parte significativa da base de código devido à . No entanto, isso ainda está longe de alcançar a segurança máxima do tipo. any inferência de tipo Por que nada explícito não é suficiente Embora tenhamos lidado com explicitamente usado, ainda há muitos implícitos nas dependências de um projeto, incluindo pacotes npm e a biblioteca padrão do TypeScript. any any Considere o código a seguir, que provavelmente será visto em qualquer projeto: const response = await fetch('https://pokeapi.co/api/v2/pokemon'); const pokemons = await response.json(); // ^? any const settings = JSON.parse(localStorage.getItem('user-settings')); // ^? any Ambas as variáveis e receberam implicitamente tipo. Nem nem o modo estrito do TypeScript nos avisarão neste caso. Ainda não. pokemons settings any no-explicit-any Isso acontece porque os tipos para e vêm da biblioteca padrão do TypeScript, onde esses métodos possuem uma anotação explícita. Ainda podemos especificar manualmente um tipo melhor para nossas variáveis, mas existem quase 1.200 ocorrências de na biblioteca padrão. É quase impossível lembrar de todos os casos em que pode entrar furtivamente em nossa base de código a partir da biblioteca padrão. response.json() JSON.parse() any any any O mesmo vale para dependências externas. Existem muitas bibliotecas mal digitadas no npm, e a maioria ainda é escrita em JavaScript. Como resultado, o uso de tais bibliotecas pode facilmente levar a muitos implícitos em uma base de código. any Geralmente, ainda existem muitas maneiras de entrar furtivamente em nosso código. any Estágio 2: Aprimorando os recursos de verificação de tipo Idealmente, gostaríamos de ter uma configuração no TypeScript que fizesse o compilador reclamar de qualquer variável que tenha recebido tipo por qualquer motivo. Infelizmente, tal configuração não existe atualmente e não se espera que seja adicionada. any Podemos conseguir esse comportamento usando o modo de verificação de tipo do plugin . Este modo funciona em conjunto com TypeScript para fornecer informações completas de tipo do compilador TypeScript para regras ESLint. Com essas informações, é possível escrever regras ESLint mais complexas que essencialmente estendem os recursos de verificação de tipo do TypeScript. Por exemplo, uma regra pode encontrar todas as variáveis com tipo, independentemente de como foi obtida. typescript-eslint any any Para usar regras de reconhecimento de tipo, você precisa ajustar ligeiramente a configuração do ESLint: module.exports = { extends: [ 'eslint:recommended', - 'plugin:@typescript-eslint/recommended', + 'plugin:@typescript-eslint/recommended-type-checked', ], plugins: ['@typescript-eslint'], parser: '@typescript-eslint/parser', + parserOptions: { + project: true, + tsconfigRootDir: __dirname, + }, root: true, }; Para habilitar a inferência de tipo para , adicione à configuração do ESLint. Em seguida, substitua a predefinição por . A última predefinição adiciona cerca de 17 novas regras poderosas. Para os fins deste artigo, nos concentraremos em apenas 5 deles. typescript-eslint parserOptions recommended recommended-type-checked argumento sem insegurança A regra procura chamadas de função nas quais uma variável do tipo é passada como parâmetro. Quando isso acontece, a verificação de tipo é perdida e todos os benefícios da digitação forte também são perdidos. no-unsafe-argument any Por exemplo, vamos considerar uma função que requer um objeto como parâmetro. Suponha que recebemos JSON, analisamos e obtemos tipo. saveForm any // ❌ Incorrect function saveForm(values: FormValues) { console.log(values); } const formValues = JSON.parse(userInput); // ^? any saveForm(formValues); // ^ Unsafe argument of type `any` assigned // to a parameter of type `FormValues`. Quando chamamos a função com este parâmetro, a regra sinaliza-a como insegura e exige que especifiquemos o tipo apropriado para a variável . saveForm no-unsafe-argument value Esta regra é poderosa o suficiente para inspecionar profundamente estruturas de dados aninhadas em argumentos de função. Portanto, você pode ter certeza de que passar objetos como argumentos de função nunca conterá dados não digitados. // ❌ Incorrect saveForm({ name: 'John', address: JSON.parse(addressJson), // ^ Unsafe assignment of an `any` value. }); A melhor maneira de corrigir o erro é usar do TypeScript ou uma biblioteca de validação como ou . Por exemplo, vamos escrever a função que restringe o tipo preciso de dados analisados. o estreitamento de tipo Zod Superstruct parseFormValues // ✅ Correct function parseFormValues(data: unknown): FormValues { if ( typeof data === 'object' && data !== null && 'name' in data && typeof data['name'] === 'string' && 'address' in data && typeof data.address === 'string' ) { const { name, address } = data; return { name, address }; } throw new Error('Failed to parse form values'); } const formValues = parseFormValues(JSON.parse(userInput)); // ^? FormValues saveForm(formValues); Observe que é permitido passar tipo como argumento para uma função que aceita , pois não há preocupações de segurança associadas a isso. any unknown Escrever funções de validação de dados pode ser uma tarefa tediosa, especialmente quando se lida com grandes quantidades de dados. Portanto, vale a pena considerar a utilização de uma biblioteca de validação de dados. Por exemplo, com Zod, o código ficaria assim: // ✅ Correct import { z } from 'zod'; const schema = z.object({ name: z.string(), address: z.string(), }); const formValues = schema.parse(JSON.parse(userInput)); // ^? { name: string, address: string } saveForm(formValues); atribuição não-insegura A regra procura atribuições de variáveis nas quais um valor tenha tipo. Tais atribuições podem induzir o compilador a pensar que uma variável tem um determinado tipo, enquanto os dados podem, na verdade, ter um tipo diferente. no-unsafe-assignment any Considere o exemplo anterior de análise JSON: // ❌ Incorrect const formValues = JSON.parse(userInput); // ^ Unsafe assignment of an `any` value Graças à regra , podemos capturar tipo antes mesmo de passar para outro lugar. A estratégia de fixação permanece a mesma: podemos usar o estreitamento de tipo para fornecer um tipo específico ao valor da variável. no-unsafe-assignment any formValues // ✅ Correct const formValues = parseFormValues(JSON.parse(userInput)); // ^? FormValues acesso sem membro inseguro e chamada sem insegurança Essas duas regras são acionadas com muito menos frequência. No entanto, com base na minha experiência, eles são realmente úteis quando você tenta usar dependências de terceiros mal digitadas. A regra nos impede de acessar as propriedades do objeto se uma variável tiver o tipo , pois pode ser ou . no-unsafe-member-access any null undefined A regra nos impede de chamar uma variável com tipo como uma função, pois pode não ser uma função. no-unsafe-call any Vamos imaginar que temos uma biblioteca de terceiros mal digitada chamada : untyped-auth // ❌ Incorrect import { authenticate } from 'untyped-auth'; // ^? any const userInfo = authenticate(); // ^? any ^ Unsafe call of an `any` typed value. console.log(userInfo.name); // ^ Unsafe member access .name on an `any` value. O linter destaca dois problemas: Chamar a função pode ser inseguro, pois podemos esquecer de passar argumentos importantes para a função. authenticate Ler a propriedade do objeto não é seguro, pois será se a autenticação falhar. name userInfo null A melhor maneira de corrigir esses erros é considerar o uso de uma biblioteca com uma API fortemente tipada. Mas se isso não for uma opção, você mesmo poderá . Um exemplo com os tipos de biblioteca fixos seria assim: aumentar os tipos de biblioteca // ✅ Correct import { authenticate } from 'untyped-auth'; // ^? (login: string, password: string) => Promise<UserInfo | null> const userInfo = await authenticate('test', 'pwd'); // ^? UserInfo | null if (userInfo) { console.log(userInfo.name); } sem retorno inseguro A regra ajuda a não retornar acidentalmente tipo de uma função que deveria retornar algo mais específico. Esses casos podem induzir o compilador a pensar que um valor retornado tem um determinado tipo, enquanto os dados podem, na verdade, ter um tipo diferente. no-unsafe-return any Por exemplo, suponha que temos uma função que analisa JSON e retorna um objeto com duas propriedades. // ❌ Incorrect interface FormValues { name: string; address: string; } function parseForm(json: string): FormValues { return JSON.parse(json); // ^ Unsafe return of an `any` typed value. } const form = parseForm('null'); console.log(form.name); // ^ TypeError: Cannot read properties of null A função pode levar a erros de execução em qualquer parte do programa onde for utilizada, pois o valor analisado não é verificado. A regra evita tais problemas de tempo de execução. parseForm no-unsafe-return É fácil corrigir isso adicionando validação para garantir que o JSON analisado corresponda ao tipo esperado. Vamos usar a biblioteca Zod desta vez: // ✅ Correct import { z } from 'zod'; const schema = z.object({ name: z.string(), address: z.string(), }); function parseForm(json: string): FormValues { return schema.parse(JSON.parse(json)); } Uma nota sobre desempenho O uso de regras de verificação de tipo acarreta uma penalidade de desempenho para o ESLint, pois ele deve invocar o compilador do TypeScript para inferir todos os tipos. Essa lentidão é perceptível principalmente ao executar o linter em ganchos de pré-confirmação e em CI, mas não é perceptível ao trabalhar em um IDE. A verificação de tipo é executada uma vez na inicialização do IDE e, em seguida, atualiza os tipos conforme você altera o código. É importante notar que apenas inferir os tipos funciona mais rápido do que a invocação normal do compilador . Por exemplo, em nosso projeto mais recente com cerca de 1,5 milhão de linhas de código TypeScript, a verificação de tipo por meio leva cerca de 11 minutos, enquanto o tempo adicional necessário para que as regras de reconhecimento de tipo do ESLint sejam inicializadas é de apenas cerca de 2 minutos. tsc tsc Para nossa equipe, a segurança adicional fornecida pelo uso de regras de análise estática com reconhecimento de tipo vale a pena. Em projetos menores, esta decisão é ainda mais fácil de tomar. Conclusão Controlar o uso de em projetos TypeScript é crucial para obter segurança de tipo e qualidade de código ideais. Ao utilizar o plugin , os desenvolvedores podem identificar e eliminar quaisquer ocorrências de tipo em sua base de código, resultando em uma base de código mais robusta e de fácil manutenção. any typescript-eslint any Ao usar regras eslint com reconhecimento de tipo, qualquer aparecimento da palavra-chave em nossa base de código será uma decisão deliberada, e não um erro ou descuido. Essa abordagem nos protege de usar código em nosso próprio código, bem como na biblioteca padrão e em dependências de terceiros. any any No geral, um linter com reconhecimento de tipo nos permite atingir um nível de segurança de tipo semelhante ao de linguagens de programação de tipo estaticamente, como Java, Go, Rust e outras. Isso simplifica muito o desenvolvimento e a manutenção de grandes projetos. Espero que você tenha aprendido algo novo com este artigo. Obrigado por ler! Links Úteis Biblioteca: typescript-eslint Artigo: Principais considerações no tsconfig Artigo: Melhorando os tipos de biblioteca padrão Documentos: Estreitamento de tipo em TypeScript Documentos: Inferência de tipo em TypeScript Biblioteca: Zod Biblioteca: Superestrutura

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

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

Este áudio é produzido no idioma original da história!

Tornando o TypeScript verdadeiramente "fortemente digitado"

Muito longo; Para ler

@nodge

Credibility

HISTÓRIAS RELACIONADAS