TypeScript no WordPress

TypeScript WordPress é a aplicação do TypeScript — superset do JavaScript com tipagem estática — em projetos WordPress modernos: plugins customizados, blocos Gutenberg, projetos headless com Next.js ou Astro consumindo a REST API. Traz segurança em tempo de desenvolvimento, autocomplete poderoso, refatoração confiável e documentação implícita via tipos. Em equipes que escrevem JavaScript pesado para WordPress, virou padrão; em projetos pontuais, ainda é decisão a justificar pelo overhead de setup.

O que é TypeScript

TypeScript é uma linguagem criada pela Microsoft em 2012, mantida open-source no GitHub, que estende o JavaScript adicionando sistema de tipos estáticos. Você escreve TypeScript, o compilador (tsc) checa os tipos em tempo de desenvolvimento e gera JavaScript puro pronto para rodar no navegador ou em Node.js. Não é uma linguagem alternativa, é JavaScript turbinado.

A vantagem central é detectar erros antes da execução. Em JavaScript puro, você só descobre que passou string onde esperava número quando o código quebra em runtime. Em TypeScript, o compilador acusa o erro durante o desenvolvimento, antes mesmo de testar no navegador. Em projetos médios e grandes, isso salva semanas de bug-hunting acumulado.

O TypeScript ganhou tração massiva a partir de 2018 e hoje é o padrão em frameworks modernos. Next.js, Remix, Nuxt, SvelteKit, todos suportam TypeScript de fábrica. Bibliotecas populares — React, Vue, lodash, axios — já distribuem suas próprias definições de tipos. Em 2024, TypeScript é a primeira escolha em qualquer projeto JavaScript sério novo.

No mundo WordPress, TypeScript é menos universal porque a base ainda é PHP. Mas em todo lugar onde JavaScript pesa — blocos Gutenberg, frontends headless, plugins com painéis React — TypeScript ganhou espaço. O próprio Gutenberg core do WordPress migrou parte do código para TypeScript a partir de 2023.

Vantagens do TypeScript em WP

A primeira vantagem é confiabilidade. Quando você define que renderBlock recebe { title: string, content: string }, o compilador garante em build que ninguém vai chamar a função com parâmetro errado. Em JavaScript, esse contrato vive na cabeça do programador; em TypeScript, vira garantia checada por máquina.

Autocomplete em IDE é a segunda vantagem prática que dispara produtividade. VSCode com TypeScript ativo entrega autocomplete preciso para todos os métodos do WordPress JS API: wp.blocks, wp.element, wp.components, wp.data. Você digita o ponto, ele lista as opções válidas. Em vez de consultar documentação a cada função, o editor é a documentação.

Refatoração ganha confiança total. Renomear uma função em projeto JavaScript grande exige busca textual com risco de erro; renomear em TypeScript é seguro porque o compilador checa todos os usos. Em projetos longos, esse ganho cresce exponencialmente — código TypeScript envelhece muito melhor.

Documentação implícita é a quarta vantagem. Quando você lê um arquivo TypeScript, os tipos comunicam o contrato sem precisar de docstring. function getPost(id: number): Promise<Post | null> diz tudo que importa: aceita número, retorna Promise de Post ou null. JavaScript precisaria de comentário para passar a mesma informação.

TypeScript no Gutenberg

O ecossistema Gutenberg WordPress oferece suporte robusto a TypeScript. O package @wordpress/scripts, padrão para build de blocos, aceita TypeScript nativamente desde a versão 19. Basta configurar o tsconfig.json e renomear arquivos .js para .ts ou .tsx — o build entende e compila.

O package @wordpress/blocks e os principais pacotes do Gutenberg (block-editor, components, data, element) já vêm com tipos TypeScript embutidos. Quando você escreve um bloco customizado, autocomplete entrega todas as opções válidas para registerBlockType(), BlockEdit, BlockSave. Erros de configuração de bloco são pegos em build, não em runtime.

Para plugins que usam React no painel admin, TypeScript turbina ainda mais a experiência. Combinando React com tipos completos do React no WordPress, você pega erros de props incorretas, hooks usados errado, dispatch com payload inválido — tudo durante o desenvolvimento.

Boas práticas em projetos Gutenberg-TypeScript: definir interfaces para os attributes do bloco logo no início, tipar callbacks de Inspector Controls, usar generics nos hooks de useSelect e useDispatch. Combinado com Gutenberg moderno, essa stack entrega blocos previsíveis, manuteníveis e escaláveis para times grandes.

Setup TypeScript em projeto WordPress

O caminho mais simples para começar é via @wordpress/scripts em um plugin novo. Crie a pasta do plugin, rode npm init, instale npm install –save-dev @wordpress/scripts typescript. Adicione um tsconfig.json mínimo apontando para src/, configure scripts no package.json (build, start) e mova seu código JS para src com extensão .ts.

O tsconfig.json para projeto WordPress costuma ser razoavelmente simples. Target ES2020 ou ES2022, module ESNext, jsx react, strict true, esModuleInterop true. O wp-scripts cuida do bundling via webpack, do transpiling via babel, e do output em build/. Você escreve TypeScript, ele entrega JavaScript pronto para o WordPress carregar via wp_enqueue_script.

Para projetos headless onde o WordPress só fornece dados via REST API, TypeScript brilha ainda mais. Defina interfaces para os recursos do WordPress (WPPost, WPCategory, WPMedia) e use em todo o frontend. Bibliotecas como @wp-types/api entregam essas interfaces prontas para a API REST padrão. Para projetos com Next.js no WordPress, esse padrão é praticamente obrigatório.

Em projetos longos, TypeScript exige disciplina. Tipos que viram any no primeiro problema viram acúmulo de dívida técnica. Configure o eslint para alertar sobre any implícito, mantenha tipos restritivos, use type guards para validar dados de fora (REST API responses, props de URL). Disciplina aqui paga em manutenção barata por anos.

Para projetos que dependem de stack moderna conectando WordPress como CMS a frontends em TypeScript, a FULL Services entrega infraestrutura WordPress preparada para integrações headless: REST API ajustada, JWT authentication configurável, CORS adequado, performance que sustenta requisições constantes do frontend Node ou edge. Os planos da FULL cobrem desde sites simples até projetos modernos com TypeScript e WordPress headless rodando em produção.