Упрощение поддержки зависимостей

[monolithed]

Вместо:

git clone git@github.com:mailru/fest.git
cd fest
sudo npm install -g grunt-cli
npm install
grunt

Вариант:

Писать:

git clone --recursive git@github.com:mailru/fest.git

Для этого нужно лишь добавить:

.gitmodules

[submodule "node_modules/grunt-cli"]
  path = node_modules/grunt-cli
    url = git://github.com/gruntjs/grunt-cli.git

Обновляем потом так:

git submodule foreach git pull origin master

Или так ( git 1.7.3+):

git pull --recurse-submodules
git submodule update --recursive

Опционально:

package.json

"scripts": {
    "preinstall": "git submodule update --init --recursive && ./configure"
},
"dependencies" : { 
   "grunt-cli":"*" 
}
// ....

.configure

cd npm_modules;

for i in $(ls -d -- */)
    do
        npm install -g $i | sed s/\\/$//;
    done;

cd ..

[eprev]

Есть примеры проектов, которые grunt-cli атачат к себе сабмодулем? Он должен быть установлен в системе глобально. Одного сабмодуля недостаточно, необходимо выполнять cd grunt-cli && npm install.

В общем случае npm install -g grunt-cli вообще не выполняется (уже установлен у разработчика), необходимо одиножды выполнить npm install и все. Куда проще то?

[monolithed]

> Есть примеры проектов, которые grunt-cli атачат к себе сабмодулем? 

Полно, поиск первым выдал: https://github.com/lanceharper/ember-table/tree/512b174b4c3e7688b71982e290b638757ad8c139/node_modules/grunt-cli (хотя явно .gitmodules они не используют, видимо не знают что так можно)

Во первых, я предлгаю сделать утановку grunt опциональным (если в нашем случае такое возможно), т.к. не всем он нужен глобально. И подержать как опциональный параметр в cli

Во вторых, если grunt не может работать из хомяка, то почему же не сделать так:

"preinstall": "git submodule update --init --recursive && sudo npm install -g grunt sax"

Я это к тому что установка должна быть гибкой и простой, а не ультимативной

[eprev]

Увы, но пример не показателен: grunt не сабмодуль, и вообще иерархия node_modules в репе хранится, это bad practice.

Саш, grunt итак необязателен – его необходимо ставить, если ты хочешь контрибьютить в fest. Ты же не будешь спорить с тем, что тесты должны быть написаны на Jasmine?

PS. Установка fest: npn install fest (так написано в readme).

[RubaXa]

Я буду, почему на Jasmine? (просто интересуюсь)

2013/3/18 Anton Eprev notifications@github.com

Увы, но пример не показателен: grunt не сабмодуль, и вообще иерархия node_modules в репе хранится, это bad practice.

Саш, grunt итак необязателен - его необходимо ставить, если ты хочешь контрибьютить в fest. Ты же не будешь спорить с тем, что тесты должны быть написаны на Jasmine?

Reply to this email directly or view it on GitHubhttps://github.com/mailru/fest/issues/61#issuecomment-15054927 .

И больше не пишите мне, занят я!

[eprev]

Jasmine прост и выразителен. А mocha тянет за собой библиотеку ассершенов. Vows уже был к тому времени.

[monolithed]

Jasmine убог и избыточен

[eprev]

Это не аргумент :-)

[monolithed]

Jasmine это наследие JSUnit, сравни с QUnit, что может быть проще (правда мне не он тоже не всем нравится, поэтому я написал свой :yum:, но тем не менее )?

[RubaXa]

óÐÁÓÉÂÏ, ÐÒÏÄÏÌÖÁÊÔÅ ÂÏÄÁÔØÓÑ.

On Mon, Mar 18, 2013 at 5:46 PM, Anton Eprev notifications@github.comwrote:

üÔÏ ÎÅ ÁÒÇÕÍÅÎÔ :-)

Reply to this email directly or view it on GitHubhttps://github.com/mailru/fest/issues/61#issuecomment-15055316 .

é ÂÏÌØÛÅ ÎÅ ÐÉÛÉÔÅ ÍÎÅ, ÚÁÎÑÔ Ñ!

[monolithed]

A почему npm_modules это bad practicies?

[eprev]

А зачем хранить unmaintained код в репозитории?

[monolithed]

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

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

[eprev]

Сумин, вообще не хотел стороннюю библиотеку для тестирования. А Jasmine прост, и не составит труда сделать свою реализацию, сохранив его API.

[eprev]

Так как npm ставит локально, то в глобальный npm list ничего не попадет от проектов.

[monolithed]

Нафига такое API? toBeNull, toBeTruthy, toBeFalsy, toEqual, toBeDefined и пр. Нафига там десятки методов?

[monolithed]

У меня был случай когда я использовал сторонную либу, исходники которой потом пропали вместе с ее автором :jack_o_lantern:

[eprev]

Посмотри http://chaijs.com ;-)

[eprev]

В интернете ничего не пропадает!

[monolithed]

expect(undefined).to.not.be.ok; жут какая ;)

[eprev]

Я знал, что тебе понравится :-)

[monolithed]

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

var unit = new Suitest;

unit
    .test('test 1', function(unit) {
       unit.exec(true, 1)
            .done();
   });

    .test('test 2', function() {
       this.exec(true, 2)
            .done();
   });

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

[monolithed]

Ну что тогда закрывать таск?

[eprev]

Окей.