В декабре появились новости об уязвимостях в Angular

И здесь в чате об этом писали, спасибо @ngxSamurai за новость👍🏻

📌 Сначала в репозитории опубликовали сообщение о CSRF уязвимости.
Суть в том, что URL, начинающиеся с //, обрабатываются некорректно. Рекомендуется проверить приложение на наличие динамически формируемых URL, особенно с участием пользовательских данных.

📌 Но об этом уже многие слышали, но на прошлой неделе добавилась XSS уязвимость, которая возникает из-за недостаточной проверки URL-атрибутов: Схема безопасности некорректно классифицирует некоторые атрибуты, которые могут содержать URL (например, xlink:href в SVG). Это позволяет передавать в них javascript: URL, которые не блокируются.

📌 Уязвимость в SVG: Атрибут attributeName в элементах SVG-анимации ( , и др.) не проверялся должным образом. Злоумышленник может динамически назначить этот атрибут как "href" и передать в values вредоносный javascript: URL, что также обходит санитизацию.

Команда Angular рекомендует обновить приложения до следующих версий:
- Angular v19: обновиться до 19.2.17
- Angular v20: обновиться до 20.3.15
- Angular v21: обновиться до 21.0.2

#angular

NgStream / Чат

Перегрузка функций

Недавно попалась такая история на ревью, решил написать. Не все могут знать, что в Typescript есть нюанс. Неправильный порядок при декларации перегрузки функций может привести к трудноотлавливаемым багам.

📌 Ключевое правило - более специфичные сигнатуры должны быть выше, общие (any, unknown) - ниже. TypeScript использует первую подходящую перегрузку сверху вниз.

// Хорошо
declare function fn(el: HTMLDivElement): string;
declare function fn(el: HTMLElement): number;
declare function fn(el: unknown): unknown;

// Плохо
declare function fn(el: unknown): unknown;
declare function fn(el: HTMLElement): number;

В примере выше, если первым поставить unknown, то узкие сигнатуры не будут использованы, т.к. этот тип является супертипом и будет совпадать всегда.

unknown ⊃ any ⊃ HTMLElement ⊃ HTMLDivElement
// где ⊃ означает "является супертипом"

Несмотря на то, что union types безопаснее, перегрузки функций обеспечивают лучший DX для других разработчиков через автодополнение. Пишите в комментарии, если тоже сталкивались или есть другой подобный опыт:)

#typescript

NgStream / Чат

Обновление OWASP

Впервые с 2021 года обновился Top 10 - опрос о категориях уязвимостей, которые чаще всего встречаются в индустрии.

📌 О чем вообще речь?

OWASP - сообщество, которое создает открытые стандарты, инструменты и документацию по безопасности веб-приложений.

📌 Сначала коротко о самых известных инструментах.

- OWASP Cheat Sheet - руководства по конкретным темам (аутентификация, криптография, защита от SQL-инъекций и тд).
- OWASP Application Security Verification Standard - описывает требования безопасности и используется для проведения аудитов. При проектировании приложения позволяет не забыть о валидации данных на клиенте, работе с токенами, защите от CSRF.
- OWASP Zed Attack Proxy (ZAP) - инструмент для динамического тестирования безопасности (DAST), который помогает автоматически находить уязвимости в работающем приложении.

📌 Теперь об отчете.

Самым интересным кажется появление в рейтинге supply chain атак. Если кратко, то это тип атак через любой из компонентов цепочки поставки – сторонние библиотеки, инфраструктура сборки, хранения кода, мониторинга. При этом риск охватывает и инструменты разработки на основе ИИ, которые сами становятся вектором атаки (небезопасный сгенерированный код, уязвимости в самих помощниках).

Благодаря ORM и санитизации injections перестают быть острой проблемой и сместились с третьего места на пятое по частоте возникновения.

Broken Access Control сохраняет за собой первое место, подчеркивая его фундаментальную и повсеместную опасность. Статистика указывает на всеобъемлющую проблему, которая может усугубиться с развитием ИИ агентов.

При этом, ИИ рассматривают и как решение для обнаружения сложных логических уязвимостей и снижения ложных срабатываний.

📌 Общий тренд говорит о том, что от организаций требуется смещение фокуса с проверки кода на обеспечение безопасности всего жизненного цикла разработки и эксплуатации.

NgStream / Чат

В сообществе опять вернулись к вопросу переключения на стратегию Onpush по умолчанию. Эта идея давно обсуждалась, но после миграции компонентов на standalone вернулись снова.

Дело в том, что с появлением Signals писать код, совместимый с OnPush, стало значительно проще. Дополнительно, это подтолкнет разработчиков, особенно новичков, сразу писать более производительный код и уменьшит бойлерплейт.

Ранее предлагались варианты глобальной настройки (через angularCompilerOptions или angular.json), но отказались, так как их сложнее контролировать и понимать при работе с конкретным компонентом.

Сейчас же обсуждается вариант с автоматической миграцией, аналогичной переходу на stabdalone. Может даже миграцией по шагам. В общем, недавно выкатили proposal, за который можно проголосовать.

#angular

NgStream / Чат

Скоро новогодние праздники, кто-то уже взял отпуск и отдыхает, кто-то радуется снегу:)

Всех поздравляю с наступающим Новым годом и Рождеством!🎄🎉🎉🎉🎉🎉
Вернемся к новостям уже в следующем!

Спасибо, что подписаны! Хотим пожелать нам всем профессионально развиваться и не забывать отдыхать!

Пока вы догуливаете последние дни каникул, команда Angular, спустя 8 лет, начала работу над поддержкой стрелочных функций прямо в шаблонах!

📌 планируется поддержка только implicit returns, это должно будет предотвратить миграцию сложных функций, содержащих бизнес-логику, в шаблоны

📌 внутри этих функций нельзя будет использовать pipes, но результат работы этих функций можно будет передавать в pipe через конвеер

{{ (a, b) => a + b | currency }}

❓в комментах Manfred Steyer предложил также избавиться от магической переменной $event и добавить возможность использовать явный параметр (click)="(e) => doStuff(e)"

По сути, это всё будет in-place решением для функций-компараторов, например для trackBy, либо же:

<select [compareWith]="(a, b) => a.id === b.id"/>

<mat-autocomplete [displayWith]="option => option.name"/>

<button (click)="someSignal.update(prev => prev + 1)"/>

А что с производительностью?
Заявлено, что если функция ссылается только на свои собственные параметры, то она будет автоматически выноситься в top-level константу и не будет пересоздаваться при каждом Change Detection.
А в случаях, когда функция ссылается на контекстные переменные шаблона – она будет сохранена в текущем View, после чего будет подставляться где необходимо.

Данную возможность просили еще с 2017 года и длительное время на гитхабе шла дискуссия о подходе, плюсах и минусах добавления этой возможности.
Высказывались опасения по поводу того, что будет сложно тестировать такие функции, что бизнес-логика переедет в шаблон, а с другой стороны звучали аргументы, что это все должно быть на совести разработчика, а не фреймворка.

А что вы думаете об этом?

#angular

NgStream / Чат

Команда Angular добавит контроль за очисткой инжекторов при переходе с одного route на другой.

📌 Когда для маршрута определяются провайдеры (через providers в Route или lazy загрузку модуля), Angular создает для этого маршрута отдельный EnvironmentInjector. И инжекторы никогда не уничтожаются, даже если пользователь перешел на другой route.
В этом состоит основная проблема, что приводит накоплению неиспользуемых инжекторов в памяти, неосвобождаемым подпискам и ресурсам компонентов и, в результате, росту потребления памяти в приложениях. Для современных SPA это критично.

Для пояснения следующего пункта нужно пояснить, кто не знает.

RouteReuseStrategy - стратегия управления жизненным циклом компонентов роутов. Если чуть упростить, то механизм, который позволяет кешировать роуты, а именно инстанс компонента и относящийся к нему DOM, чтобы впоследствии (при повторном обращении к route) достать из кеша.

Получается, стратегия определяет:
- Уничтожать и пересоздавать компоненты при навигации (поведение по умолчанию) или

- Сохранять в памяти и переиспользовать компоненты с их состоянием.

📌 При использовании этой стратегии объекты DetachedRouteHandle сохранялись в памяти. Если пользователь больше не возвращался на сохраненный route, компоненты не уничтожались и не отписывались от Observable, что постепенно замедляло работу приложения. В этом состоит вторая проблема.

📌 Обновление вводит механизмы для автоматической и ручной очистки ресурсов. Для этого используется алгоритм "mark and sweep", который выявляет неиспользуемые инжекторы и освобождает ресурсы.
Для автоматической очистки рекомендуется использовать withExperimentalAutoCleanupInjectors().

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes, withExperimentalAutoCleanupInjectors())
  ]
};

📌 Обновление RouteReuseStrategy
В стратегию добавлены новые методы - shouldDestroyInjector и retrieveStoredRouteHandles, которые дают более тонкий контроль над тем, когда именно нужно очищать ресурсы.

Как мы видим, мощное архитектурное улучшение решит проблемы с утечками памяти и деградацией производительности. Особенное внимание стоит уделить крупным приложениям и использующим кэширование routes.

МР

#angular

NgStream / Чат

Angular tip

Как вы знаете, в обновленном Style guide, направленном на обеспечение единообразия кода, основное внимание уделяется стандартам именования файлов. Начиная с 21 версии для новых проектов предполагается новый формат.

Функциональные единицы теперь не должны использовать суффикс. Например, для компонента UserProfile файлы должны называться user-profile.ts, user-profile.html и user-profile.scss.

Фишка в том, что добавлен флаг для сохранения текущего подхода.

--file-name-style-guide=2016

В этом случае компоненты, сервисы и другие элементы получат классические суффиксы.

#angular

NgStream / Чат

Вокруг vibe coding и всевозможных LLM не стихает информационный шум.

📌 Читая заголовки выступлений на митапах и конференциях, по ощущениям, половина о том, как подружиться с ИИ, как внедрить, управлять…, организовать процесс vibe coding…

📌 Вдруг, кто не знает, vibe coding - разработка, где человек, в основном, описывает задачу на естественном языке, а LLM генерирует код. Я решил написать свое отношение к теме vibe coding.

📌 Меня удивляет, что глубоко интегрируя этот процесс, человек не погружается глубоко в суть задачи, отдавая все на откуп ИИ. В итоге получается не всегда эффективное решение, поверхностное, с возможными ошибками. Здесь стоит сказать, что важно уметь с ним общаться, правильно и точно формулировать требования, исходную задачу и требуемый результат. В этом случае, конечно, процент ошибок ниже.

📌 Особенно остро этот вопрос касается джунов. ИИ делает хуже им, предоставляя готовые ответы, которые не позволяют набирать нужный опыт. Чем решение хорошо/плохо? Почему такое решение? Подобный подход подталкивает брать готовое решение и не разбираться в вопросе самостоятельно. А на первых этапах особенно важно походить по граблям и набить шишки.
В общем, я бы сказал, что внедрять джунам AI нужно не бездумно, а подкреплять его нормальными инженерными практиками, помощью коллег.

📌 Сложно спорить, есть очевидные плюсы

- Прототипирование возможных решений. Существенная экономия времени.
- Объемная и рутинная работа. Написать CRUD или что-то аналогичное. Быстро, удобно доставить бизнес-ценность.

📌 Но за эту скорость мы платим тем, что постепенно утрачивается навык самостоятельно решать задачу, навык глубокой отладки. В общем, мы перестаем меньше писать. Это же то, за чем многие пришли в разработку! Наша ценность всегда была в глубоком понимании, а не просто в умении производить код.

Я использую llm для генерации документации, иногда для написания тестов. С правками получается неплохо. Не всегда, правда😅

📌 Вывод в том, что ИИ, на мой взгляд, это усилитель навыков, а не замена разработчика. Как молоток не делает из человека плотника, так и ИИ не делает из новичка senior-разработчика. ИИ требует осознанности, важно оценивать качество сгенерированного кода, а не просто копировать. Соблюдать баланс, еще одна важная часть нашей экспертизы.

А какие ИИ инструменты используете вы в разработке? Добавлю небольшой опрос. Если есть мысли, пишите в комментариях, интересно будет узнать!

NgStream / Чат

TypeScript 6.0. И никаких компромиссов.

Если предыдущие версии старались сохранять максимальную обратную совместимость, то версия 6.0 нацелена на решительное избавление от legacy и установку новых стандартов «по умолчанию».

Что изменится в новой версии?

📌 Strict Mode теперь обязателен. Это не просто изменение одного флага, а глубокая смена логики наследования настроек. Теперь такие критические проверки, как noImplicitAny и strictNullChecks, становятся стандартом. Также по умолчанию будет подразумеваться директива "use strict"
📌 target es5 deprecated. Минимально возможный стандарт теперь ES2015. Отказ от ES5 позволит команде упростить внутреннюю логику. Возможно, ускорит процесс сборки.
📌 Включение параметра noUncheckedSideEffectImports по умолчанию. Позволит улучшить существующие конфиги и выявлять некорректные импорты в IDE.

Значительная часть работы посвящена удалению старых опций для упрощения конфигурации. Помечены deprecated baseUrl, --outFile, а также module resolutions node10 и classic .

Публикация финальной версии намечена на март 2026 года, а план выпуска включает этапы бета-тестирования и релиз-кандидата.

24 февраля 2026 - RC Release.
17 марта 2026 - Final Release.

Эти реформы призваны сделать конфигурацию «по умолчанию» максимально эффективной для защиты от типичных программных ошибок.

Подробнее здесь. Typescript Iteration Plan.

#typescript

NgStream / Чат

Команда Angular в последнем релизе все же представила новый вид селекторов. Точнее, selectorless подход. Эта функциональность не просто перешла в stable режим, но и была установлена как режим по умолчанию.

Суть подхода в обращении к классу компонента напрямую, минуя использование строковых селекторов, которые задаются в свойстве selector.

На мой взгляд, изменение вида селекторов - весьма спорное нововведение по нескольким причинам.

🛠 Несоответствие стандарту HTML. Как я понимаю, selectorless раньше не внедряли специально для следования стандарту. Спецификация определяет void-элементы (например, <img>, <br>), которые не могут иметь содержимого и не требуют закрывающего тега (но в конце ставят /> , например: <img />). Поэтому формально для соответствия стандарту HTML именно Angular берет на себя задачу превращения этих инструкций в валидные DOM элементы с открывающими и закрывающими тегами. Однако, если вы попытаетесь использовать такой синтаксис напрямую в html файле без предварительной компиляции (например, через innerHTML в браузере), парсер браузера может интерпретировать это неверно, так как по стандарту HTML пользовательские элементы (custom elements) обязательно должны иметь закрывающий тег и не могут быть void-элементами.

🛠 Медленная адаптация в enterprise. Многие пользователи Angular это крупные компании и обычно изменения внедряются постепенно. Поскольку плюсы не видны (по крайней мере пока что), то просто так переписывать код не очень разумно.

🛠 Сложнее поиск компонента в дереве селекторов в devtools и в коде, если использовать имя компонента.

🛠 Самое интересное, зачем текущий html-like синтаксис превращать в JSX? (кто не знает, в Angular не html, а чуть другой формат) Мы привыкаем ко всему, но это определенно делает Angular непривычным и никаких причин для внедрения, кроме "modern Angular code", я не нашел в тексте МР.

#angular

NgStream / Чат

Корректирующая обратная связь

В работе и личной жизни мы часто сталкиваемся с необходимостью давать обратную связь. Однако неправильно сформулированная критика может вызвать конфликт, обиду или демотивировать человека. Как сделать общение продуктивным, а критику - полезной?

Решением может быть корректирующая обратная связь - стиль взаимодействия, при котором цель не доказать свою правоту, а решить проблему. При этом фокус остается на фактах, а не на эмоциях.

Рассмотрим пару примеров.
❌ «Ты всегда срываешь сроки!» // Обвинение
✅ «Я заметил, что последние два дедлайна были пропущены. Давай разберёмся, что мешает уложиться в сроки?» // Конструктивный подход.

Конструктивное общение — это навык, который можно развить. Его основы:
🔸 Уважение к собеседнику.
🔸 Конкретика в замечаниях.
🔸 Готовность помочь исправить ошибки.

В разработке это особенно критично, потому что мы работаем со сложными системами, где причина проблемы редко лежит на поверхности.

Есть несколько причин давать корректирующую обратную связь.

📌 Ощущение безопасности. Когда критика не носит личный характер и направлена на решение задачи, люди перестают бояться ошибаться и скрывать проблемы. Поможет раньше задавать вопросы, адекватно оценивать риски.
📌 Формирование ответственности. Когда человек понимает реальное влияние своих действий на продукт, команду и клиентов, он начинает мыслить системно.
📌 Мотивация специалистов. Талантливые люди ценят рост, а отсутствие обратной связи - сигнал о стагнации и безразличии.

Получается, что это такой же инструмент инженерной культуры, как Code Review или тестирование. Если его правильно применять, это будет двигателем роста и для сотрудника, и для процессов команды, и для продукта в целом.

Если тема понравится, напишу отдельный пост и расскажу о фреймворке, который можно применять для корректирующей обратной связи.

#нетехзаметки

NgStream / Чат

На прошлой неделе релизнули 21.2

📌 Одно из нововведений - Exhaustiveness checking для @switch control flow! В этом случае требуется указание @case для каждого значения в типе. Проще говоря, появилась возможность добавить @default never;

Для тех , кто не знал, это называется "проверка на полноту", помогает убедиться при жонглировании набором значений, что задействованы все элементы Union type. Я стараюсь использовать в TS такую конструкцию для обеспечения дополнительной безопасности.
А сейчас добавлется еще один важный пункт - логика на UI теперь отражает модель данных.

// если пропустили/забыли добавить значение, компилятор вернет ошибку. В данном случае, если не указать 'reject' в @case, то получим ошибку.
type Status = 'draft' | 'review' | 'success' | 'reject';
status: Status = 'draft';

@switch (status) {
  @case ('draft') {...}
  @case ('review') {...}
  @case ('success') {...}
  @default never
}

📌 Стрелочные функции в шаблонах. Об этом уже написано в канале, не буду повторяться. Скажу, что конструкция избыточна и только размывает логику между шаблоном и классом. Шаблон все же предназначен для рендеринга, а не описания логики. А тут еще и поддержку оператора instanceof запилили. В шаблоне!
Есть нюанс. Вы не можете использовать стрелочную функцию в качестве обработчика события для вызова метода. Попытка написать (click)="() => doSomething()" приведет к ошибке на этапе компиляции (Template Type-Check error). Это ограничение связано с тем, как Angular оптимизирует привязку событий, и попытка «обернуть» вызов метода в стрелочную функцию внутри шаблона нарушает этот механизм.

📌 SignalFormControl. Здесь интереснее. Это инструмент для плавной миграции между реактивными и сигнальными формами. Позволяет применять правила, как это сделано в сигнальных формах, пример ниже. В шаблонах менять ничего не придется. Об изменениях касательно форм напишу отдельно=)

password: new SignalFormControl('', p => {
    required(p);
    minLength(p, 6);
  })

📌 Явность вместо неявности. С 22 версии OnPush стратегия по умолчанию для новых компонентов. А ChangeDetectionStrategy.Eager теперь является способом явно заявить, что компонент требует устаревшего «прожорливого» поведения. Это переименование необходимо для работы миграций. После обновления до 22, Angular CLI автоматически заменит отсутствие стратегии или Default на Eager.

📌 Интеграция с Prettier
Angular CLI теперь имеет встроенную интеграцию. При создании нового проекта .prettierrc добавляется «из коробки». Для больших команд это критически важное улучшение DX.

А вы уже мигрируете свои проекты на OnPush и сигналы или ожидаете принудительного перехода в v22?

Описание обновления.

#angular

NgStream / Чат

Обновления Signal Forms API

Еще одним полезным дополнением в 21.2 является новая утилита transformedValue для синхронизации значения с моделью.

Основные возможности
📌 Двусторонняя трансформация: функция parse (преобразование ввода → модель) и format (модель → отображение)
📌 Автоматическая обработка ошибок: Ошибки парсинга автоматически пробрасываются в родительскую форму. Ни на что не похоже?:)
📌 Гибкий механизм валидации: Функция parse может возвращать как успешный результат с value, так и массив errors
📌 Интеграция со встроенными валидаторами: Возможность возвращать стандартные ошибки валидации (например, min для отрицательных значений)
Пример использования: Пользователь вводит "20m" или "1h", а в модели данные хранятся в минутах. При неверном формате ввода форма получает соответствующую ошибку для отображения в UI.

Еще один инструмент - директива FormRoot , которая делает отправку форм полностью декларативной. Вместо навешивания на форму (submit)=submit($event) и директивы novalidate (которая отключает встроенные проверки браузера при проверке форм) используем FomRoot, которая связывает сигнал формы с шаблоном.

Обработку submit предлагается делать в специальном cb submission внутри сигнала form. Теперь не шаблон управляет отправкой, а сама форма определяет логику.

protected readonly form = form(this.credentials, {
  submission: {
    action: async () => await this.svc.save(this.credentials()),
    onInvalid: () => this.invalidSubmission.set(true),
    ignoreValidators: 'none'
  }
});

Кстати, .reset() по-прежнему сбрасывает только состояния touched и dirty. Для сброса значения формы указывать напрямую initial значение модели. В этом случае, сбросится значение формы и сигнал, содержащий модель данных.

Описание обновления.

#angular

NgStream / Чат

Вышел Vite 8.0

Главным нововведением стал переход на Rolldown, высокопроизводительный bundler на базе Rust, который заменяет связку из esbuild и Rollup для достижения кратного прироста скорости сборки.

Долгое время Vite балансировал между esbuild для сборки в режиме разработки и мощным Rollup для оптимизированных бандлов в production.

Rolldown был спроектирован для того, чтобы объединить нативную производительность (уровня esbuild) с богатой экосистемой плагинов Rollup. Теперь и разработка, и prod сборка используют одни и те же механизмы парсинга и разрешения модулей, что гарантирует идентичность поведения кода.

В экспериментальном режиме Full Bundle Mode обещают какие-то фантастические цифры:
- Старт сервера в 3 раза быстрее.
- Полные перезагрузки страниц на 40% быстрее.
- Снижение количества сетевых запросов в 10 раз.

Теперь цепочка «инструмент сборки (Vite) - бандлер (Rolldown) - компилятор (Oxc)» работает как единое целое с глубокой AST-интеграцией.

Команда предлагает специальный Migration guide, обещая плавный переход без значительных изменений в конфигах.

Более подробно можно ознакомиться по ссылке.

#angular

NgStream / Чат

На просторах интернета нашел статью о глубоком погружении и использовании Claude Code на примере Angular и решил скинуть. Мне показалось, что описано подробно и будет полезно для тех, кто сейчас разбирается в процессе.

📌 Здесь и о настройке первого проекта, пояснениях документации, Angular MCP, режимах планирования, интеграции с Git и плагинами. И даже с пайплайнами CI.

📌 Главная проблема LLM - устаревание знаний, а Angular развивается довольно быстро (Signals, Resource API), поэтому ответы могут быть некорректными. Но есть Model Context Protocol (MCP), который позволяет Claude подключаться к актуальной документации Angular CLI напрямую.

📌 Еще одна проблема - это высокая автономность, и ошибки AI могут быть фатальными. Решением является изоляция. Для этого предлагается использовать Docker Sandbox. Запуск через claude --docker изолирует агента в microVM.
Неплохая фраза, которую нашел в статье и которая описывает текущее состояние:

ваша задача - быть «пилотом», который задает курс и проверяет качество.

📌 А на прошлой неделе еще появилась новость, что Anthropic признали угрозой национальной безопасности и приказали федеральным агентствам прекратить использовать Claude. Bloomberg.

#angular

NgStream / Чат

Обновление Angular roadmap

Команда выделяет основные направления:

📌 Самое громкое изменение - повышение приоритета «Improve the AI experience for developers». Angular не просто «надеется», что LLM напишут хороший код, а системно оптимизирует свои инструкции, документацию и внутренние API, чтобы модели, вроде Gemini, выдавали качественный результат. Для оценки прогресса используется собственная инфраструктура тестирования - Web Codegen Scorer.

📌 Эволюция реактивности и Signals. Сигналы становятся центральной частью архитектуры Angular, проникая во все ключевые пакеты.

-Signal Forms. В планах обеспечение бесшовной миграции с Reactive Forms.
- Асинхронная реактивность. Внедрение примитивов resource и httpResource для обработки асинхронных потоков данных как сигналов.
- В разработке создание оберток на базе сигналов для Router и других модулей.
- Повышение производительности. Переход на zoneless и использование стратегии обнаружения изменений OnPush по умолчанию.

📌 Улучшение DX. Здесь, как я понял, команда отметила, что завершена работа над запланированными изменениями. И ничего не было написано о новых. Angular переходит на сторону популярных инструментов экосистемы.

- Vitest (Experimental, v20). Современная и быстрая альтернатива Karma/Jasmine становится частью официального тулинга.
- Стабильный HMR (v20). Горячая перезагрузка шаблонов и стилей наконец-то получила статус Stable, что делает цикл «правка-результат» практически мгновенным.

Ссылка на МР с обновлением.

#angular

NgStream / Чат

Сигналы становятся центральной частью Angular, вытесняя старые механизмы управления состоянием и запросами к шаблону. Некоторые (если не многие) проекты сейчас в состоянии перехода на новые сигнальные API.

Просто взять и заменить все декораторы на функции в пятницу вечером - плохая идея. Но мы можем запретить появление новых декораторов в новом коде.
И я недавно увидел, что есть правила ESLint, которые могут помочь с миграцией, и решил поделиться.

Для миграции нам понадобятся два ключевых инструмента ESLint (с плагином @angular-eslint) и schematics, которые были представлены вместе с выходом нового API.

📌 Мы можем использовать правило prefer-signals. Оно помечает использование @Input как ошибку, предлагая заменить на input. Аналогично для других legacy декораторов.

📌 Что с [(ngModel)] ? Мы знаем, что можно заменить на сигнал model(), который упрощает реализацию двустороннего связывания (two-way data binding). Выглядит следующим образом: value = model.required<string>();

Здесь нам помогает правило prefer-signal-model. Поскольку сигналы не должны переназначаться, правила ESLint предлагают автоматически добавлять модификатор readonly к объявлению свойств.

В общем, с использованием правил линтера немного проще мигрировать большие enterprise проекты на новый API, писать код чище, современнее и безопаснее. Успешной миграции!

#angular

NgStream / Чат

Все же представлен экспериментальный компилятор Angular от OXC

VoidZero заявляют:
- об ускорении билда в 20 раз за счет переноса логики обработки и преобразования шаблонов на сторону Rust и интеграции с экосистемой Oxc и Vite.
- в 6 раз быстрее, чем Angular CLI и в 20 раз быстрее, чем Webpack.
- vitejs plugin с полной поддержкой HMR.

Решение сфокусировано на скорости, в нем отсутствуют межфайловые оптимизации и проверка типов в шаблонах, что является узким местом текущего решения, т.к. требует глубокого семантического анализа всей программы и замедляет сборку по мере роста приложения.

Из интересного - компилятор написан на Rust! И разработан с использованием искусственного интеллекта. Пишут, что инженеры использовали Claude и Codex. Агенты проанализировали проект Oxc и определили, как использовать его компоненты (Parser, Semantic, Transformer) для замены функционала TypeScript. Были внедрены высокопроизводительные паттерны Rust, такие как arena memory allocation и применение существующих SIMD crates.

Oxc Angular Compiler не планируют поддерживать в дальнейшем, поскольку задача была удостовериться в возможностях AI, его эффективности и переносе Angular single-file компиляции на Rust.

На мой взгляд, это немного подтверждает теорию, что даже крупные проекты могут быть переписаны с помощью ИИ , но их поддержка будет дорогой.

Команда Angular уже проводит собственные эксперименты, что позволит интегрировать решения для существующего компилятора и работать с Vite.

Ссылка на статью с подробностями.

#angular

NgStream / Чат