Eu sou @nyaomaru, um engenheiro frontend que recentemente migrou o setup de build do is-kit de tsup para tsdown. Inicialmente, a mudança parecia simples, mas revelou um problema interessante.
A Migração da Configuração
A migração da configuração foi pequena. O principal desafio foi preservar o contrato do pacote, que é crucial para a compatibilidade do código.
O Problema
O primeiro build com tsdown terminou com sucesso, mas alterou silenciosamente arquivos que já faziam parte do contrato público do pacote. Isso levantou a questão de como manter a integridade do pacote.
Preservando o Contrato Público
Para manter a integridade do pacote, precisamos preservar o comportamento ESM/CJS existente, compatibilidade das declarações, conjunto de exports e banner das declarações. O código-fonte não é o contrato aqui; o pacote npm empacotado é.
A Migração Parecia Trivial
Substituir tsup por tsdown e ajustar o pacote para evitar interpretações ambíguas foi quase trivial. No entanto, a migração alterou os nomes de arquivos, quebrando a compatibilidade.
Corrigindo o Contrato Público
Para corrigir o contrato público, usei outExtensions para preservar os nomes de arquivos existentes. Isso garantiu que os arquivos continuassem a ser gerados corretamente.
Verificando o Pacote Publicado
Para garantir que o pacote publicado continuaria a funcionar corretamente, fiz um smoke test do pacote empacotado. Isso permitiu que eu verificasse se o pacote publicado estava funcionando corretamente.
Conclusão
A migração do is-kit de tsup para tsdown mostrou que a preservação do contrato público é crucial. Isso exigiu uma abordagem cuidadosa para garantir que o pacote continuaria a ser compatível com os consumidores.
Tags
- TypeScript
- tsdown
- tsup
- Migração
- Biblioteca OSS
- Compatibilidade
- Build System
- Módulos ESM/CJS