Телеграм канал «»

Некоторое время назад, то тут, то там появлялись статьи с заголовками о переписывании компилятора Angular на Rust. И теперь мы снова возвращаемся к этой новости.

Но в этот раз решение получилось более интересное, с инженерной точки зрения. Вместо полного переписывания был выбран гибридный вариант - реализован модуль packages/compiler-cli/preprocessor. Это препроцессор NGP (Angular Preprocessor). В его основе AST-анализатор, написанный на Rust, со сборкой в WebAssembly. Вместо полной переработки фреймворка команда Angular посчитала такой подход на порядок эффективнее и безопаснее. Он позволяет вынести наиболее ресурсоемкие операции по синтаксическому анализу, парсингу, сканированию аннотаций и построению метаданных в высокопроизводительный Rust-бинарник, не разрушая при этом миллионы строк существующей бизнес-логики компилятора на TypeScript и сохраняя стопроцентную обратную совместимость с экосистемой.

Как заявлено в описании, решение затрагивает весь DX целиком. В состав нового модуля вошли следующие взаимосвязанные компоненты:
- Движок препроцессора и Jasmine-тесты: основной препроцессорный модуль в packages/compiler-cli/preprocessor и полная тестовая обвязка на Jasmine.
- AST-анализатор ng-analyze: Rust-компонент с целевой компиляцией в WebAssembly, расположенный в packages/compiler-cli/preprocessor/ng-analyze.
- Интеграция с Language Services: расширение языкового сервиса и наборы спецификаций в packages/compiler-cli/preprocessor/language-service.
- Экспериментальное расширение для VS Code: специализированный плагин ngp-vscode-ng-language-service для прямой интеграции в редактор.

Решение напомнило сравнительно недавние новости из других инструментов - Turbopack и Rolldown, где повышение производительности тоже достигается не за счет переписывания всего инструмента, а через делегирование тяжелых вычислений на Rust при сохранении высокоуровневой логики на TypeScript. Можно сказать, индустриальный стандарт.

#angular

NgStream

Модернизация архитектурных шаблонов Angular

Посмотрел доклад Rainer Hahnekamp, где он рассматривает эволюцию архитектурных паттернов в Angular, переходя от Domain-Driven Design к более минималистичным подходам. Он считает, что используя подход с smart\dumb компонентами, мы платим indirection tax - контейнер превращается в обычного прокси-посредника. Он не несет бизнес-ценности, а лишь занимается оркестрацией @Input() и @Output(). В общем, лишний бойлерплейт, который ранее оправдывался необходимостью защиты UI от логики. Подход пришел к нам из React, как способ справиться со сложностью из-за тяжеловесных и глобальных сторов. Сегодня сторы перестали быть глобальными монолитами и несут меньше мусора в коде.

Райнер предлагает радикальную идею: перевернуть зависимость. Вместо контейнера, который управляет данными и раздает их дочерним компонентам, позволять доменным UI-компонентам напрямую инжектить локальный стор.

Здесь вступает новое правило - мы должны четко разделять два типа UI:
Shared Reusable UI: Кнопки, инпуты, календари. Они остаются абсолютно «глупыми», не знают о доменах и общаются только через @Input/@Output.
Domain-specific UI: Компоненты, созданные специально для конкретной задачи.

Преимущество в том, что пробросы данных не нужны. Логика инкапсулируется в сторе, а компоненты отвечают за отображение. В этой модели стор не просто хранилище, а «центр управления полетами».

На мой взгляд, предлагаемое изменение сильно пересекается с существующим Smart/Dumb подходом. Все равно работа с состоянием, вычисления происходят в сервисе/сторе. Компоненты отвечают за UI, бизнес логики в них быть не должно. Рассмотрю пример. Есть OverviewComponent, в него вложен MetricsList и дочерний MetricsCard. Я бы по-прежнему инжектировал сервис в OverviewComponent, получал данные и пробрасывал через свойства. По предложенной логике это Domain-specific UI, разве не проще пробросить данные через input в MetricsCard из шаблона сверху? Предложенный подход вполне применим, сильно зависит от ситуации.

И как вы считаете, продолжаете ли применять концепцию Smart/Dumb (где это необходимо)?
Ссылка на запись.

#angular

NgStream

В Angular CLI добавили сборщик библиотек.

Новый @angular/build:library построен на тех же принципах, что и Application Builder. В отличие от предыдущих подходов, этот билдер оптимизирован на уровне ядра:

📌 Унификация движка: Библиотеки и приложения теперь используют одинаковую инфраструктуру.
📌 Встроенный Asset Copying: Нативная поддержка работы со статическими файлами теперь встроена в процесс, устраняя необходимость в дополнительных скриптах.
📌 Поддержка Angular Package Format (APF). Это то, что гарантирует совместимость библиотеки с FESM, типами и метаданными в любой версии фреймворка. Раньше соответствие APF требовало сложной настройки. Теперь это стандартное поведение.

Особо стоит отметить, что новый билдер перехватывает все warnings, возникающие при обработке CSS/SCSS, что означает, что некорректный синтаксис будет обнаружен сразу, а не только на этапе интеграции библиотеки.

Дополнительно были сделаны улучшения, касающиеся инкрементальной сборки. Реализован pipeline компиляции, обеспечивающий повторную сборку только изменённых частей. Новый dependency graph scanner используется для анализа entry points и связей между ними. Данные сканирования используются для компиляции, бандлинга и создания структуры манифестов package.json в соответствии со спецификацией APF.

Планируется включить этот функционал в следующий минорный релиз. Ссылка на MR.

#angular

NgStream

Angular CLI - переход на Sass-Embedded Compiler

Разработчики заменили медленную JS версию Sass компилятора на нативный сервис sass-embedded, работающий как фоновый процесс. В прежнем подходе сборщик использовал пул Worker Threads для запуска компилятора. Это приводило к повышенному расходу памяти и ошибкам Out of Memory, что особенно критично в CI/CD с ограниченными ресурсами.

В новом подходе, вместо запуска тяжелого Node.js процессов, система вызывает отдельный процесс - бинарный файл Dart AOT, работающий вне виртуальной машины V8. В старой системе основной процесс Node.js и рабочие потоки часто конфликтовали. Главным виновником была блокировка потоков. Это происходило, когда Sass пытался вычислить пути к импортируемым файлам. Процессор буквально «замирал» в синхронном цикле ожидания, вызывая thread contention (соперничество за ресурсы).

Новая архитектура построена на интерфейсе SassServiceImplementation и использует асинхронное общение через Protocol Buffers по стандартным каналам ввода-вывода. Переход на асинхронную обработку сообщений позволил процессору не ждать, а заниматься сборкой других частей приложения, пока фоновый процесс занят компиляцией стилей.

Инженеры Angular предусмотрели гибкость. В системе сосуществуют две реализации: SassAsyncCompilerImplementation (основная) и SassWorkerImplementation (резервная). Иногда запуск нативного фонового процесса невозможен. Например, в WebContainers (кто не слышал, это среда внутри StackBlitz). В них браузерная песочница безопасности запрещает порождать внешние бинарные процессы. В таких случаях Angular CLI автоматически переключается на старый метод.
Это нововведение успешно закрывает один из самых старых и востребованных запросов сообщества (#29319). Переход на sass-embedded - это не просто оптимизация, это смена парадигмы в сторону использования нативного инструментария там, где возможности Node.js и V8 достигают своего предела.

Ссылка на MR

#angular

NgStream