Сборщик проектов на Angular и RequireJS и некоторые мысли по сборке

Тут и gulp и webpack и lodash'евский шаблонизатор

gulp в качестве таск раннера, webpack — бандлер. FYI webpack это не замена gulp, это сборщик модулей и только. Что до lodash — это скафолдинг для генерации компонентов, что бы уменьшить количество рутины. С тем же успехом можно было бы использовать yoman но у меня еще руки не дошли вынести это все в yo (обсуждали в gitter). С прагматичной точки зрения решение более чем вменяемое на данный момент. Опять же пулреквесты мы приветствуем.

Из-за Babel livereload работает дольше

Инкрементные билды в плане. Справедливости ради вариант с systemjs + http2 (для разработки) работает пошустрее за счет кеширования.

Чтобы весь этот стек поддерживать нужно знать уйму технологий.

угу, gulp знают все, lodash — там только шаблончики подправить. Опять же я не знаю людей которые не работали с ледашевскими шаблонами, да и как бы для кодогенераии альтернатив не много. Что до webpack — я бы срадостью заменил это дело на jspm + system.js но на данный момент webpack справляется хорошо, а у jspm до сих пор есть небольшие проблемки (которые надеюсь скоро устранят).

Как делать билд для продакшена

Продакшен билды в плане. Я только на днях нашел время добавить ng-annotate, на следующей неделе планирую добавить prod настройки для webpack. В целом же в документации по webpack все это описано.

С этого момента можно только начать подумывать над подобной архитектурой.

С чего бы это? Компонентный подход потихоньку обкатывают уже начиная с angular 1.2. Я уже где-то год так делаю. В 1.5 они просто вкатили упрощенный вариант управления этим что бы упростить миграцию на angular2.

Чем ES6-модули принципиально лучше AMD-модулей?

Тем что они читабельнее и являются частью стандарта. У AMD преимуществе перед ними нет никаких (почти). Я сейчас готовлю маленький PR что бы чуть упростить управление модулями (я ng6-starter уже на 4-х проектах использую и конечно же у меня уже побольше всего понапридумано).

Можно сравнить:

нельзя. Вы забыли объявление модуля, зависимости и т.д. Вы же не используете один модуль на все приложение?

Я же например планирую переделать все это так:

import angular from 'angular';
import uiRouter from 'angular-ui-router';

export default angular
  .module('about', [
    uiRouter
  ])
  .config(($stateProvider) => {
    "ngInject";
    $stateProvider
      .state('about', {
        url: '/about',
        template: '<about></about>'
      });
  }).name;

Разбивать структуру на common и components — плохое решение (уже проходили).

Я тоже проходил это и в итоге вернулся. Выношу туда все то что можно потом вынести в отдельный репозиторий (например фильтрики по датам и другие не привязанные к приложению UI компоненты). Причем чаще я все это просто выношу постфактум из components в common.

Что там куда перетекать должно мне лично не понятно. Либо у вас в common не независимые компоненты либо не знаю что еще. Достаточно просто указать зависимости от навбара в модуле news и все хорошо.

разбитую по бизнес-логике, а не синтетически

Все просто, в components application-specific UI компоненты, в common какие-то общие вещи не привязанные к конкретному приложению. Бизнес логика (сервисы) у меня сейчас вообще отдельно лежат, не привязываясь к компонентам и ангуляру в принципе.

Таким образом в user могут быть login и register

Ну так оно как-то так и должно быть. А вот контрол «repeat password» или «view password» можно уже положить в common. Или эта идея звучит бредово?

продакшеном тут и не пахнет.

2 проекта на этом шаблоне (естественно допиленные) в продакшене уже, все хорошо, полет нормальный, скорость разработки и поддержки кода по сравнению с другими шаблонами (своими и чужими) сильно выше.

Уверен что большинство темплейтов появились не из пустого место

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