Автоматическая сборка javascript/coffeescript проекта

[MuLLtiQ]

Для JavaScript-проектов есть grunt, в котором всё «из коробки», кроме компиляции CoffeeScript'а. Впрочем ничто не мешает добавить нужный таск самому.

[SHTrassEr]

Действительно, классный проект. Сейчас просмотрел его документацию, остался один вопрос: можно ли каким-нибудь образом «из коробки» влиять на порядок объединения файлов? Вот, как в моем примере: если в третьем файле объявляются какие-нибудь функции, которые требуются во втором, то при сборке неплохо было бы, что бы третий файл стоял «выше» второго. При большом количестве файлов, в конфиге вручную прописывать порядок, понятное дело, не вариант.

А так, размер конфигурационных файлов grunt'а не многим меньше чем вариант с Rake::Pipeline, насколько я понимаю.

[vitalets]

может разбить concat на несколько команд? как-то так:

concat: {
    module1: {
      src: ['src/intro.js', 'src/project.js'],
      dest: 'tmp/module1.js'
    },
    module2: {
      src: ['src/intro2.js', 'src/project2.js'],
      dest: 'tmp/module2.js'
    },
    dist: {
      src: ['<config:concat.module1.dest>', '<config:concat.module2.dest>'],
      dest: 'dist/built.js'
    }

 }

[MuLLtiQ]

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

[SHTrassEr]

Можно, но тут порядок сборки жестко прописывается в конфиге. И если для двух файлов понадобилось столько кода, то что же будет в более сложных случаях?

Вариант с «require» мне все-таки нравится гораздо больше. Проще прописать в файле project2.js:

require("project.js");

[MuLLtiQ]

Разработчики jQuery по этому поводу не парятся :)

Хотя если файлов в проекте действительно много, то задавать зависимость между ними через require может быть действительно лучше. В этом случае можно сделать самому обработку директив require, как реализовано в rake-pipeline-web-filters.

[SHTrassEr]

Разработчики jQuery круты:)
Но у меня какой-то необъяснимый страх перед файлами размером под 1000 строк кода. Поэтому стараюсь все раскидывать по маленьким файлам, а в в итоге их как-то многовато получается.

[vitalets]

Да, грунт интересный проект, как раз хочу сделать перевод одной вводной статьи по нему, а то на хабре почти ничего нет.
Кстати, сборка jQuery UI на нем реализована.

[MuLLtiQ]

И не только jQuery UI, но и самого jQuery тоже.

[vitalets]

А вот bootstrap пока нет :)
Хотя в версии 2.1 обещают

[JiLiZART]

По моему, сейчас только ленивый js на нем не собирает, из больших библиотек.

[MuLLtiQ]

Теги к статье некорректно проставились — «javascript coffescript pipeline» — как один тег пошло

[token]

Я для себя решил проблему самописным решением основанным на ANT (для сборки), RequireJS (для управления зависимостями) и Mozilla Rhino (чтобы в build — time можно было бы распарсить код проекта, вытащить зависимости и объеденять / делать что угодно) + Google Closure Compiler и прочие вещи для оптимизации / минификации / сжатия всего этого в deployment package. Чего действительно не хватает JavaScript'у так это чего то типа Maven'а, но без заточки на Java, так чтобы можно было без костылей и стандартных «directory layouts» работать с JavaScript — зависимостями.

[Sinopiklab]

Я видимо чего-то не понял, но зачем вам RequireJS если вы собираете весь JS в один файл?

[token]

Тема такая, есть проект который использует файлы A, B, C и D. Причем C и D используются другими проектами (к примеру C это jQuery а D это некий файл с утилитами). Есть главный файл проекта app.js который посредством соотв. Вызовов RequireJS, как то использует перечисденнные файлы. Мое решение позволяет собрать app.js, A и B в один файл, а C и D в другой, на этапе сборки проекта перед деплоем.

[token]

А по — теме, по — моему главный недостаток вашей попытки создать систему сборки зависимостей, это использование Ruby в качестве сборщика. Возникло пара вопросов:
1. почему именно Ruby, мы ведь собираем JavaScript — проект?
2. Почему не воспользоваться для сборки JavaScript — проекта — JavaScript'ом, и тем же Mozilla Rhino в роли сборщика?

[SHTrassEr]

1. Чем вам так руби не угодил?:) Или есть какое-то правило, что Javascript можно только javascript'ом собирать?
2. Тот же Rhino в качестве зависимости Джаву тянет. Следуя вашей логике: зачем нам Mozilla Rhino (Java), ведь мы же собираем javascript проект.

Я не создавал систему сборки зависимостей, я лишь описал существующую. И по мне так описанная мной система как минимум не хуже того же grunt'а. Более того, по доступным из коробки возможностям она даже превосходит ее.

А так, воспользоваться Rhino конечно можно. Другой вопрос, будет ли это удобнее.

[token]

1. Никакой неприязни к руби у меня нет. Я просто его не знаю и знать не хочу (мне и без него хорошо). Думаю я не единственный такой. Руби делает ваше решение зависимым от разраба который знает руби…

2. Я могу ошибаться но Джава в отличие от руби есть на 90% машин.

[SHTrassEr]

Тут каждый выбирает что ему ближе. Я вот привык rake — файлами подобные вещи собирать. И скрипты тут примитивные на самом деле:)

И какое решение не выбирай — все равно всему учиться надо. Сборка при помощи ant зависит от разработчика, который знает ant, при помощи Rhino — нужно знать Rhino, при помощи grunt — ну вы поняли:)