Рекомендации по настройке окружения для оптимизации скорости сборки EmberJS-приложений.

Рекомендации по выбору операционной системы для ember-cli

Если есть возможность выбрать операционную систему на которой будут разрабатываться ember-приложения, то рекомендуется использовать один из современных Linux-дистрибутивов. В этой операционной системе сборка выполняется максимально быстро благодаря особенностям файловой системы (источник).

Рекомендации по настройке окружения для сборки под ОС Microsoft Windows

Если сборка проекта занимает больше 1-3 минут, то попробуйте воспользоваться следующими рекомендациями.

  1. Следует добавить каталог с проектами на EmberJS в исключения для Windows Defender или любых других антивирусов. Во время сборки обрабатываются десятки тысяч небольших js-файлов.
  2. Для каталога с проектами на EmberJS отключить индексацию. В свойствах каталога Общие -> Атрибуты -> Другие -> Атрибуты индексирования и архивации -> снять галку Разрешить индексировать содержимое файлов в этой папке в дополнение к свойствам файла.
  3. Рекомендуется использовать консоль с правами администратора. В консоли с правами администратора поддерживаются символьные ссылки (symlink), что даёт ощутимый прирост скорости сборки.
  4. Рекомендуется использовать SSD-диск вместо HDD, в т.ч. для папки с кешами npm, yarn, bower. В случае использования npm link или yarn link убедитесь, что все файлы, участвующие в сборке будут находиться на SSD.
  5. Можно настроить RAM-Disk для устройств без SSD, но с достаточным объёмом оперативной памяти.
  6. В качестве меры, которая почему-то работает - удалить папки node_modules и tmp, а также, если вы уверенны, файл yarn.lock, после чего переустановить пакеты и собрать приложение (источник). Удаление папки tmp, которая не очищается сама, если терминал с запущенным приложением завершается аварийно (не останавливается нажатием Ctrl+C).

Рекомендации по настройке сборки приложения

  1. Отключить тестирование и проверку стиля написания кода при сборке приложения. В файле ember-cli-build.js, в объект с опциями для сборки, добавить следующие свойства: { tests: false, hinting: false, 'ember-cli-qunit': { useLintTree: false } }. В тестировании при сборке особой необходимости нет, а ввиду большой кодовой базы тестирование занимает существенный объём времени. Запускать тестирование явно командой ember test.
  2. Проанализировать что в вашем конкретном проекте занимает максимальное время при сборке и попробовать побороть эту конкретную проблему, например, это может быть проблема с типами зависимостей. Долгое время сборки - это не ещё приговор, а интересная техническая задача!

Как не попасть в ад зависимостей при сборке приложения

Для приложения нет большой разницы, к какому типу вы относите его зависимости, но обычно это зависимости разработки (devDependencies), потому что, после сборки вы получаете готовый к использованию bundle.

При разработке аддона, другие используемые аддоны, по умолчанию следует относить к зависимостям разработки, или равным зависимостям (peerDependencies), и устанавливать их в приложение с помощью блюпринта аддона. Некоторые аддоны учавствуют в процессе сборки, и должны быть установлены как обычные зависимости (dependencies), например таким аддоном является ember-test-selectors.

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

Рассмотрим на следующем примере, в приложении my-app используются аддоны my-first-addon и my-second-addon, которые в свою очередь используют аддон my-third-addon как обычную зависимость, получается примерно следующая структура:

my-app
+-- my-first-addon
| `-- my-third-addon
`-- my-second-addon
  `-- my-third-addon

Таким образом, при сборке приложения, сборка аддона my-third-addon будет выполнена дважды. Чтобы этого избежать, необходимо использовать аддон my-third-addon как зависимость разработки, в аддонах my-first-addon и my-second-addon, а также в приложении my-app, получая примерно следующую структуру:

my-app
+-- my-first-addon
+-- my-second-addon
`-- my-third-addon

Дополнительные материалы

Tags: EmberJS