Собрание ваших сочинений на Angular.js

[Santacruz]

yeoman.io/ + github.com/yeoman/generator-angular

Уже все придумали

[justusebrain]

Если точнее, в генераторе есть grunt-ngmin, а grunt-ngmin использует ngmin, который есть и под gulp.

[galkinrost]

А что для сборки-то придумали? Это генератор с возможностью автоматичкого подключения файлов в html-страницу.

[alexeimoisseev]

Он генерит неведомо что. В сгенерированном grunt-файле не рабоатет часть тасков. Например, cdnify. Переводить всё это дело на gulp — боль отдельная.

[jonic]

я использую обыкновенный build.json с таким содержимым:

{
   "application":"App",
   "controllers":["Controller1","Controller2"],
   "modules":["Module1","Module2",..],
   ...
}

а потом собираю по нему php скриптом. Мартышкин труд вроде, а с другой стороны один раз написал и забыл…

[galkinrost]

Если бы я был Кипеловым, то посвятил бы вам песню «Беспечный ангел», настолько я восхищаюсь вашей аутентичностью.

[iKBAHT]

Мы применили аналогичный подход, только собираем не php скриптом, а задачей на grunt.

[GIum]

А в чем проблема сразу написать, скажем, bootrstrap.js:

angular.module('App.controllers',[]); 
angular.module('App.services',[]);
angular.module('App.myModule',[]);
angular.module('App',['App.controllers','App.services', 'App.myModule']);

И подключать его первым?

[galkinrost]

Потому что в этому случае, не нужно будет писать дополнительную библиотеку. Очевидно же.

[galkinrost]

Не вижу причин, почему бы не делать так, как вы предлагаете. Единственное, если у вас модули регулярно гуляют между проектами, то, наверное, будет удобнее хранить их объявление вместе с остальным кодом, но это, конечно, слабый аргумент. Поэтому добавил в пост ссылку на комментарий.

[iKBAHT]

А где гарантия того, что файл bootrstrap.js будет исполнен до какого либо контроллера?

[GIum]

И подключать его первым

[iKBAHT]

Не заметил. В статье автор рассматривает такую проблему

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

Ваш способ отлично решает эту проблему. Но это не единственная проблема при определении порядка загрузки/объединения скриптов. Допустим, есть файл router.js, в котором прописаны роутинги. Ему для работы нужны некие провайдеры. Нужно чтобы провайдеры были загружены раньше роутера.
Как я понимаю эту проблему не решает предложенный в статье NgConcat.

[galkinrost]

Если производить настройку провайдеров в файле объявления модуля, решает.

[iKBAHT]

Тогда хотелось бы более подробной документации для NgConcat на гитхабе

[StreetStrider]

Использую с browserify, полёт нормальный. На предмет возможных косяков проанализировал, не смог придумать.
Можно использовать обычный require модуля, можно использовать совместно с ангуларовским DI.

Есть презентация на эту тему:
benclinkinbeard.com/talks/2014/ng-conf/
benclinkinbeard.com/talks/2014/ng-conf/#/20 — на 20-ом слайде конкретный пример.

[galkinrost]

Вы browserify с shim используете?

[StreetStrider]

Нет.

[galkinrost]

А как вы сторонние библиотеки подключаете?

[StreetStrider]

Делаю require. Как правило, всё, что мне нужно, есть в npm, и оно работает через browserify без напильника (почти всегда). Однажды у меня была проблема с tls, но я его просто проигнорировал в browserify, и пакет прекрасно работал в браузере. Иногда приходится использовать не модуль, а его dist-версию, но редко.
О каких проблемах вы говорите?

[galkinrost]

Я обычно использую bower для фронтенда и здесь возникает проблема, что большинство библиотек AMD, а не CommonJs. И даже, если в файле сборки прописать порядок подключения этих файлов, browserify может собрать их произвольно, поэтому приходится отдельно указывать зависимости в shim.

[StreetStrider]

Да, это проблема. Тут нужно выбирать, если bower, то bower. Я как-то пробовал совмещать их, потом понял, что могу целиком перейти на CommonJS-модули. bower, как инфраструктура, мне симпатичен, но я уже не могу отказаться от плюсов npm-инфраструктуры.

[sonriente]

Почему-то никто не прокомментировал про структуру проекта.

app.js
controllers/
    FirstCtrl.js
    SecondCtrl.js
services/
    FirstSrv.js
    SecondSrv.js

Окей, хорошо, если вы делаете калькулятор. При условии, что вы пишете production code для большого проекта с парой тысячей контроллеров, вы просто утонете во всем этом. На хабре был разбор полетов на эту тему, главным смыслом которого была группировка не по типу, как в angular seed (контроллеры/директивы/сервисы), а по entities. Например:

app.js 
user
- UserModule.js
- UserCtrl.js
- AuthCtrl.js
- UserService.js
dashboard
- DashboardModule.js
- DashboardCtrl.js
- DashboardDirectiveThatShowsNeatCats.js ;)

Соответственно, проблемы как собрать собрать подобный проект без всяких примочек, у нас не возникало.

[galkinrost]

А дальше ведь могут быть ещи и самостоятельные модули со своей структурой.

Эх, чуть-чуть не дочитали

[sonriente]

Дочитали:) Я просто не понял, зачем все эти решения, если делать сразу правильную структуру проекта на вырост, Он и так неплохо собирается

[galkinrost]

А как вы собираете?

[iKBAHT]

А почему, скажем, ваш раздел user содержит только один контроллер? Если их будет больше, то вы получите все те проблемы, которые описаны в статье.