Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Muita gente fica na dúvida se o VSCode realmente está fazendo o seu trabalho direito na hora de mostrar erros TypeScript, especialmente em projetos React usando create-react-app.
A maior pegadinha é que, por padrão, o VSCode só exibe os erros nas abas de arquivos que estão abertos na hora. Isso pode fazer a gente passar batido em erros que só aparecem na compilação, e aí só descobre na hora de rodar o app.
A solução mais prática, e que ajuda muito na rotina, é configurar o TypeScript para fazer a verificação contínua de todo o projeto, mesmo com os arquivos fechados. Sem esse critério, a solução pode parecer simples no começo e cara no suporte. O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco.
Dá pra fazer isso usando o comando "tsc --watch" no terminal, ou melhor ainda, ajustar o seu workspace para rodar essa verificação de forma automática ao abrir ou salvar arquivos. O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco. Por isso, o recorte precisa considerar manutenção, validação e caminho de volta. Esse contexto ajuda a separar ganho real de novidade difícil de sustentar.
Assim, o código fica mais seguro e você consegue corrigir erros antes mesmo de rodar o app.
Quem já tentou alguma configuração diferente ou usa algum plugin que ajude nisso? Acho que a galera que trabalha com TS em React vai agradecer essa dica. Esse contexto ajuda a separar ganho real de novidade difícil de sustentar. A decisão fica mais saudável quando o time consegue medir o impacto depois. Sem esse critério, a solução pode parecer simples no começo e cara no suporte. O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco. Por isso, o recorte precisa considerar manutenção, validação e caminho de volta.
Como assim? eu acho que o problema maior é a quantidade de arquivos que fica no projeto. Se não tiver uma boa estratégia de divisão, o tsc watch pode ficar pesado demais.
aham, ajudou pra cacete quando o time mede o antes e depois. Sem isso, vira só sensação boa de demo.
No meu time, a gente sempre roda o tsc watch em background, assim não perde erro. Mas é bom lembrar que isso aumenta o consumo, né? resolveu lindamente
Pois é, o ideal é integrar com o pipeline também, assim a checagem não fica só na IDE. Mas a dica do watch é massa pra acelerar o feedback.
Concordo, Guto. No meu caso, uso o plugin do VSCode pra rodar a verificação contínua na background, ajuda demais na hora do deploy, pq já fica tudo no radar.