Angular CLI: Migrando para o Novo Sistema de Construção: Uma Jornada Rumo à Modernidade

A versão 17 trouxe consigo uma revolução silenciosa: um novo sistema de construção, projetado para impulsionar o desempenho e a eficiência do desenvolvimento de suas aplicações.

Este novo sistema, baseado em tecnologias modernas como ESM (ECMAScript Modules), esbuild e Vite, oferece uma série de vantagens em relação ao sistema anterior, baseado no Webpack.
Ele proporciona um formato de saída mais moderno, tempos de construção mais rápidos, integração com SSR (Server-Side Rendering) e pré-renderização, além de abrir portas para novas ferramentas e recursos.

Nesta jornada, vamos explorar o processo de migração para o novo sistema de construção do Angular CLI, desvendando os passos necessários para modernizar suas aplicações e aproveitar ao máximo o potencial dessa poderosa ferramenta.

Para Novas Aplicações: Um Novo Começo

Se você está iniciando um novo projeto Angular, pode comemorar! O novo sistema de construção já é o padrão para aplicações criadas com o Angular CLI a partir da versão 17. Ao executar o comando ng new, sua aplicação já será configurada para utilizar o novo sistema, sem a necessidade de nenhuma configuração adicional.

Para Aplicações Existentes: A Jornada da Migração

Se você possui aplicações Angular mais antigas, criadas com versões anteriores do Angular CLI, a migração para o novo sistema de construção é opcional, mas altamente recomendada. Existem duas formas de realizar essa migração:

Migração Automatizada: A Ponte para o Futuro

A migração automatizada é a maneira mais fácil e rápida de modernizar sua aplicação Angular, levando-a para o novo sistema de construção. O Angular CLI, como um guia experiente, conduzirá você por esse processo, realizando as mudanças necessárias nas configurações e no código.

Executando a Migração Automatizada

Para iniciar a migração automatizada, execute o seguinte comando:

ng update @angular/cli --name use-application-builder

Este comando instrui o Angular CLI a realizar as seguintes ações:

• Converter o alvo de construção: Se sua aplicação estiver utilizando o construtor browser ou browser-esbuild, ele será convertido para o novo construtor application.
• Remover construtores SSR antigos: Caso sua aplicação utilize algum construtor SSR antigo, ele será removido, pois o novo construtor application já inclui suporte a SSR.
• Atualizar configurações: As configurações do seu projeto em angular.json serão atualizadas para refletir as mudanças no sistema de construção.
• Fundir arquivos de configuração TypeScript: Os arquivos tsconfig.server.json e tsconfig.app.json serão fundidos em um único arquivo, e a opção "esModuleInterop": true será adicionada para garantir a compatibilidade com importações ESM.
• Atualizar o código do servidor: Se sua aplicação utilizar SSR, o código do servidor será atualizado para utilizar a nova estrutura de inicialização e diretório de saída.
• Remover o uso de estilos específicos do Webpack: O Angular CLI removerá qualquer uso de estilos específicos do Webpack, como o tilde (~) ou acento circunflexo (^) em @import ou url(), e atualizará a configuração para fornecer um comportamento equivalente.
• Converter para o novo pacote @angular/build: Se não houver outro uso do pacote @angular-devkit/build-angular, a aplicação será convertida para usar o novo pacote @angular/build, que possui menos dependências.

Verificando e Ajustando o Código

Após a migração automatizada, é importante executar um build da sua aplicação (ng build) para verificar se ocorreram erros. É possível que algumas partes do seu código precisem de ajustes manuais para se adaptarem ao novo sistema de construção.

O Angular CLI tentará fornecer soluções para os problemas encontrados, e as próximas seções deste guia detalharão algumas das situações mais comuns que você pode encontrar.

Com a migração automatizada, você estará dando um passo importante rumo à modernização da sua aplicação Angular, aproveitando as vantagens do novo sistema de construção e abrindo caminho para um futuro mais brilhante e eficiente no desenvolvimento web.

Migração Manual: Escolhendo o Seu Caminho para a Modernidade

Além da migração automatizada, o Angular CLI também oferece opções de migração manual, permitindo que você tenha mais controle sobre o processo e adapte-o às necessidades específicas do seu projeto.

Duas Opções para a Jornada Manual

O Angular CLI oferece duas opções de migração manual, cada uma com suas vantagens e desafios:

browser-esbuild: A Ponte Mais Curta

O construtor browser-esbuild é uma alternativa mais simples para modernizar a construção do seu projeto. Ele se concentra apenas no pacote do lado do cliente, sendo compatível com o construtor browser do sistema de construção anterior. Essa opção é ideal para projetos que não utilizam SSR (Server-Side Rendering) e desejam uma migração mais rápida e com menos alterações no código.

application: A Ponte para o Futuro Completo

O construtor application é a opção mais completa e poderosa. Ele abrange toda a aplicação, incluindo o pacote do lado do cliente, o servidor para SSR (se utilizado) e a pré-renderização de páginas estáticas em tempo de construção. Essa opção é ideal para projetos que já utilizam ou pretendem utilizar SSR, pois oferece melhorias significativas no desempenho e na experiência do usuário.

Escolhendo a Opção Ideal

A escolha entre browser-esbuild e application depende dos requisitos do seu projeto e do nível de esforço que você está disposto a investir na migração.

Se sua aplicação não utiliza SSR e você busca uma migração rápida e fácil, o browser-esbuild pode ser a melhor opção. Ele oferece a maioria dos benefícios de desempenho do novo sistema de construção com menos alterações no código.

Se sua aplicação já utiliza SSR ou você pretende adotá-lo no futuro, o construtor application é a escolha ideal. Ele oferece melhorias significativas no desempenho do SSR e facilita a adoção dessa tecnologia em projetos que ainda não a utilizam. No entanto, a migração manual para o construtor application pode exigir mais esforço, especialmente para aplicações SSR existentes.

Migração Manual para o Construtor de Compatibilidade: Um Passo Simples Rumo à Modernidade

Para projetos existentes que desejam experimentar o novo sistema de construção sem grandes mudanças no código, o Angular CLI oferece o construtor de compatibilidade browser-esbuild. Essa opção é ideal para aplicações que utilizam o construtor browser e buscam uma migração rápida e suave.

Uma Mudança Simples: Editando o arquivo angular.json

A migração para o construtor browser-esbuild é surpreendentemente simples. Basta editar o arquivo angular.json do seu projeto e alterar o campo builder no alvo de construção (build) para @angular-devkit/build-angular:browser-esbuild.

Antes:

"architect": {
  "build": {
    "builder": "@angular-devkit/build-angular:browser",
    ...
  }
  ...
},

Depois:

"architect": {
  "build": {
    "builder": "@angular-devkit/build-angular:browser-esbuild",
    ...
  }
  ...
},

Um Passo à Frente, Sem Dor de Cabeça

Com essa única alteração, você já estará utilizando o novo sistema de construção em sua aplicação, sem precisar modificar seu código ou suas folhas de estilo. O construtor browser-esbuild foi projetado para ser compatível com o construtor browser, minimizando o impacto da migração e permitindo que você aproveite os benefícios do novo sistema sem dor de cabeça.

Migração Manual para o Construtor application: A Jornada Completa Rumo ao Futuro

Para projetos que desejam aproveitar ao máximo o novo sistema de construção do Angular CLI, incluindo suporte a SSR (Server-Side Rendering) e pré-renderização, a migração manual para o construtor application é o caminho a seguir.

Um Novo Começo: Editando o arquivo angular.json

Assim como na migração para o browser-esbuild, o primeiro passo é editar o arquivo angular.json do seu projeto e alterar o campo builder no alvo de construção (build) para @angular-devkit/build-angular:application.

Antes:

"architect": {
  "build": {
    "builder": "@angular-devkit/build-angular:browser",
    ...
  }
  ...
},

Depois:

"architect": {
  "build": {
    "builder": "@angular-devkit/build-angular:application",
    ...
  }
  ...
},

Ajustando as Opções de Construção: Navegando por Novas Configurações

Após alterar o nome do construtor, é necessário atualizar as opções dentro do alvo de construção (build). As seguintes opções do construtor browser precisam ser ajustadas:

• main: Deve ser renomeado para browser.
• polyfills: Deve ser um array de arquivos, em vez de um único arquivo.
• buildOptimizer: Deve ser removido, pois essa funcionalidade agora é coberta pela opção optimization.
• resourcesOutputPath: Deve ser removido, pois agora é sempre media.
• vendorChunk e commonChunk: Devem ser removidos, pois eram otimizações de desempenho que não são mais necessárias.
• deployUrl: Deve ser removido e não é mais suportado. Utilize a tag <base href> em seu lugar (consulte a documentação de implantação para mais informações).
• ngswConfigPath: Deve ser renomeado para serviceWorker.

Próximos Passos: Explorando Novos Horizontes

Se sua aplicação não utiliza SSR, essas alterações devem ser suficientes para que o comando ng build funcione corretamente. No entanto, podem surgir novos avisos ou erros devido a diferenças de comportamento ou ao uso de recursos específicos do Webpack em sua aplicação.

Para aplicações que estão adotando o SSR pela primeira vez, o Guia de SSR do Angular oferece informações adicionais sobre o processo de configuração.

Para aplicações que já utilizam SSR, ajustes adicionais serão necessários para atualizar o servidor da aplicação e suportar os novos recursos integrados de SSR. O construtor application agora fornece funcionalidades integradas para os seguintes construtores preexistentes:

• app-shell
• prerender
• server
• ssr-dev-server

O processo de ng update removerá automaticamente o uso de pacotes do escopo @nguniversal, onde alguns desses construtores estavam localizados anteriormente. O novo pacote @angular/ssr também será adicionado automaticamente e utilizado, com a configuração e o código sendo ajustados durante a atualização. O pacote @angular/ssr suporta tanto o construtor browser quanto o construtor application.

Ao migrar para o construtor application, você estará abrindo as portas para um novo mundo de possibilidades no desenvolvimento Angular, com recursos avançados como SSR e pré-renderização, além de um desempenho de construção aprimorado.

Executando a Construção: Dando Vida à Nave Espacial

Após realizar as migrações necessárias, seja de forma automatizada ou manual, chegou o momento de executar a construção da sua aplicação Angular utilizando o novo sistema. Com o poder do Angular CLI e a modernidade do novo sistema de construção, sua nave estará pronta para alçar voo em pouco tempo.

O Comando ng build: A Plataforma de Lançamento

Assim como antes, o comando ng build continua sendo o ponto de partida para construir sua aplicação. No entanto, agora ele utiliza o novo construtor application (ou browser-esbuild, se você optou pela migração de compatibilidade), proporcionando um processo mais rápido e eficiente.

ng build

Atenção aos Scripts e Opções de Linha de Comando

Se sua aplicação utiliza scripts npm ou outros scripts para executar a construção, certifique-se de revisá-los e atualizá-los para garantir a compatibilidade com o novo sistema de construção. Algumas opções de linha de comando podem ter mudado ou se tornado obsoletas.

Para aplicações que migraram para o construtor application e utilizam SSR ou pré-renderização, você pode remover comandos ng run extras dos seus scripts, pois o ng build agora oferece suporte integrado a essas funcionalidades.

Aproveitando o Novo Sistema de Construção

Com o novo sistema de construção, você experimentará tempos de compilação mais rápidos, tanto para builds completos quanto para reconstruções incrementais. Além disso, o formato de saída ESM e o uso de ferramentas modernas como o esbuild garantem um código mais otimizado e eficiente.

Se sua aplicação utiliza SSR, você também se beneficiará das melhorias de desempenho e da integração com o novo construtor application, que simplifica a configuração e o gerenciamento do SSR.

Decolando para o Futuro

Com a construção da sua aplicação concluída, você está pronto para implantá-la em um servidor e compartilhar sua criação com o mundo. O Angular CLI, como um fiel copiloto, guiou você por todas as etapas da migração e construção, preparando sua nave espacial para uma jornada de sucesso no universo da web.

Iniciando o Servidor de Desenvolvimento: Testando sua Nave em Ambiente Controlado

Após a construção da sua aplicação Angular com o novo sistema, é hora de colocá-la em ação no ambiente de desenvolvimento. O servidor de desenvolvimento do Angular CLI entra em cena para simular o ambiente de produção e permitir que você teste e refine sua aplicação em tempo real.

ng serve: Seu Centro de Comando Permanece o Mesmo

A boa notícia é que, mesmo com o novo sistema de construção, o comando ng serve continua sendo seu fiel escudeiro para iniciar o servidor de desenvolvimento. Ele detecta automaticamente o novo sistema e o utiliza para construir e servir sua aplicação, sem a necessidade de alterações na configuração do builder dev-server ou na linha de comando.

ng serve

Opções de Linha de Comando: Personalizando a Experiência

Você pode continuar utilizando as mesmas opções de linha de comando que já conhece e usa para personalizar o servidor de desenvolvimento. Por exemplo:

• --open (ou -o): Abre automaticamente o navegador padrão na URL da sua aplicação (http://localhost:4200/ por padrão).
• --port: Especifica a porta em que o servidor deve ser executado (padrão é 4200).
• --host: Especifica o host em que o servidor deve ser executado (padrão é localhost).
• --ssl: Habilita o protocolo HTTPS para o servidor de desenvolvimento.

Recursos do Servidor de Desenvolvimento: Sua Base de Operações

O servidor de desenvolvimento do Angular CLI oferece diversos recursos para facilitar o desenvolvimento da sua aplicação:

• Live Reload: Atualiza automaticamente o navegador sempre que você salva uma alteração no código-fonte, proporcionando um feedback instantâneo sobre suas mudanças.
• Hot Module Replacement (HMR): Substitui módulos específicos em tempo real, sem a necessidade de recarregar toda a página, agilizando o desenvolvimento.
• Proxy para Backend: Permite que você direcione requisições para um servidor backend, simulando a comunicação com APIs externas.
• Source Maps: Facilita a depuração do código, mapeando o código JavaScript gerado de volta para o código TypeScript original.
• Outras Opções: O Angular CLI oferece diversas outras opções para personalizar o servidor de desenvolvimento, como a configuração de certificados SSL, a simulação de latência de rede e a integração com ferramentas de depuração.

Com o servidor de desenvolvimento do Angular CLI, você tem uma base de operações completa para testar, depurar e refinar sua aplicação Angular antes de lançá-la ao mundo. Aproveite essa ferramenta poderosa para garantir que sua nave espacial esteja pronta para voar em qualquer galáxia!

Hot Module Replacement (HMR): Acelere seu Desenvolvimento com Atualizações em Tempo Real

No mundo acelerado do desenvolvimento web, cada segundo conta. É por isso que o Angular CLI oferece o Hot Module Replacement (HMR), um recurso que permite atualizar partes da sua aplicação em tempo real, sem a necessidade de recarregar toda a página.

O Que é HMR?

Imagine que você está construindo um foguete e precisa fazer um ajuste em uma peça específica. Com o HMR, você pode trocar essa peça sem precisar desmontar todo o foguete e remontá-lo novamente. Da mesma forma, o HMR permite que você atualize módulos específicos da sua aplicação Angular sem perder o estado atual da página.

HMR no Angular CLI

No momento, o Angular CLI oferece suporte limitado ao HMR, focando principalmente na atualização de folhas de estilo globais. Isso significa que você pode modificar seus arquivos CSS e ver as mudanças refletidas instantaneamente no navegador, sem precisar recarregar a página.

O HMR para módulos JavaScript ainda está em desenvolvimento e será introduzido em versões futuras do Angular CLI. Quando estiver disponível, você poderá atualizar componentes, serviços e outros módulos em tempo real, agilizando ainda mais o processo de desenvolvimento.

Benefícios do HMR

O HMR oferece diversos benefícios para o desenvolvimento de aplicações Angular:

• Agilidade: Você pode ver as mudanças no seu código instantaneamente, sem precisar esperar o navegador recarregar a página.
• Produtividade: Você economiza tempo e mantém o foco no desenvolvimento, sem interrupções constantes para recarregar a página.
• Preservação do Estado: O HMR preserva o estado da sua aplicação, permitindo que você continue de onde parou após cada atualização.
• Debugging: O HMR facilita a depuração de problemas, pois você pode ver o impacto das suas alterações em tempo real.

O Futuro do HMR no Angular

A equipe do Angular está trabalhando ativamente para expandir o suporte ao HMR, incluindo a atualização de módulos JavaScript e a integração com ferramentas como o Vite. Com o HMR completo, o desenvolvimento de aplicações Angular se tornará ainda mais rápido, eficiente e produtivo.

Enquanto aguardamos ansiosamente por essa evolução, podemos aproveitar o HMR de folhas de estilo para agilizar nosso fluxo de trabalho e construir aplicações Angular cada vez mais incríveis.

Recursos e Comportamentos Ainda Não Implementados: A Jornada Continua

Embora o novo sistema de construção do Angular CLI seja estável e totalmente suportado, algumas opções e comportamentos do sistema anterior ainda não foram implementados. No entanto, isso não impede que você experimente o novo sistema, pois o Angular CLI emitirá avisos para qualquer opção não implementada e as ignorará durante a construção.

Importações WASM: Uma Fronteira a Ser Explorada

Um dos recursos ainda não implementados é a importação direta de módulos WebAssembly (WASM). Embora você ainda possa carregar módulos WASM manualmente usando as APIs web padrão, a importação direta via import ainda não é suportada.

A equipe do Angular está trabalhando para implementar o suporte a importações WASM no novo sistema de construção e ele estará disponível em uma versão futura.

Outras Opções e Comportamentos

Além das importações WASM, outras opções e comportamentos do sistema de construção anterior ainda não foram implementados. A lista completa pode ser encontrada na documentação oficial do Angular CLI.

Se sua aplicação depende de alguma dessas opções para funcionar corretamente, talvez seja melhor esperar até que elas sejam implementadas antes de migrar para o novo sistema.

A Jornada Continua

O novo sistema de construção do Angular CLI é um projeto em constante evolução. A equipe do Angular está trabalhando ativamente para implementar novos recursos e aprimorar a experiência de desenvolvimento.

Ao longo do tempo, novas opções e comportamentos serão adicionados, tornando o novo sistema ainda mais poderoso e versátil. Fique atento às atualizações do Angular CLI para acompanhar as novidades e aproveitar ao máximo as ferramentas que ele oferece.

ESM Default Imports vs. Namespace Imports: Alinhando com a Especificação ECMAScript

Ao migrar para o novo sistema de construção do Angular CLI, você estará adotando o formato ESM (ECMAScript Modules), que é o padrão moderno para modularidade em JavaScript. No entanto, é importante estar atento a uma diferença sutil, mas importante, entre a forma como o TypeScript e o ESM lidam com importações padrão (default imports).

O Problema: Divergência da Especificação ECMAScript

Por padrão, o TypeScript permite que exportações padrão sejam importadas como namespace imports e, em seguida, usadas em expressões de chamada. Infelizmente, isso diverge da especificação ECMAScript. O esbuild, o empacotador (bundler) utilizado no novo sistema de construção, espera código ESM que esteja em conformidade com a especificação.

A Solução: Habilitando a Opção esModuleInterop

Para corrigir esse problema e garantir a compatibilidade com o novo sistema de construção, você precisa habilitar a opção esModuleInterop no arquivo tsconfig.json da sua aplicação. Essa opção alinha o TypeScript com a especificação ECMAScript e é recomendada pela equipe do TypeScript.

{
  "compilerOptions": {
    "esModuleInterop": true,
    // ... outras opções do TypeScript
  }
}

Exemplo: Corrigindo a Importação do Pacote moment

Vamos usar o pacote moment como exemplo. O seguinte código, que utiliza um namespace import, causará erros em tempo de execução no novo sistema de construção:

import * as moment from 'moment';
console.log(moment().format()); 

O build gerará um aviso indicando o problema:

▲ [WARNING] Calling "moment" will crash at run-time because it's an importnamespace object, not a function [call-import-namespace]

Para corrigir o erro, habilite a opção esModuleInterop e altere a importação para utilizar um default import:

import moment from 'moment';
console.log(moment().format()); 

Importações Default vs. Namespace: Entendendo a Diferença

• Default Import: Importa o valor padrão exportado pelo módulo. É mais conciso e recomendado para a maioria dos casos.
• Namespace Import: Importa todos os membros exportados pelo módulo em um objeto namespace. É útil quando você precisa acessar vários membros do módulo.

Com a opção esModuleInterop habilitada e o uso correto de default imports, você garante que seu código TypeScript esteja em conformidade com a especificação ECMAScript e funcione perfeitamente com o novo sistema de construção do Angular CLI.

Vite como Servidor de Desenvolvimento: Acelere sua Jornada com um Motor Turbo

No universo do desenvolvimento web, a velocidade é essencial. É por isso que o Angular CLI incorporou o Vite, um servidor de desenvolvimento ultrarrápido, para impulsionar sua experiência de desenvolvimento.

O Que é o Vite?

Imagine o Vite como um motor turbo para o seu servidor de desenvolvimento. Ele utiliza módulos ES nativos e um sistema de cache inteligente para fornecer um ambiente de desenvolvimento extremamente rápido e eficiente. Com o Vite, você pode ver as mudanças no seu código refletidas no navegador quase instantaneamente, sem precisar esperar por longos tempos de compilação.

Vite no Angular CLI

O Angular CLI utiliza o Vite como servidor de desenvolvimento padrão a partir da versão 17. Isso significa que, ao executar o comando ng serve, você estará automaticamente utilizando o poder do Vite para impulsionar seu fluxo de trabalho.

O Vite trabalha em conjunto com o novo sistema de construção do Angular CLI, gerando um build de desenvolvimento da sua aplicação em memória e passando os resultados para o Vite, que se encarrega de servir a aplicação.

Benefícios do Vite

• Velocidade Extrema: O Vite é conhecido por sua velocidade excepcional, tanto na inicialização do servidor quanto na atualização de módulos em tempo real.
• Hot Module Replacement (HMR): O Vite oferece um HMR ainda mais rápido e eficiente do que o Webpack, permitindo que você veja as mudanças no seu código refletidas no navegador quase instantaneamente.
• Experiência de Desenvolvimento Aprimorada: Com o Vite, você pode desenvolver suas aplicações Angular de forma mais fluida e produtiva, sem interrupções e com um feedback imediato.

Configuração do Vite

No momento, o uso do Vite no Angular CLI é encapsulado dentro do builder dev-server e não pode ser configurado diretamente. No entanto, a equipe do Angular está trabalhando para adicionar mais opções de configuração no futuro.

Com o Vite como seu motor turbo, sua nave espacial Angular estará pronta para decolar em alta velocidade, proporcionando uma experiência de desenvolvimento incrivelmente rápida e eficiente.

Desafios Conhecidos: Navegando por Águas Turbulentas na Migração

Embora o novo sistema de construção do Angular CLI seja estável e promissor, algumas turbulências podem surgir durante a jornada de migração. É importante estar ciente dos desafios conhecidos para que você possa navegar por eles com segurança e chegar ao seu destino final: uma aplicação Angular moderna e otimizada.

Problemas Conhecidos:

A equipe do Angular está trabalhando ativamente para resolver os seguintes problemas:

• Verificação de Tipos de Código Web Worker e Processamento de Web Workers Aninhados: O novo sistema de construção ainda não oferece suporte completo à verificação de tipos em código Web Worker e ao processamento de Web Workers aninhados. Se sua aplicação depende desses recursos, você pode encontrar erros ou avisos durante a migração.
• Importações com Efeitos Colaterais em Módulos Lazy: Em alguns casos, a ordem de importação de módulos lazy pode afetar o comportamento da sua aplicação. O novo sistema de construção pode não preservar a ordem original das importações, o que pode causar problemas em alguns cenários.

Outros Desafios:

Além dos problemas listados acima, você pode encontrar outros desafios durante a migração, como:

• Configurações Personalizadas: Se sua aplicação possui configurações personalizadas no arquivo angular.json, pode ser necessário ajustá-las para garantir a compatibilidade com o novo sistema de construção.
• Dependências de Terceiros: Algumas bibliotecas de terceiros podem ainda não ser compatíveis com o novo sistema de construção. Verifique a documentação das suas dependências para obter informações sobre a compatibilidade com o Angular CLI.
• Testes: Se sua aplicação possui testes unitários ou de integração, pode ser necessário ajustá-los para garantir que funcionem corretamente com o novo sistema de construção.

Suporte e Recursos:

A equipe do Angular está comprometida em fornecer suporte e recursos para ajudar você a superar os desafios da migração. Você pode encontrar informações adicionais e soluções para problemas comuns na documentação oficial do Angular CLI e no repositório do GitHub.

Lembre-se que a migração para o novo sistema de construção é um investimento no futuro da sua aplicação Angular. Ao enfrentar esses desafios, você estará abrindo caminho para um desenvolvimento mais rápido, eficiente e moderno.

erificação de Tipos de Código Web Worker e Processamento de Web Workers Aninhados: Desvendando as Limitações Atuais

A jornada de migração para o novo sistema de construção do Angular CLI nos leva a explorar as fronteiras da tecnologia, onde algumas funcionalidades ainda estão em desenvolvimento. Uma dessas fronteiras é o suporte completo a Web Workers, um recurso poderoso para executar tarefas em segundo plano, liberando a thread principal da sua aplicação.

Web Workers: Trabalhadores em Segundo Plano

Web Workers são scripts que rodam em threads separadas do thread principal da sua aplicação. Isso permite que você execute tarefas intensivas, como cálculos complexos ou operações de rede, sem bloquear a interface do usuário.

No Angular CLI, você pode utilizar Web Workers em seu código da mesma forma que faria com o construtor browser:

const worker = new Worker(new URL('./app.worker', import.meta.url));

Limitações Atuais

Embora o uso de Web Workers seja suportado no novo sistema de construção, existem algumas limitações que você deve estar ciente:

• Verificação de Tipos: Atualmente, o compilador TypeScript não verifica os tipos do código dentro do Web Worker. Isso significa que você pode encontrar erros de tipo apenas em tempo de execução, o que pode dificultar a depuração.
• Web Workers Aninhados: Web Workers aninhados, ou seja, a criação de um Web Worker dentro de outro arquivo de Web Worker, ainda não são suportados pelo sistema de construção.

O Futuro do Suporte a Web Workers

A equipe do Angular está trabalhando ativamente para aprimorar o suporte a Web Workers no novo sistema de construção. Em versões futuras, podemos esperar:

• Verificação de Tipos: O compilador TypeScript será capaz de verificar os tipos do código dentro do Web Worker, proporcionando uma experiência de desenvolvimento mais segura e produtiva.
• Web Workers Aninhados: O sistema de construção será capaz de processar e empacotar Web Workers aninhados, expandindo as possibilidades de uso dessa poderosa ferramenta.

Navegando pelas Limitações

Enquanto aguardamos essas melhorias, você ainda pode utilizar Web Workers em sua aplicação Angular, mas esteja ciente das limitações atuais. Certifique-se de testar seu código minuciosamente e utilize ferramentas de depuração para identificar e corrigir possíveis erros de tipo.

Lembre-se que a tecnologia está em constante evolução, e o Angular CLI está sempre se aprimorando para oferecer as melhores ferramentas e recursos para o desenvolvimento de aplicações web modernas e eficientes.

Importações com Efeitos Colaterais em Módulos Lazy: Uma Armadilha a Ser Evitada

Em nossa jornada pelo novo sistema de construção do Angular CLI, encontramos mais um desafio a ser superado: a ordem de importação de módulos com efeitos colaterais em módulos lazy. Essa peculiaridade pode causar problemas inesperados no comportamento da sua aplicação, mas com alguns cuidados, você pode evitá-los e garantir uma navegação tranquila.

O Que São Efeitos Colaterais?

Em programação, um efeito colateral é qualquer alteração no estado de um sistema que ocorre fora do escopo da função que está sendo executada. Por exemplo, uma função que modifica uma variável global ou que registra um evento no console está produzindo efeitos colaterais.

O Problema: Ordem de Importação em Módulos Lazy

Quando você utiliza módulos lazy, que são carregados sob demanda pelo Angular Router, a ordem em que as importações são realizadas pode ser crucial para o correto funcionamento da sua aplicação. Se um módulo lazy depende de um efeito colateral de outro módulo, e a ordem de importação for alterada pelo novo sistema de construção, isso pode causar problemas inesperados.

Por exemplo, imagine que você tem um módulo LoggerModule que registra um evento no console ao ser importado. Se um módulo lazy DashboardModule depende desse evento para funcionar corretamente, e o sistema de construção importa o DashboardModule antes do LoggerModule, o evento não será registrado a tempo, e o DashboardModule pode não funcionar como esperado.

A Solução: Evitar Módulos com Efeitos Colaterais

A melhor forma de evitar esse problema é evitar o uso de módulos com efeitos colaterais fora do escopo dos polyfills. Polyfills são módulos que fornecem funcionalidades ausentes em navegadores mais antigos, e seus efeitos colaterais são geralmente bem definidos e controlados.

Módulos com efeitos colaterais não locais podem impactar negativamente o tamanho e o desempenho da sua aplicação. Ao evitá-los, você garante um código mais limpo, modular e eficiente.

Boas Práticas:

• Modularidade: Divida sua aplicação em módulos menores e coesos, cada um com responsabilidades bem definidas.
• Injeção de Dependência: Utilize a injeção de dependência para gerenciar as dependências entre seus módulos, evitando o uso de variáveis globais e efeitos colaterais não locais.
• Testes Unitários: Escreva testes unitários para garantir que seus módulos funcionem corretamente de forma isolada, independentemente da ordem de importação.

Ao seguir essas boas práticas, você estará construindo aplicações Angular mais robustas, escaláveis e fáceis de manter. Lembre-se, a jornada para o novo sistema de construção pode apresentar alguns desafios, mas com o Angular CLI como seu guia e as ferramentas certas em mãos, você chegará ao seu destino com sucesso.

A Jornada da Migração: Desbravando o Futuro do Angular CLI

A migração para o novo sistema de construção do Angular CLI é uma jornada emocionante e desafiadora, que nos leva a explorar as fronteiras da tecnologia e a construir aplicações web mais modernas, eficientes e escaláveis.

Nesta jornada, exploramos os benefícios do novo sistema, como a velocidade de construção aprimorada, o formato de saída ESM e a integração com ferramentas modernas como o esbuild e o Vite. Aprendemos sobre as diferentes opções de migração, tanto automatizada quanto manual, e como escolher o caminho mais adequado para o seu projeto.

Enfrentamos desafios como a compatibilidade com Web Workers, a ordem de importação de módulos lazy e a necessidade de adaptar o código para o novo formato ESM. Mas com o Angular CLI como nosso guia e as informações deste artigo como bússola, estamos preparados para superar qualquer obstáculo e chegar ao nosso destino.

A migração para o novo sistema de construção é um investimento no futuro da sua aplicação Angular. Ao abraçar essa mudança, você estará abrindo as portas para um mundo de novas possibilidades e recursos, impulsionando a qualidade e o desempenho da sua aplicação.