ng build prod что это
Angular CLI создание проекта: основные команды
Сегодня начинаем разбирать весьма новый фреймворк JavaScript — Angular. Для того чтобы не писать кучу лишнего кода самому, чтобы его запустить и не тратя на это время — сначала мы изучим инструмент Angular CLI.
Что такое Angular CLI
Это инструмент созданный командой Google, который помогает увеличить скорость работы с проектом. Чтобы с ним работать вам придется изучить несколько команд, которые прописываются в командной строке.
У вас наверное созрел вопрос, а что именно он может? С помощью его вы можете:
Также у него в арсенале имеется Webpack, который пользуется большой популярностью. Он нужен чтобы компилировать и запускать проекты во время разработки.
Как видите это очень мощный инструмент в разработке больших проектов, и на старте проекта.
Установка Angular CLI
Для того чтобы начать необходимо установить:
Npm подтянется вместе с Node js при его установки.
Он нам нужен из-за большого количества дополнительных библиотек, зависимостей, которые придется устанавливать. Так мы сможем производить установку каждой по отдельности библиотеки, либо сразу все, которые находятся в файле package.json.
package.json — может хранить все зависимости, которые используются для работы с проектом. Также в нем можно найти — имя проекта, версия, скрипты и т.д.
Заходим на сайт — nodejs. Здесь вас ждет две версии Node js — LTS и Current. Выбирайте LTS и устанавливайте ее.
Теперь давайте установим Angular CLI на ваш ПК. Для этого вам нужно перейти в командною строку. Это можно сделать двумя способами:
Два данных способа относятся к операционной системе Windows
После открытия командной строки вводим строку ниже. Она представляет собой запрос на скачивание пакета npm:
Эта библиотека большая, поэтому вас понадобиться подождать несколько минут для ее установки.
Вот и все работы были сделаны. Теперь можем перейти рассматривать функционал установленного пакета.
Команды Angular CLI
Вот список всех команд, которые вам понадобиться знать:
Это будет зависеть от скорости вашего интернета соединения.
Если вы зайдете в данный проект, то увидите такую картину:
ng serve — запускает Webpack, который в свою очередь собирает файлы вашего проекта и переносит их в оперативную память вашего компьютера. Если вы замените какой-то файл, то он заново будет пересобирать ваш проект.
Перейдите на localhost:4200 в браузере и сможете увидеть ваш проект.
ng build — собирает все ваши файлы проекта и переносит их в папку dist. Далее вы можете делать с ними все что угодно — например, залить куда-нибудь на хостинг.
При ng serve мы ни как не можем пощупать собранные файлы.
ng generate [spec_file] [name] — создает [spec_file] с названием [name] и автоматически добавляет(производит import) его в модуль.
[spec_file] — это левая колонка таблицы
Со всем этими файлами вы познакомитесь позже.
Замена стилизации в проектах
Конфигурация приложений на Angular. Лучшие практики
Как управлять файлами конфигурации среды и целями
Когда вы создали angular приложение с помощью Angular CLI или Nrwl Nx tools у вас всегда есть папка с фалами конфигурации окружения:
Можно переименовать environment.prod.ts в environment.production.ts например, также можно создавать дополнительные файлы конфигурации такие как environment.qa.ts или environment.staging.ts.
Файл environment.ts используется по умолчанию. Для использования остальных файлов необходимо открыть angular.json и настроить fileReplacements секцию в build конфигурации и добавить блоки в serve и е2е конфигурации.
Для сборки или запуска приложения с конкретным окружением используйте команды:
Создайте интерфейс для environment файлов
Не используйте environment файлы напрямую, только через DI
Использование глобальных переменных и прямых импортов нарушает ООП подход и усложняет тестируемость ваших классов. Поэтому лучше создать сервис который можно инжектить в ваши компоненты и другие сервисы. Вот пример такого сервиса с возможностью указывать дефолтное значение.
Отделяйте конфигурацию окружения и бизнес логики
Конфигурация окружения включает в себя только свойства которые относятся к окружению, например apiUrl. В идеале конфигурация окружения должна состоять из двух свойств:
Также в этот конфиг можно добавить свойство для включения дебаг режима debugMode: true или можно добавить имя сервера на котором запущено приложение environmentName: ‘QA’, но не забывайте что это очень плохая практика если ваш код знает что-либо о сервере на котором он запущен.
Никогда не храните какую-либо секретную информацию или пароли в конфигурации окружения.
Другие настройки конфигурации такие как maxItemsOnPage или galleryAnimationSpeed должны храниться в другом месте и желательно использоваться через configuration.service.ts который может получать настройки с какого то эндпоинта или просто загружая config.json из папки assets.
1. Асинхронный подход (используйте когда конфигурация может измениться в рантайме)
2. Синхронный подход (используйте когда конфигурация почти никогда не меняется)
Подменяйте environment переменные во время деплоя или в рантайме
Многие команды нарушают правило “Build once, deploy many” делая сборку приложения для каждого окружения вместо того чтобы просто подменять конфигурацию в уже собранном билде.
Не создавайте отдельные сборки с разными конфигурациями, вместо этого используйте только одну продакшн сборку и подменяйте значения во время деплоя или во время исполнения кода. Есть несколько вариантов как сделать это:
Заменить значения плэйсхолдерами в environment файлах которые будут заменены в итоговой сборке во время деплоя
Во время деплоя строка APPLICATION_API_URL должна быть заменена на реальный адрес апи сервера.
Использовать глобальные переменные и инжектить конфиг файлы с помощью docker volumes
Спасибо за внимание к статье, буду рад конструктивной критике и комментариям.
Также присоединяйтесь к нашему сообществу на Medium, Telegram или Twitter.
Angular: создание и публикация библиотеки
Начнем с начала
Если мне не изменяет память, то с версии 6 в angular появилась возможность создавать в одном workspace проекты разных типов: application и library.
До этого момента люди, которые хотели создать библиотеку компонент, скорее всего, пользовались отличным и полезным пакетом ng-packagr, который помогал создавать пакет в принятом для angular формате. Собственно, предыдущую библиотеку я создавал при помощи этого инструмента. Теперь команда angular включила ng-packagr в angular-cli и добавила schematics для создания и сборки библиотек, расширила формат angular.json и добавила еще несколько приятностей. Давайте теперь пройдем путь от ng new до npm install — от создания пустой библиотеки до ее публикации и импорта в сторонний проект.
Workspace создается как обычно
Будет создан workspace и проект приложения, заглянем в angular.json
Теперь добавим проект библиотеки
Посмотрим теперь в angular.json, у нас добавился новый проект
В директории проекта появилась следующая структура
Также, в tsconfig.json есть добавление в секции paths
теперь, если запустить приложение,то мы увидим стандартный работающий шаблон приложения angular
Создание функционала библиотеки
Давайте создадим библиотеку с сервисом, директивой и компонентом. Сервис и директиву разместим в разных модулях. Переместимся в директорию projects/test-lib/src/lib и удалим test-lib.*.ts, также удалим содержимое projects/test-lib/src/public-api.ts.
Переместимся в projects/test-lib/src/lib и создадим модули, директиву, сервис и компонент
Наполним компонент, сервис и директиву логикой. Компонент будет отображать поданный на вход список строк. Директива — добавлять красную рамку, сервис будет каждую секунду добавлять в Observable текущий timestamp.
Компонент список и модуль
! Важно. При генерации компонент и библиотек cli не создает export, так что в модулях обязательно добавьте в секции exports те компоненты и директивы, которые должны быть доступны.
Далее, чтобы в будущем классы из библиотеки были доступны, добавим немного кода в public-api.ts
Подключение библиотеки в тестовом приложении
Соберем проект библиотеки
Далее в app.module заимпортим модули с компонентом и директивой и добавим логику
И используем штуки из нашей библиотеки в приложении
Запустим и проверим приложение, все работает:
Сборка и публикация
Осталось собрать и опубликовать пакет. Для сборки и публикации удобно добавить команды в scripts в package.json приложения
Библиотека собрана, опубликована, теперь после установки в любом ином angular проекте
можно использовать компоненты и директивы.
Небольшое примечание
У нас в компании есть целое семейство npm пакетов, поэтому в нашем случае пакет должен публиковаться с namespace как company/test-lib. Для этого сделаем всего несколько правок.
В package.json библиотеки переименуем пакет
И чтобы в тестовом приложении библиотека была доступна по названию с namespace немного поправим tsconfig
И в тестовом приложении заменить импорты, например
Построение и глубокое погружение в компилятор Angular
Дата публикации: 2017-09-07
От автора: как вы уже знаете, я люблю Angular, и всю ту магию, которую с его помощью можно творить. Я подумал, что будет интересно посмотреть на построение компилятора Angular 4, попробовать его переделать и сымитировать некоторые участки процесса компиляции.
Разбор компилятора был очень интересной задачей, большую часть того, что я узнал, я рассказал на конференции ng-conf 2017: DiY Angular Compiler. Мне очень нравится учиться и возиться с чем-нибудь, и я подумал, что было бы неплохо поделиться частью знаний в форме блога! Представляю вам «очень глубокое погружение в компилятор Angular».
Как и в большинстве моих постов, будет лучше, если вы будете следовать за мной, поэтому прежде чем перейти к сути, вам нужно установить пару вещей:
Во-первых, нужно установить node.js и npm. Также нужна последняя версия Angular CLI (версия 1.2.0 или выше). Проверить версию можно так:
Бесплатный курс «Laravel + Angular. Быстрый старт»
Изучите курс и узнайте, как создать веб-приложение с нуля на Angular и Laravel
Результат будет выглядеть примерно так:
Если версия старая, установите последнюю версию Angular CLI:
Также нам понадобится еще один замечательный инструмент — source-map-explorer. Если у вас его нет, его можно установить:
Изоляция компилятора
Чтобы начать наше глубокое погружение в компилятор Angular, давайте создадим новый проект. Перейдите в любую подходящую директорию и введите:
Процесс компиляции программы займет пару минут, после чего вы получите новый проект в папке compiler-playground. Перейдите в эту папку и введите:
Команда создаст папку dist с скомпилированным приложением. Вы заметите, что конечные JS-файлы весят довольно много: если открыть папку dist, то там будет лежать файл vendor.bundle.js размером около 2Мб. Совсем не круто!
Если открыть этот файл, то внутри мы увидим неминифицированный код. На этот файл можно запустить uglify, что значительно сожмет его вес – примерно до 650Кб. Но это все равно много для простого приложения «Hello world».
Тут нам поможет source-map-explorer. С его помощью можно открывать сборку и смотреть, что делает ее такой большой. Введите следующую команду:
Подождите пару секунд, после чего мы получим примерно следующую картину:
Можно заметить, что модуль compiler занимает около 50% общего размера сборки. Это около 1Мб (или 320Кб в минифицированном виде) данных, которые пользователи должны скачивать.
К счастью, очень просто избавиться от компилятора. Просто запустите:
и часть, ответственная за компилятор, будет магическим образом удалена с помощью функции Angular AoT (“Ahead of Time”). AoT запускает шаг компиляции в момент создания билда, а не внутри браузера. Т.е. когда будете создавать билд проекта в продуктив, компилятор вообще может полностью исчезнуть, что сэкономит драгоценные циклы процессора при загрузке в браузере пользователя.
Теперь давайте взглянем на папку dist: вендорные JS-файлы сжались до 310Кб. С помощью source-map-explorer можно заметить, что большая часть, ответственная за компилятор исчезла:
Можно с легкостью избавиться еще от 30% размера, если удалить модули forms и http (если не будем их использовать). Надеюсь, в будущем система создания билда будет умнее и будет делать это за нас (для удаления неиспользуемого кода есть свой термин — tree-shaking). Если удалить forms и http (нам они не понадобятся) и включить сжатие, размер файл упадет до 79Кб.
Заметка: цифры могут слегка отличаться, все зависит от конкретной версии Angular.
Так что же компилятор Angular делает там? Как его можно удалить, и будет ли приложение работать после этого? Зачем он нужен на первом месте?
Чтобы понять роль компилятора, давайте посмотрим на внутреннюю работу Angular.
Внутри Angular: шаблоны и представления
При создании шаблонов мы задаем то, как должно выглядеть представление. В основном, мы с помощью языка HTML описываем структуру DOM и привязываем данные к ней. При старте приложения Angular должен создать DOM-дерево по вашему шаблону и заполнить его данными. Т.е. если вы напишите
Кроме того, Angular обязан мониторить значение свойства title и обновлять элемент при изменении значения.
В AngularJS (версии до Angular или версии 1.х) создание DOM отдавалось браузеру, который парсил ваш HTML и создавал дерево DOM (все-таки это его работа), после чего AngularJS пробегался по элементам DOM, распознавал директивы и выражения привязки и заменял их реальными данными (код в AngularJS, отвечающий за это).
Такой подход выявил несколько проблем. Во-первых, браузеры разные. Разные браузеры парсят один и тот же HTML в разные структуры DOM (пример), и Angular должен учитывать это. Также браузеры не так хорошо работают с ошибками – они зачастую пытаются скрыть ошибку, автоматически закрывая элементы или перемещая их. Даже если ошибка и отображается на экране, то в ней не указывается номер строки. Это сильно усложняет дебаг и ведет к закрытию приложения до тех пор, пока мы не найдем ошибку.
Кроме того, это значит, что нам нужен браузер лишь для парсинга наших шаблонов и рендеринга их в HTML, который уже можно передать клиенту и мгновенно отобразить (и поисковым движкам), что делает серверный рендеринг сложным и подверженным ошибкам настройки (более подробно здесь или здесь).
Наконец, по каким-то причинам HTML зависим от регистра в названии HTML-тегов и атрибутов. Также он не сохраняет оригинальный регистр, конвертируя имена тегов в верхний регистр, а атрибутов в нижний. Посмотреть это можно, если запустить:
На выходе вы получаете H1. Это заставило AngularJS использовать знаменитый змеиный регистр (например, ng-if, ng-model) вместо верблюжьего, который используется в JS.
Если использовать HTML-парсер браузера, мы получим разные результаты в разных браузерах, у нас не будет информации об ошибках, мы не сможем делать рендеринг на сервере, а также теряем регистр в атрибутах.
Вот зачем у нас есть компилятор. Компилятор заменяет браузер и парсит HTML. Это дает нам одинаковый результат во всех браузерах, а значит, он может выполняться на сервере (это просто кусок JS-кода, который парсит шаблоны), давать полную информацию об ошибках и сохранять регистр тегов/атрибутов. Также он дает нам парочку очень крутых инструментов, но о них чуть позже.
Компилятор Angular: производительность, производительность и еще раз производительность!
Компилятор Angular – удивительная инженерная мысль, что скоро мы и увидим. Он весит 1Мб не просто так – это результат больше года работы команды Angular. Он не просто парсит шаблоны, он также создает высокопроизводительный код и настроен на создание и обновление DOM с минимальными затратами процессора и памяти.
Цель добавления компилятора заключалась (и сейчас) в снижении нагрузки на память, быстрой загрузке страниц и быстром обнаружении изменений. Вот ссылка на исследования, выполненные перед внедрением компилятора в Angular 4: генерация Less кода.
Сейчас команда Angular усердно работает над улучшением инструментов и интеграции с компилятором Closure, инструментом, который применяет агрессивную оптимизацию к JS-коду, что еще сильнее сжимает размер билда и снижает время выполнения. Вот что мне нравится в Angular – за ним стоит замечательная команда, которая постоянно его улучшает, и наши приложения становятся быстрее и лучше, прям как хорошее вино. А плоды их тяжелой работы мы получаем бесплатно!
Теперь перейдем к компилятору!
Запуск компилятора
Вставьте эти строки в секцию scripts в файле package.json:
Подождите пару секунд, и вы увидите, что в папке проекта создалось много файлов. Ваш файл app.component.html превратился в app.component.ngfactory.ts, а app.module.ts теперь app.module.ngfactory.ts. CSS-файлы превратились в шимы. Ниже мы рассмотрим все файлы.
Компоненты (создание представления и определение изменений)
Компилятор Angular трансформирует наши 3 строки HTML в шаблоне в app.component.ngfactory.ts. Если открыть этот файл, то в нем можно увидеть много кода, который сложно понять сразу. Этот код написан для машин, а не людей – вот почему нам нужно немного терпения и навыков реверс инжиниринга. Тут нам поможет TypeScript.
Всего 3 строки HTML дали столько кода!
Первое, что бросается в глаза – множество непонятных методов, объявленных с помощью ɵ (греческая Тета), после которой идут 3 латинские символа (например, ɵvid). Буква ɵ используется командой Angular для индикации того, что некоторые методы имеют видимость private для фреймворка и не должны вызываться напрямую пользователем, так как API для этих методов не гарантирует стабильность между версиями Angular (на деле, я гарантирую, что почти всегда это не работает).
Бесплатный курс «Laravel + Angular. Быстрый старт»
Изучите курс и узнайте, как создать веб-приложение с нуля на Angular и Laravel
Почему используется 3 символа, а не полное название метода – экономия байтов в финальной сборке. Но если сделать Ctrl+click на этих методах (в Visual Studio Code или WebStorm), вы увидите полные названия методов. Для ɵvid это будет viewDef, функция, которая определяет представление.
Попробуйте изменить шаблон представления (app.component.html) и заново запустите компилятор angular (npm run compile). Посмотрите, как ваши изменения отразились в скомпилированном файле. Например, попробуйте изменить шаблон так:
И посмотрите, что будет в скомпилированном виде.
Большая часть магии происходит в методе View_AppComponent_0, который состоит из двух частей: верхняя часть определяет вид – т.е. все элементы, которые необходимо создать, их атрибуты, текст и т.д., и нижняя – отвечает за определение изменений. Такое разделение позволяет Angular быть эффективным инструментом – верхняя часть запускается только один раз при создании представления, а нижняя часть запускается, когда Angular выполняет определение изменений.
Верхняя часть запускается только один раз при создании представления, а нижняя часть запускается, когда Angular выполняет определение изменений
Модули
Мы используем модули для организации наших приложений в компоненты и сервисы. Это задает контекст для разрешения компонентов и вставки зависимостей: компилятор заглядывает в модули и решает, какие компоненты доступны для других компонентов. В отличие от AngularJS, пайпы и компоненты не глобальные, они доступны только в контексте модуля, в котором объявлены или импортированы из другого модуля. Это предотвращает коллизии с именами при создании больших приложений на Angular.
Ниже мы взглянем на то, как вставка зависимостей реализована в Angular. Вы можете представить, что это будет какой-то объект или Map, который будет соединять все имена классов или токены с имплементациями. И действительно, AngularJS использовал объекты для этих целей. Недостаток объектов в том, что их индексы всегда конвертируются в строку, т.е. мы можем использовать только строки в качестве токенов при вставке зависимостей.
В Angular все по-другому – фреймворк взял другой подход, который позволяет использовать классы и другие объекты как токены при вставке зависимостей. И что же это?
Если открыть файл app.module.ngfactory.ts, там можно найти очень длинный метод getInternal(). Именно так выполнена вставка зависимостей в Angular. Сперва я подумал, что это было сделано для повышения производительности – возможно, куча if на тот момент была самым эффективным способом сопоставления значений в JS?
Я спросил команду Angular и мне сказали, что главная причина такого подхода в том, что он позволяет лучше удалять неиспользуемый код. Компилятор Closure умеет определять неиспользуемые сервисы и удалять их из финальной сборки.
Как только найдено совпадение, релевантный if запускает геттер, который создает объект сервиса при первом запуске. В остальных случаях он возвращает уже созданный ранее объект. Т.е. вставка зависимостей это просто куча if’ов.
Пример: геттер сервиса Compiler, создающий объект по требованию
В случае если какой-то сервис зависит от другого, то это будет известно во время компиляции, и мы можем найти подходящий сервис до получения объекта и передать его в качестве параметра в конструктор:
Сервис Testability зависит от NgZone, поэтому его объект будет создан и передан в конструктор сервиса Testability
Повеселимся с инструментами
Мы можем написать еще много страниц про возможности инструментария в Angular Compiler, но я хочу вызвать один инструмент — Language Services.
Angular Language Services позволяет запускать компилятор в любимой IDE (WebStorm, Visual Studio Code), пользоваться автокомплитером, детальными ошибками при редактировании шаблонов. Если вы раньше не работали с ними, вам точно стоит попробовать: эти инструменты сделают из вас более лучшего разработчика. Если работаете с VSCode — вот расширение.
Minko Gechev также упоминал пару хороших способов использования в своем выступлении на ng-conf 2017 talk: Mad Science with the Angular Compiler. Помимо создания инструментов поверх компилятора для автоматической миграции между версиями Angular и визуализации структуры приложения, где-то он даже создает 3D-модель приложения со всеми компонентами в виде… деревьев!
Практика: сделай сам!
Мы лишь прошлись по поверхности компилятора Angular, изучать еще очень много. Я оставлю вам 3 упражнения, которые помогут вам лучше почувствовать принцип работы компилятора, если вы лучше понимаете все на практике. Во всех упражнения вам предстоит вручную попробовать выполнить трансформации, которые делает компилятор.
Прежде чем мы начнем, давайте переключим код, чтобы поглощать скомпилированный код, чтобы вы могли его менять и видеть результаты.
Во-первых, запустите ng serve и проверьте, что приложение работает (//localhost:4200), так как после изменения точки входа в приложение, webpack плагин Angular будет возвращать ошибку (она будет происходить при инициализации webpack). Обойти ее можно, запустив ng eject и перенастроив webpack на использование чистого typescript плагина, но здесь это не важно.