В своем выступлении ng-conf 2017 Брэд Грин объявил о проекте под названием ABC - Angular with Bazel и Closure. Цель состоит в том, чтобы объединить то, как мы разрабатываем приложения Angular внутри Google, с тем, как это делает внешнее сообщество. Это все еще на стадии проектирования, поэтому детали и документация не будут готовы в ближайшее время. Но мы также глубоко заботимся о сообществе Angular и считаем важным дать некоторый набросок того, что мы стремимся делать и почему.

Gmail был революционным приложением, когда он был впервые представлен. Это был сложный и амбициозный конкурент настольных почтовых клиентов, работавший полностью в веб-браузере. Позже такие продукты, как Google Docs, повторили этот успех, и долговечность этих инструментов доказывает, что их кодовые базы все еще поддерживались даже с большим количеством JavaScript.

Это стало возможным, потому что некоторые очень талантливые инженеры разработали инструменты, необходимые для превращения JavaScript в платформу корпоративной разработки. Мы создали типизированный вариант JavaScript, названный Closure, со стандартной библиотекой, библиотекой Closure и компилятором Closure, который представляет собой средство проверки типов, ES2015-транспилятор, оптимизатор, сборщик, минификатор - все в одной команде.

В течение 10 лет, прошедших с тех пор, команда продолжала постепенно улучшать оптимизатор в Closure Compiler. Оптимизация даже с использованием однозначного процента обеспечивала достаточно преимуществ для веб-приложений Google, и мы могли приложить необходимые инженерные усилия. В нашу цепочку инструментов сборки добавлены такие функции, как разделение кода для поддержки отложенной загрузки, эксперименты A / B и сокрытие кода на уровне отдельных файлов JS.

Перенесемся в Angular в 2016 году. Мы выпустили «Ahead-of-Time Compiler» для Angular, который перемещает большую часть фреймворка Angular из среды выполнения в браузере на этап сборки. Важно отметить, что этот компилятор также изменяет шаблоны с HTML на JavaScript, поэтому все развернутое приложение находится на одном языке. Это позволяет Closure Compiler выполнить самую важную оптимизацию: переименование свойств. Свойства в классе компонентов теперь можно переименовать в однобуквенные идентификаторы, поскольку ссылки в шаблоне также можно переименовывать. Мы в полной мере воспользовались этим преимуществом в Google, и наши приложения Angular обычно использовали флаги расширенной оптимизации для Closure Compiler для создания гораздо меньших полезных нагрузок JavaScript.

В то же время нам нужно было интегрировать TypeScript и Angular в наш инструмент сборки Bazel (http://bazel.build). Мы обеспечиваем время разработки 1-2 секунды, причем предварительная компиляция является * единственным * допустимым методом для запуска Angular. (Помимо тестов, где в настоящее время требуется JIT, чтобы разрешить переопределение дерева компонентов. Теперь есть планы выполнить AOT и для тестов.) Это означает, что мы выполняем проверку типов TypeScript и Angular, TypeScript-to -Компиляция JavaScript и компиляция шаблонов Angular достаточно быстро, чтобы продуктивно работать разработчиками даже в самых больших приложениях.

Необходимым свойством для выполнения этой работы является то, что время цикла разработки должно быть пропорционально размеру «библиотеки», а не размеру приложения. Разделив компиляцию на отдельные единицы компиляции, нам нужно запустить `ngc` только для нескольких файлов, включая те, которые вы только что изменили, но не для остальной части приложения. В других системах сборки было бы очень сложно организовать все необходимые повторные компиляции, и особенно сложно надежно пересобрать правильные. В конце концов, единственное, что хуже, чем инструмент неинкрементной сборки, - это инструмент сборки, в котором вы не уверены, что только что внесенные вами изменения действительно отражаются в работающем приложении. Пользователи Bazel настолько доверяют инкрементальности, что никогда не запускают «bazel clean» (я предполагаю, что многие гуглеры даже не знают об этой команде).

Мы думаем, что это довольно круто и действительно важно для разработки крупных клиентских интерфейсов корпоративного уровня. Но в отличие от большинства Angular, мы разработали эту интеграцию в нашем внутреннем репозитории с закрытым исходным кодом. Сейчас мы работаем над тем, чтобы сделать это доступным для всех. Это приносит пользу как сообществу разработчиков ПО с открытым исходным кодом (особенно корпоративным пользователям), которые могут создавать приложения Angular, как Google, так и команде Angular, уменьшая объем параллельных усилий, которые мы предпринимаем за кулисами.

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

После этого мы рассмотрим несколько вариантов сборки набора инструментов для сборки, который предоставит лучшее из того, что мы создали для себя, а также лучшее из того, что было создано сообществом. Например, даже если Bazel будет запускать все инструменты компилятора, мы все равно можем использовать Webpack в качестве сервера разработки. Мы также рассмотрим, как этот набор инструментов может быть доступен в следующем поколении Angular CLI.

Впереди у нас много работы, но мы также чрезвычайно рады снести часть обнесенного стеной сада, разделявшего опыт разработчиков двух наших ключевых групп пользователей: наших сотрудников в Google и нашего сообщества Angular.