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

[VasilioRuzanni]

Похоже, что вы просто придумали Webpack или Brunch, но менее навороченный в плане фич и возможностей. К тому же, не вполне понятно, зачем/причем тут вообще require.js в том или ином виде — SystemJS (плюс SystemJS Builder) и Webpack замечательно умеют работать с модулями самых разных форматов. Понятно, что там свои конфиги, но все равно неясна ниша этой разработки — немного похоже на brunch (но на базе gulp) и не предлагается ничего кардинально нового.

И совершенно непонятен тезис насчет

А как же Babel, ES6, Coffee, TypeScript? А никак. Сборка создавалась для использования в больших и средних проектах в продакшене. Если у вас университетская исследовательская работа или домашняя страничка, зачем вам вообще сборка? А если всё это в серьезном проекте, да в продакшене… Положим еще раз руку на сердце, вы просто изучаете новые технологии за счет работодателя.

Что бы это вообще значило? То, что все вышеперечисленное — игрушки для студенческих поделок?

[tamtakoe]

Это более высокий уровень абстракции. Пользователю предлагается оптимальная структура проекта и оптимальный с точки зрения быстродействия результат сборки. Так же ему не придётся задумываться о поиске и настройке плагинов, т. к. всё что нужно включено в сборщик и настроено. Идея в том, чтобы фронтендщик установил однажды модуль и навсегда забыл о сборке.

Если webpack или другая технология подойдёт лучше gulp в качестве основы и вы сможете объяснить как её настроить подобным образом — буду благодарен.

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

[tamtakoe]

Так покажите проект на аналогичной технологии. Свой или любой, который нравится. Отовсюду слышу про Вебпак, Реакт, что там всё круто, но не видел ни одного проекта, архитектура которого покрутилась бы год-два в продакшене, чтобы можно было скачать и сразу клепать своё на основе.

[xamd]

Так, ну React использует Facebook, Airbnb, Khan Academy, Filpboard как минимум (это первое, что приходит на ум). Вообще, есть целый тред на эту тему. Могу то же самое найти для Webpack, но я полагаю Вы тоже умеете пользоваться поиском.

[tamtakoe]

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

[Fesor]

давайте так, покажите мне проект на angularjs в опенсурсе на код которого было бы не стыдно смотреть. Я вот что-то не видел. А те что видел и подходят под описание закрыты NDA.

Почти все крутые штуки закрыты NDA.

[tamtakoe]

Так я его и выложил в этой статье! Специально заморочился с примером github.com/tamtakoe/node-arjs-builder-seed
Основные вещи настроены, конфиги написаны, общая структура ясна, даже роутинг с ресурсами прикручены, хотя это уже углубление в архитектуру. Конечно, там есть код за который мне стыдно, но его не много и он не столь важен для понимания сути. Скачиваете, запускаете, всё сразу работает и готово к использованию.

Что такое NDA? Его используют аутсорсеры, или стартаперы (тот случай, когда все гонят и на развитие не хватает времени, так что сомневаюсь на счет крутых штук). При этом подобные ограничения накладываются на бизнес-логику и узкоспециализированные вещи. Архитектура — слишком обширное понятие — это опыт, который кочует из одной компании в другую, который содержит в себе наработки других людей, в т. ч. открыто опубликованных. Чтобы к тебе прикопались нужно доказать, что написание структуры, сборки и проч. было утверждено в плане разработки, что всё это написано сотрудниками с нуля в соответствии с этим планом (в т. ч. все исследования, переделки и проч.), написано в компании в рабочее время, а не дома, что большинство фишек не позаимствовано из открытых источников, что в этом есть исключительно интеллектуальная собственность компании и она понесла какой-то урон (компаниям важно чтобы с их ноу-хау все было в порядке, а все эти архитектуры им до лампочки). На деле, прицепиться не реально, поэтому писать статьи на общие темы и публиковать компоненты общего назначения можно совершенно безболезненно.

[Fesor]

Так я его и выложил в этой статье!

вы выложили сид, темплейт проекта. Я так тоже могу: NG6-starter (немного пиара, извините, но это пожалуй лучший темплейт проекта который я пока видел, потому и помогаю его мэйнтейнить).

Мой же комментарий был к этой фразе:

Имею в виду проекты где можно было бы посмотреть код и минимальную документацию к нему.

То есть я говорил о реальных проектах которые можно посмотреть. Архитектура без проекта это просто теория, на практике все чуть подругому да и нагляднее. И нормальных проектов на angular на гитхабе днем с огнем не сыщешь (как и symfony2, reactjs и многие другие годные фреймворки).

Архитектура — слишком обширное понятие — это опыт

принцип единой ответственности, сегрегация интерфейсов, инверсия зависимостей и все клево. Добавим сюда в контексте ангуляра MVC (или MVA, кому как удобно, не забывая при этом про ViewModel которая только добавляется между View и Model), компоненты, идеи функционального программирования (javascript же) и получаем все что нужно для построения архитектуры UI приложения (angular в конце концов это UI фреймворк).

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

А сборка проекта — это вообще минимальной важности штука. Оно конечно важно для наших процессов, что бы устранить как можно больше рутины и помогает разработчикам сосредоточиться на главном. Без разницы как оно организовано. Мне вот webpack не нравится но я могу настроить сборку проекта удобно за пару часов, и не париться, в то время как предыдущий свой темплейт проекта я собирал где-то пару дней, и до того уровня удобств которые предоставляют бандлеры типа system.js или webpack там было очень далеко.

AMD же по по моему весьма субъективному мнению смотрится в проектах с angular весьма ужасно, как минимум потому что у нас уже есть своя система модулей а синтаксис AMD самый объемный в плане необходимого написания кода. Я использую babel + es6 модули и… все просто работает и все просто удобно.

[tamtakoe]

За NG6-starter огромное спасибо! Есть с чем сравнивать. Напишу о своих впечатлениях. Первое естественно негативное. Даже если опустить, что пару часов пытался его запустить github.com/AngularClass/NG6-starter/issues/65, то код, который увидел поверг в ужас. Тут и gulp и webpack и lodash'евский шаблонизатор и ES6 c Babel'лом и страшные конфиги. Чтобы весь этот стек поддерживать нужно знать уйму технологий. И, вообще, зачем весь этот сборочный хлам держать в каталоге приложения, а не в node-modules?

Из-за Babel livereload работает дольше. Как делать билд для продакшена (по модулям с md5 именами) так и не понял. Документация молчит.

Чем ES6-модули принципиально лучше AMD-модулей? На пару скобок меньше писать в каждом файле? Это из разряда, что плохому танцору всегда что-то мешает. Можно сравнить:

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

let aboutModule = angular.module('about', [
  uiRouter
])

.config(($stateProvider) => {
  "ngInject";
  $stateProvider
    .state('about', {
      url: '/about',
      template: '<about></about>'
    });
})

export default aboutModule;

define([

  'app'

], function(app) {

  app.config(function($stateProvider) {
    $stateProvider
      .state('about', {
        url: '/about',
        template: '<about></about>'
      });
  });
})

Библиотечные зависимости типа uiRouter зачем-то тянутся в каждый компонент. В статье даже графиком проиллюстрировал, что все библиотеки лучше собирать в один файл и подключать ко всему проекту разом. Создавать для каждого компонента отдельный модуль излишне в Angular 1.x, потому что все сервисы в глобальной области видимости. Объявлять в конструкторе каждого контроллера его имя, вообще, суровый костыль. Из-за всех этих условий пришлось генератор компонентов написать, потому что создавать вручную — много мороки. Лучший генератор всех времен и народов — копи-паст. Надеюсь, они к этому придут.

Разбивать структуру на common и components — плохое решение (уже проходили). Сначала в common'е navbar, потом footer, потом news в footer, потом раздел news в components и всё — пересечение — половина компонентов в common перетечет. Лучше делать однородную структуру (+ с ней легче работать), разбитую по бизнес-логике, а не синтетически. А уже в каждом из ее компонентов делать вложенные, если нужно. Таким образом в user могут быть login и register, которые могут использоваться в том же navbar для отображения формы входа/регистрации.

Из хорошего могу отметить направленность на компонентный подход (тоже приду к этому). Но ребята явно бегут впереди лошади. Ангуляровцы всего неделю назад выкатили module.component. С этого момента можно только начать подумывать над подобной архитектурой. В противном случае всё выливается в кучу никому не нужных костылей. Проект явно исследовательский, продакшеном тут и не пахнет.

Еще страничка Browsersync ничего такая. Можно развивать это направление.

По поводу «архитектура без проекта — теория». Уверен что большинство темплейтов появились не из пустого место, а выросли из нескольких проектов, так что не просто теория :-)

[Fesor]

Тут и 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 проекта на этом шаблоне (естественно допиленные) в продакшене уже, все хорошо, полет нормальный, скорость разработки и поддержки кода по сравнению с другими шаблонами (своими и чужими) сильно выше.

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

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

[tamtakoe]

Или эта идея звучит бредово?

«repeat password» или «view password»… В моем случае директива поля ввода пароля с глазиком лежит в common/components/form/password как элемент абстрактной формы. Ничего бредового.

Инкрементные билды в плане...

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

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

Пометил вещи, которых не должно быть в объявлении компонента:

import angular from 'angular';
import uiRouter from 'angular-ui-router'; //Зачем глобальные зависимости в каждом компоненте?

export default angular
  .module('about', [ //В крайнем случае включить uiRouter, ngResource и проч. в lib
    uiRouter //и подключать везде его,
  ]) //но и это попахивает костылем
  .config(($stateProvider) => {
    "ngInject"; //Лишнее
    $stateProvider
      .state('about', {
        url: '/about',
        template: '<about></about>'
      });
  }).name; //Зачем разработчику помнить, что нужно всегда экспортировать name?

на днях нашел время добавить ng-annotate

Обязательно сделайте пример с одновременным использованием angular-bootstrap и angular-strap. У них пересекается сервис $tooltip и их совместное подключение разруливается исключительно ng-annotate.

Интересный проект. Буду следить, как развиваете компонентный подход и используете технологии типа webpack, systemjs, jspm, на которые пока серьезно не смотрел.

[Fesor]

Зачем глобальные зависимости в каждом компоненте?

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

//Лишнее

не уверен на 100% — пусть будет. Я добавил там ng-strict-di еще что бы детектить где надо это добавить. Сам же я добавляю метки для ngAnnotate почти всегда. Мне проще добавить метку чем расстраиваться что оно не подхватило это дело.

//Зачем разработчику помнить, что нужно всегда экспортировать name?

Потому что пока мы не на angular2 нам приходится за этим следить самостоятельно и экспортировать только имена модулей. Между прочим так сделано почти во всех крупных модулях для ангуляра.

[dixoNich]

Слышать то мало, надо вникать. У нас angular + webpack (babel, stylus, jade). Перешли с gulp на webpack и стали очень счастливыми людьми. Всё на продакшене, всё хорошо.

[tamtakoe]

Можете показать код сборки (можно в личку, если секретно)

[tamtakoe]

Специально статью написал, чтобы собрать фидбек и узнать об аналогах)

[dixoNich]

А TypeScript? А Coffeescript? Тоже баловство, получается? Babel отлично работает и ни разу не было ситуации с тем, что где-то что-то пошло не так.

Если webpack или другая технология подойдёт лучше gulp в качестве основы и вы сможете объяснить как её настроить подобным образом — буду благодарен.

Как минимум webpack из коробки поддерживает commonjs модули. То, что сделали вы, у нас занимает около 70 строк, у вас же около 500.

[tamtakoe]

Кофескрипт, вообще, первый показатель того, что человека не стоит брать на работу по причине неадекватности. Как правило, это люди, пришедшие с бекенде или языков с похожим синтаксисом, которым лень освоить обычный js, либо те кто без разбору хватается за всё новое, пытаясь сэкономить на спичках вместо того чтобы писать по сути лучший код. (Сорри, если кого-то задел. Это субъективные наблюдения)

За Тайпскриптом наверняка будущее, но оно настанет не раньше чем через 3 года. Недавно специально прошёлся с поиском по своим проектам и по популярным фреймворкам, чтобы узнать в скольки местах можно применять новые фишки. Оказалось, что классов в проектах используется не больше 10 штук, стрелочные функции были нужны в ~5 местах и остальной сахар так же не настолько уж необходим.

Про commonJs и AMD та же история. Синтаксисы имеют одинаковую сложность, только AMD работает без компиляции. История о том, что можно использовать одни и те же модули на фронтендщик и на ноде не выдерживает никакой критики. У них совершенно разный код в 99,9% случаев.

Стандартная просьба. Покажите, пожалуйста, ваши 70 строчек. Не скажу, что горю желанием поддерживать очередную библиотеку. Если найду решение лучше — возьму на вооружение.

[SerafimArts]

Это уж слишком субъективные наблюдения. Что Coffee, что ES6-7 Babel будут в разы продуктивнее и удобнее нативного JS (ES4-5). В результате код будет на порядок быстрее писаться, быстрее читаться и быть вне конкуренции по качеству написания. И в 90% использующий знает JS, т.к. в перечисленных мною выше без знаний оного не обойтись.

P.S. Что касается TS — если не вдаваться в детали — это лишь небольшая надстройка над Babel + Flow.

[serf]

Coffee баловство, TypeScript нет.

[SerafimArts]

А что отличает «баловство» от «не баловства»?

[serf]

Не баловство приносит ощутимую пользу, которая перевешивает накладные расходы использования абстракий от JS (усложнение инфраструктуры сборки, осваивание дополнительного синтаксиса, поиск экспертов в команду знающих эти ваши свистопределки, и прочее). Так вот, кофи по крайней мере в наше время, не нужен, изначально может быть для кого-то в нем и был смысл (не для меня). TS потенциально приносит больше пользы, так что его можно использовать.

[SerafimArts]

Кофе, зная JS, можно изучить за пару дней при этом пользы он приносит в разы больше нативного JS. Так что следуя вашей логике — JS это откровенное баловство.

Если у вас непереносимость синтаксиса — так и скажите, но при выборе одного из двух — TS vs. Кофе я бы однозначно сделал ставку на кофе, в нём больше удобств, которые позволяют писать более лаконичный и чистый код.

При сравнении всех существующих решений я бы выстроил их так (в порядке удобства использования):
1) ES6-7 Babel
2) CoffeeScript
3) Haxe
4) TypeScript
5) Native JS

P.S. Предпоследнее место TS просто из-за слишком сильных ограничений в типах, когда на это тратится существенно больше времени, чем непосредственное написание кода.

[serf]

Кофи себя давно изжил и спорить здесь не о чем, TS дает реальные преимущества (особенно для больших проектов), кофи лишь сахарок, для меня этот сахарок не стоит того чтобы его внедрять в проекте. Делать ставку на кофи в конце 2015 года глупо.

ps dart забыли

[lega]

ES6-7 Babel, CoffeeScript, TypeScript, Native JS

Проблемы есть у всех вышеперечесленных, ES6 Babel — браузеры ещё не поддерживают ES6 (ES7) полностью, поэтому его придется компиллировать в ES5 ещё долгое время для всех браузеров, а Babel дает не «лучший» код (хотя он имеет ряд опций для этого), но для написания веб-приложений это не важно, это может быть важно при написании критичных к скорости участков, Babel можно смело пробовать для приложений.

CoffeeScript и TypeScript — оба «сахар», их оба нельзя будет запустить не компиллируя, они дают свои плюшки и проблемы, в CS есть генераторы и нет async/await, в TS есть async/await, но нет генераторов, CS дает лакончиность и краткость, но его многие не переносят, TS дает «типы» и тулзы, но его многие не любят за «многословность».
Они не в одном ряду с Babel (разные цели), они могут использоваться с Babel совместно (CoffeeScript/TypeScript -> ES7 Babel -> ES5).

CoffeeScript хорош, но у него есть проблемы со впихиванием фичей из ES7 и из-за этого он будет угасать, и сообществу пора инициировать CoffeeScript 2, иначе CS может вымереть.

С Native JS итак все ясно.

Вообщем, как обычно — идеала нет.

[SerafimArts]

Ну над CS вместе с плюшками ES давно ведётся работа вроде такого: https://github.com/jashkenas/coffeescript/pull/3813 в версии 1.10 добавили ES6 деструктуризацию. Но в целом согласен, когда появился babel — кофе значительно начал проигрывать. По-этому я и написал его вторым в списке, т.к. при выборе между Babel и Coffee — выбор мой однозначно за первым.

[Fesor]

Coffee — оптимизация процессов под быструю разработку, TypeScript — для крупных проектов. Babel — что-то среднее.

[serf]

поддержку, кофи протух и вооще не стоит внимания в наше время

[xamd]

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

Последняя утвержденная спецификация языка для Вас — «бежать впереди поезда»?

Я не хочу никого обидеть, но затем создавать приложения на стеке умирающих технологий? Когда выйдет Angular 2, про первый будут помнить разве что те, у кого всё приложение в данный момент завязано на него, а что касается requirejs, то несмотря на свою дикую популярность 4 года назад, на нынешний день имеет на 100 000 скачиваний в месяц меньше, чем webpack и, на секундочку, на ~2 233 089 скачиваний меньше, чем browserify.

Вы так интересно рассуждаете о технологиях — «сегодня популярны, а завтра — забыли», но ведь уже «сегодня» про requirejs забыли, а про angular 1.x забудут, считай что «завтра».

[vinograd19]

Не стоит так переоценивать angular2. Это не более чем еще один js фреймворк, коих сейчас очень много. То, что в его названии есть слово angular я воспринимаю просто как маркетинговый ход. Каким бы плохим не был angular1, ему удалось создать вокруг себя сообщество, а это куда важнее «академической правильности», новизны, или даже отсутствия багов.

Про переезд python 2->3 в 2008-м тоже говорили «Да пару лет, и все забудут про вторую версию».
Но сообщество языка/фреймворко обычно гораздо более инертно, нежели работа авторов. И вот сейчас уже 2015, а нового продакшн-кода под python2 создается раза в 2 больше, чем под python3.

[tamtakoe]

Именно по этому стараюсь делать сборщик, да и архитектуру приложения под технологии, а не под фреймворки. Т.е. Он работает с проектами поддерживающими DI (просто сейчас это реализовано через RequireJS), проектов с веб-компонентами (реализация ангуляровскими директивами), ORM (ангуляровскими ресурсы), кеширование (http/templateCache). В самом проекте свожу использование фишек Ангуляра к минимуму, например, никогда не используются ng-controller и ng-include (всё через роутер), никогда не используется $http (всё через $resource). Это позволит легко перейти на Angular2, а если он не выстрелит, на что-то другое. Потому что фреймворки меняются, а технологии остаются :-) Напишу подробнее в статье по архитектуре.

RequireJS и Gulp всего лишь инструменты для реализации идеи. Их можно и заменить.

P.S. Последняя утверждённая спецификация- это бежать впереди поезда. Ехать на поезде — это спецификация, поддерживаемая основными браузерами

[SerafimArts]

Возможно на счёт поездов Вы и правы, только текущий «вагон» ну ни разу не удобен, когда уже пристрастился к люксовуму ES6\7, который, между прочим бесплатный и проверенный временем в боевых проектах.

[Fesor]

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

Знаете я тоже когда-то страдал подобным «перфекционизмом» а потом мне надоело. Сборка проекта — это второстепенная штука, часть инфраструктуры. Все что должна делать сборка — собирать проекты, быть неприхотливой к поддержке и т.д. бандлеры вроде webpack/system.js с этим справляются наура.

Если webpack или другая технология подойдёт лучше gulp в качестве основы

gulp — это таск раннер и только. Его задача — предоставить пайплайн для сборки. Webpack — это бандлер, его задача взять все ваши модули (js файлики, можно jade/html файлики, стили и т.д.) и собрать в соответствии с графом зависимостей и т.д.

вы сможете объяснить как её настроить подобным образом

подобным образом — не уверен что в этом есть смысл. Мне нравится та структура проекта которую я использую (потому что я могу эффективно делать свою работу не парясь по поводу сборки). Да конечно иногда коребит что есть не совсем православные вещи, но это опять же все определенные уступки в пользу скорости разработки. В конце концов jspm + system.js решают те же проблемы более православно.

использование в продакшене языков не поддерживаемых основными браузерами

Тогда давайте не будем использовать css с вендорными префиксами. Или js api с вендорными префиксами (хотя с этим сейчас проще).

babel транспайлит все в ES5, который более чем поддерживается основными браузерами. А то ускорение в плане разработки и повышение поддерживаемости кода более чем окупает «баловство». Вы же пользуетесь полифилами, да?

[tamtakoe]

Смотря что имеете в виду под полифилами. За глаза хватает того, что предлагает Angular и lodash. От jQuery уже избавились (lodash на очереди). В том-то и дело, что ES6 фишки далеко не так сильно востребованы как об этом пишут. Классы и какие-то сложные вещи не нужны, потому что Angular и архитектура проекта берут это на себя и бизнес-логика описывается простым кодом. А сахар… Можно и без него прожить.

Резко высказался. Я не против ES6, Babel и т. п. Я против того, чтобы использовать эти вещи для разработки. Если последний Хром поддерживает ES6, то пусть разработчики отлаживают в нём, а сборщик просто соберет финальный билд под ES5 или соберет специальную версию для старых браузеров (сейчас это не поддерживается, но потом добавлю), Babel в роли Autoprefixer для JS вполне катит.

На счет Webpack всё жду, когда кто-нибудь напишет: Вот наш конфиг для Вебпака, который делает примерно то же самое, но без кучи самописных вещей :-)

На счет структуры проекта, жду когда кто-нибудь выложит свою структуру. Пусть с костылями, пусть не на Ангуляре. Просто не с чем сравнивать.

[vinograd19]

Собирать билд можно будет вовсе без RequireJS

Посмотрите в сторону almond.js

[bakhirev]

Клевая штука, нужно обязательно заюзать у себя! Но так до конца и не понял:

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

Вы парсите html файлы? Если да, тогда зачем что-то ограничивать, можно распарсить и выявить все зависимости по цепочке. Если нет, тогда почему не парсите? Можно какой-нибудь утилитой сначала составить список всех файлов в проекте, чтобы найти все html`ки.

[tamtakoe]

Сборка начинается с того, что по цепочке зависимостей вытягиваются js-файлы. Далее рядом с каждым js-файлом ищется файл template.html и style.css (styl, less,...). Если находится, то теплейт добавляется в $templateCache Ангуляра, а стиль в файл со всеми стилями. Такая выборочность позволяет отключать любые части от проекта не удаляя отключенные файлы из проекта (достаточно убрать их из зависимостей). Также можно заимствовать какие-то модули из других проектов и быть уверенным что вместе с ними загрузятся их шаблоны и стили.