Participe da Maratona Behind the Code! A competição de programação que mais te desafia! Inscreva-se aqui

IBM Developer Blog

Siga os acontecimentos mais recentes com o IBM Developer, e fique por dentro.

Leia as notas mais recentes sobre o release do Node.js 15, além da entrada no Node.js 14 no LTS


Hoje, a comunidade Node.js está lançando o Node.js 15, com novos recursos que são importantes para usuários e clientes do Node.js. Ele não será promovido para suporte de longo prazo (LTS). No entanto, precisamos que nossos clientes e o ecossistema mais amplo o experimentem e nos forneçam feedback para ajudar a abrir caminho para o release do Node.js 16.

Estes são alguns dos novos recursos e do trabalho em andamento no release 15:

  • Tratamento atualizado de rejeições
  • npm 7
  • N-API Versão 7
  • Refinamento das APIs Async Local Storage
  • V8 8.6

# Tratamento atualizado de rejeições

Nas versões anteriores do Node.js, se houvesse uma rejeição sem tratamento, você receberia um aviso a respeito dela e um aviso de depreciação.

O exemplo a seguir:

new Promise((resolve, reject) => {
  reject('error');
});

resultaria nesta mensagem de depreciação:

(node:31727) UnhandledPromiseRejectionWarning: error
(node:31727) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:31727) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

É possível evitar essas mensagens de aviso tratando da rejeição com um bloco de captura:

new Promise((resolve, reject) => {
  reject('error');
}).catch((error) => {});

A partir do Node.js 15, o comportamento padrão mudou para:

node:internal/process/promises:218
          triggerUncaughtException(err, true /* fromPromise */);
          ^

[UnhandledPromiseRejection: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason "error".] {
  code: 'ERR_UNHANDLED_REJECTION'
}

Tomamos essa decisão para alinhar às expectativas da comunidade e ajudar a revelar problemas que, caso contrário, seriam difíceis de localizar e depurar. Isso alinha o comportamento das rejeições não tratadas ao das exceções não tratadas, em que vimos que o comportamento de arremesso é útil.

Embora o padrão tenha mudado, o Node.js permite que você configure o comportamento padrão para rejeições não tratadas por meio do sinalizador --unhandled-rejections. Caso precise retornar para o padrão anterior, basta adicionar a linha de comando a seguir: --unhandled-rejections=warn ou por meio da variável de ambiente NODE_OPTIONS export NODE_OPTIONS=--unhandled-rejections=warn.

Também é possível tratar a rejeição não tratada adicionando um listener unhandledRejection:

process.on('unhandledRejection', (reason, promise) => {
  // do something
});

npm 7

O npm 7 é um release principal que vem com novos recursos, incluindo espaços de trabalho e suporte aprimorado para o arquivo de bloqueio de pacote. Uma nova alteração do npm 7 é que as dependências de peer são instaladas por padrão. (Para saber mais sobre por que ou como isso é feito, leia a publicação de blog Instale dependências de peer.

A equipe de npm trabalhou para minimizar possíveis interrupções em projetos existentes devido à transição para a instalação automática de dependências de peer. No entanto, em caso de problemas, é possível usar o sinalizador --legacy-peer-deps no momento da instalação como alternativa para retornar ao comportamento anterior. Também é possível defini-lo no ambiente ou em arquivos de configuração npm, conforme descrito na documentação de npm.

Para obter informações mais completas sobre o release do npm 7, leia o blog do release: Apresentando a v7.0.0 da CLI npm.

# N-API Versão 7

Com o Node.js 15, é mais fácil criar, desenvolver e dar suporte a módulos nativos (também conhecidos como complementos). A IBM e a Red Hat estão continuamente contribuindo para o N-API. O Node 15 vem com a N-API versão 7, que traz métodos adicionais para trabalhar com buffers de array:

napi_status napi_detach_arraybuffer(napi_env env,
                                    napi_value arraybuffer)

napi_status napi_is_detached_arraybuffer(napi_env env,
                                         napi_value arraybuffer,
                                         bool* result)

É preciso destacar que a node-addon-api, que é uma das maneiras de consumir a N-API, recentemente ultrapassou dois milhões de downloads por semana! Para saber mais sobre a N-API, confira os documentos de API e node-addon-api.

Refinamento das APIs Async Local Storage

No blog do release do Node.js 14.x, destaquei a adição da API Async Local Storage. Continuamos refinando e testando essa API em comunidade durante a linha do tempo do 15.x. A API ainda é experimental no momento, mas é possível testá-la.

Trata-se de um recurso importante para clientes empresariais que necessitam de rastreio de transações em diferentes processos e insights mais profundos sobre seus grandes aplicativos. Isso garantirá que o Node.js forneça APIs com suporte e uma experiência de primeira classe para empresas que usam soluções open-source, como a OpenTelemetry, além de outras soluções para gerenciamento de desempenho de aplicativos (APMs).

O Node.js 14.x torna-se a próxima versão com LTS

Outra ótima novidade: na próxima semana, o release do Node.js 14.x entra no TLS. Assim, os recursos dele poderão ser facilmente usados em produção! O Node.js 14.x traz muitas adições excelentes. As que me deixam mais empolgado são:

  • O Diagnostic Report como recurso estável está disponível no 14.x. Os clientes já estão usando o relatório de diagnóstico fácil de consumir para resolver seus problemas mais rapidamente. Em um exemplo recente, um cliente forneceu um relatório de diagnóstico quando relatou seu problema. Conseguimos diagnosticar e fornecer uma solução rapidamente sem perder tempo tentando obter informações adicionais. Esse é um ótimo exemplo de como as informações em nível resumido no relatório podem ajudar você a diagnosticar e resolver problemas com mais rapidez.
  • Haverá um release de LTS com dados de ICU completos incorporados, simplificando as implementações em várias linguagens e em grande escala.

A estratégia da IBM com nosso envolvimento com o Node.js é nos concentrarmos em aspectos que acreditamos serem importantes para nossos clientes, incluindo releases estáveis e previsíveis, suporte à plataforma, segurança, diagnóstico, desempenho, redes de qualidade e segurança de código e recursos principais. Por ser um dos principais tempos de execução para implementações nativas de nuvem, o Node.js é crucial para a nuvem híbrida e o trabalho OpenShift da IBM e da Red Hat.

O release 14.x é eficiente em várias dessas áreas. É possível ler mais sobre todos os novos recursos no 14.x que podem ser usados em um release com LTS em: Release do Node.js 14: novas ferramentas de diagnóstico, recursos e aprimoramentos de desempenho.

Agradecimento à nossa excelente equipe

Para encerrar, eu gostaria de agradecer à equipe do release, incluindo Bethany Griggs da Red Hat, que gerenciou o release do 15.x, por toda a dedicação para lançar o Node.js 15. Também gostaria de agradecer ao elenco de apoio do grupo de trabalho da compilação e, evidentemente, aos colaboradores individuais.

Como contribuir para o Node.js

Enviar código e participar do trabalho da organização Node.js não são as únicas maneiras de contribuir para o sucesso contínuo do Node.js. Como desenvolvedor de pacotes ou usuário final do Node.js, peço que você teste inicialmente e com frequência, fornecendo feedback para o projeto Node.js.

Nosso ciclo regular de releases principais a cada seis meses (abril e outubro) oferece uma boa oportunidade para testar os releases com antecedência. Assim, quando um novo release for promovido para LTS, não haverá surpresas. Precisamos da sua ajuda para fazer esses testes. Depois que um release estiver em LTS, é possível testar seus aplicativos e pacotes regularmente nas versões com LTS de modo a garantir uma boa experiência para os usuários finais que estão migrando para tais versões. Caso tenha problemas, abra um problema no repositório do Node.js para relatá-los.

Você é mantenedor de pacotes? Considere alinhar seus releases e ciclos de suporte com as linhas de release do Node.js. O artigo Os mantenedores devem considerar a possibilidade de seguir o cronograma de releases do Node.js, da OpenJS Foundation, explica por que isso é benéfico para o ecossistema.

Também criamos recentemente uma nova função de triagem do Node.js para nos ajudar a gerenciar o backlog de problemas. É uma ótima forma de começar a contribuir para o projeto.

Saiba mais

Para ler mais sobre este release, confira o blog da comunidade que anuncia o release do Node.js 15. Também é possível saber mais sobre o que a IBM e a Red Hat estão fazendo nestes sites: