stamatios
← Voltar ao feed
Quatro caixas pequenas unidas numa caixa de envio robusta, consolidação de pacotes e plugin S3 do Uppy 6.0
Dev & Engenharia

Uppy 6.0 consolida pacotes e reescreve plugin de S3

resumo de ~3 min

O que muda no Uppy 6.0

O Uppy 6.0, lançado em 31 de agosto de 2026 pela equipe do uploader de arquivos mantido pela Transloadit, é uma versão de consolidação: em vez de adicionar recursos, o foco foi simplificar pacotes e reescrever o plugin de S3. Seis pacotes recebem bump major: @uppy/core, @uppy/companion, @uppy/aws-s3, @uppy/tus, @uppy/components e uppy. Quem usa o meta-pacote uppy ou o bundle via CDN não precisa de mudanças relevantes, e há um guia de migração para os demais casos.

Reescrita do @uppy/aws-s3

O plugin antigo exigia a implementação de até oito callbacks - getUploadParameters, getTemporarySecurityCredentials, uploadPartBytes, signPart, createMultipartUpload, listParts, abortMultipartUpload e completeMultipartUpload - e não indicava quais eram necessários, dependendo de multipart, do uso de Companion e de onde a assinatura ocorria. Isso gerava combinações plausíveis que falhavam silenciosamente. A conclusão da equipe foi que o problema era o formato da API, e não bugs pontuais.

A nova versão oferece três modos de assinatura, dos quais se escolhe exatamente um: getCredentials (assinatura no cliente com SigV4), signRequest (signer próprio) e companionEndpoint (Companion assina). O Companion não é mais obrigatório no caminho de dados, e o plugin conversa com qualquer serviço compatível com S3 - Cloudflare R2, MinIO e DigitalOcean Spaces funcionam sem código específico de provedor, e o AWS também deixa de ser requisito.

A reescrita corrigiu vários bugs de confiabilidade antigos: retries com backoff, expiração de credenciais, detecção de offline e condições de corrida em pause/resume em uploads multipart. O plugin agora é testado em CI contra uma instância real de MinIO em vez de mocks, o que permitiu detectar boa parte desses problemas.

Um único núcleo

Os pacotes @uppy/utils, @uppy/store-default, @uppy/companion-client e @uppy/provider-views deixam de ser publicados separadamente; seu código passa a viver dentro de @uppy/core como subpath exports. A mudança resolve um problema real: esses quatro pacotes ficavam como subdependências de todos os plugins, e um lockfile podia - e regularmente fazia - fixar uma versão antiga enquanto @uppy/core avançava, deixando duas versões de @uppy/utils na mesma árvore; para o usuário, o sintoma era "Uppy quebrado". Como todo plugin já depende de @uppy/core, agora existe uma única fonte de verdade, eliminando essa categoria de bugs.

A remoção da fronteira entre pacotes também permitiu que tipos co-dependentes se referenciem diretamente: os substitutos mantidos à mão CompanionClientProvider e CompanionClientSearchProvider foram removidos, e a recomendação é importar Provider de @uppy/core/companion-client.

Transloadit e recuperação de uploads

O @uppy/transloadit agora expõe o status da assembly no estado do plugin, permitindo construir interfaces de progresso próprias. O campo assemblyStatus segue a assembly ativa pelas transições e é limpo quando não há assembly ativa; lastAssemblyStatus preserva o resultado da execução anterior para a interface não ficar em branco entre uploads.

Em paralelo, o @uppy/golden-retriever passou a armazenar metadados de arquivos em IndexedDB, com fallback para localStorage onde IndexedDB não está disponível. O armazenamento antigo, só em localStorage, esbarrava em limites de cota em assemblies grandes - justamente os uploads mais valiosos de recuperar não eram recuperados. Agora, assemblies grandes são restauradas.

Companion, TypeScript e cadeia de suprimentos

Os tokens OAuth do Companion agora trafegam por WebSocket em vez de window.opener. A mudança quebra nos dois lados: @uppy/core exige o Companion mais recente e companion.socket() recebe companionOptions como segundo argumento. Quem faz self-host deve atualizar as duas pontas junto; quem usa o Companion hospedado não precisa fazer nada. O Companion também roda em Express 5 - montá-lo como middleware em um app Express 4 deixa de funcionar. Além disso, o Companion foi portado para TypeScript, e a equipe pede que possíveis regressões sejam reportadas.

No endurecimento da cadeia de suprimentos, após um ano ruim para o ecossistema npm: pacotes precisam ter ao menos sete dias de idade para o Yarn resolvê-los, atualizações do Dependabot têm cooldown correspondente e toda GitHub Action de terceiros é fixada a um SHA de commit. Atualizações de segurança ignoram o cooldown deliberadamente. Nada disso muda a API escrita pelo usuário.

Depreciações e ajustes finais

@uppy/instagram foi removido - a API do Instagram foi desativada em 2024 e o plugin parou de funcionar. Os quatro pacotes absorvidos por @uppy/core têm lançamentos futuros descontinuados no npm, embora os existentes permaneçam. O CSS de provedores migrou para @uppy/core/provider-views/css/style.min.css, com pouco impacto prático já que normalmente vem embutido no CSS do @uppy/dashboard.

O @uppy/tus não aborta mais a requisição quando ocorre um erro: o status e o corpo do servidor agora chegam a upload-error e file.response em vez de aparecer como status 0, o que exige revisão de código de tratamento de erros escrito contra o comportamento antigo. Há ainda suporte a Angular 22 em @uppy/angular, o botão "My Device" do Dashboard respeita fileManagerSelectionType, atualizações de locale incluindo norueguês Bokmål e um total de 58 pull requests na versão. A recomendação final é seguir o guia de migração e abrir issues se algo quebrar.