Node.js 26 leva debounce, throttle e parsing de PKCS#12 para o core

A versão 26.10.0 do Node.js↳Node.js45 conteúdosComo criar aplicações console em Node.jsDev (Back & Front) · fev 2025Entendendo o ciclo de publicação do Node.jsDev (Back & Front) · fev 2020Nodejs por baixo dos panosDev (Back & Front) · jul 2019Ver tudo em Dev (Back & Front) → colocou debounce, throttle e um parser de certificados PKCS#12 direto no core, e a LTS 26 Lithium já está em suporte ativo até abril de 2029.

O Node.js 26.10.0 incorporou ao core um grupo de utilitários que, até então, só existiam como dependências de terceiros. O node:util ganhou debounce() e throttle(), o node:crypto passou a expor parsePKCS12() para ler certificados .p12 e .pfx, e o sistema de arquivos virtual experimental (VFS) foi estendido ao node:ffi. A versão faz parte da sequência de releases da linha Current que antecedeu a entrada do Node.js 26 em Active LTS, sob o codinome "Lithium".

São mudanças pequenas em número de linhas, mas que atacam diretamente um dos hábitos mais comuns do ecossistema JavaScript: vendorizar utilitários de terceiros para tarefas triviais. Rate limiting e parsing de certificados estão nessa lista há anos.

Debounce e throttle sem lodash

util.debounce() e util.throttle() foram implementados por James M Snell em um único pull request. Segundo a reportagem da InfoQ, Matteo Collina comentou que usa esses utilitários em praticamente todo app que escreve:

Essencialmente todo app.

Matteo Collinaessentially every app

Até aqui, cobrir esse caso de uso significava instalar o lodash inteiro só para usar _.debounce, ou adicionar o pacote throttle-debounce como dependência direta. Com as novas funções no core, esse vendor sai do package.json:

const { debounce } = require('node:util');

const salvarRascunho = debounce(() => persistirEstado(), 300, { leading: true });

A implementação não foi direta. Os contribuidores ljharb e bakkot apontaram um problema de design: um AbortSignal só transita para o estado abortado uma vez, o que é inadequado para uma função pensada para ser chamada repetidamente ao longo da vida de uma aplicação. Snell reformulou o sinal para cancelar todas as invocações futuras e adicionou a opção leading, que permite disparar a primeira chamada imediatamente em vez de esperar o fim do intervalo.

O mesmo patch também trouxe util.markPromiseAsHandled(), um mecanismo explícito para autores de frameworks sinalizarem ao runtime que uma promise já foi tratada. A função ataca uma fonte recorrente de confusão em torno dos avisos de unhandled rejection, que hoje muitas vezes disparam falsos positivos quando o framework trata o erro por um caminho que o V8 não enxerga.

parsePKCS12() fecha uma lacuna antiga

O Node.js já sabia ler bundles .p12 e .pfx internamente, usados na opção pfx do módulo TLS, mas nunca expôs esse resultado para o código JavaScript do usuário. A nova crypto.parsePKCS12() muda isso: ela envolve as funções d2i_PKCS12_bio() e PKCS12_parse() da OpenSSL e devolve um objeto com os campos privateKey, certificate e additionalCertificates.

const { parsePKCS12 } = require('node:crypto');
const fs = require('node:fs');

const { privateKey, certificate, additionalCertificates } = parsePKCS12(
  fs.readFileSync('certificado.p12')
);

A contribuição foi a primeira participação significativa de Brian Muenzenmeyer tocando código C++ do core, refinada com a ajuda de Filip Skokan. Na prática, ela elimina duas rotas comuns para esse problema: chamar o binário openssl via child_process ou depender de pacotes como o node-forge só para extrair chave privada e certificado de um arquivo .pfx.

Para quem trabalha com integrações que exigem certificado digital no Brasil, isso é mais relevante do que parece à primeira vista. Certificados e-CNPJ e e-CPF usados em NF-e, eSocial e em diversas integrações com órgãos públicos costumam ser distribuídos justamente no formato .pfx. Remover a dependência de um binário OpenSSL instalado no ambiente ou de uma biblioteca JS de terceiros simplifica o deploy desses serviços em containers e funções serverless.

VFS chega ao node:ffi

O sistema de arquivos virtual experimental do Node.js também ganhou terreno. Matteo Collina e Philipp Dunkel estenderam o node:ffi para carregar bibliotecas nativas diretamente de um VFS montado, reaproveitando o mesmo truque de memfd anônimo autolimpo que os addons nativos já usam no Linux↳Linux34 conteúdosKali Linux em um Servidor VPS: como, quando e por que usar?DevSecOps · dez 2024Construindo um Windows Service ou Linux Daemon com Worker Service & .NET Core – Parte 2Dev (Back & Front) · jul 2020Criando uma WebApi utilizando .NET, Linux e VSCodeDev (Back & Front) · ago 2019Ver tudo em DevSecOps →. O mesmo patch corrigiu um bug em que dlopen encaminhava um argumento flags indefinido, o que quebrava silenciosamente o carregamento de addons a partir do sistema de arquivos real.

É um recurso de nicho hoje, mas aponta para onde o VFS do Node.js está indo: não só arquivos de dados, mas também bibliotecas compiladas, empacotadas junto com a aplicação sem tocar o disco do host.

O padrão por trás das mudanças

A InfoQ nota que esse conjunto de adições segue uma tendência visível do Node.js nos últimos ciclos: reduzir a dependência de utilitários de userland, em contraste com Bun e Deno, que historicamente entregam uma standard library mais rica por padrão. O efeito colateral é relevante para cadeia de suprimentos de software: cada função que migra para o core é uma dependência a menos em uma árvore típica de node_modules, e portanto uma superfície a menos para ataques de supply chain via pacotes npm comprometidos.

Para equipes brasileiras que rodam Node.js em produção, isso se traduz em menos auditoria de dependências transitivas e menos pacotes para atualizar depois de um CVE em algo tão simples quanto um debounce. Não é um motivo isolado para migrar, mas é um motivo a mais para manter o runtime atualizado.

Onde isso fica na linha de suporte

As mudanças chegaram primeiro na linha Current, mas o desenvolvimento não parou aí: a versão v26.11.0 já trouxe utilitários adicionais de Buffer e do módulo http. O Node.js 26 está agora em Active LTS sob o codinome "Lithium", com suporte garantido até abril de 2029. Instaladores para todas as plataformas principais estão disponíveis em nodejs.org/en/download.

Para quem mantém serviços de longa duração, a combinação de LTS recém-ativa com esse lote de utilitários nativos é um bom momento para revisar o package.json em busca de dependências que o próprio runtime agora cobre.

Fonte: InfoQ