Комментарии

[h4]

1. grunt-icon наверно имеет смысл ставить глобально? Или, в крайнем случае, прописать его как dev-зависимость.
2. noscript-то зачем откапывать?

[smolnikov]

Мне кажется, нет ничего плохого в том, чтобы ставить его локально. А вот использовать npm install grunt-grunticon --save-dev, чтобы сохранить в зависимости, действительно, стоит.

[h4]

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

[smolnikov]

Хммм, вот сейчас задумался. С одной стороны, да, всякие csso, svgo, grunt, etc. стоят глобально. А вот таски для grunt всегда ставил локально, добавлял в dependencies и благополучно гитигнорил node_modules. А, ну да — при npm install он же поставит все из package.json локально, нет?

[h4]

Вот не знаю, как решается ситуация, когда у нас что-то стоит глобально и это же прописано в package.json.

[glebis]

Насколько я помню, локальная установка — это рекомендуемая процедура. Причина: компоненты могут в любой момент обновиться и не предоставить обратной совместимости. Лично с этим уже сталкивался. Самый большой пример — сам grunt (впрочем, его как раз я ставлю глобально, хотя можно было бы и его локально, для удобства используя smartcd). Чтобы не ломать потом голову в ситуации, где у тебя на одном проекте используется версия, условно, 0.9.3, на другом 0.9.4, друг с другом они уже не совместимы, а глобально стоит 0.9.4.

[sapegin]

Всё поставится локально. Возможно, npm достанет что-то из своего кэша, если версии совпадут. Более того, бинарники, установленные локально, имеют преимущество перед глобальными, если использовать их в скриптах внутри package.json.

Я за установку любых зависимостей локально и фиксацию версий в package.json. И Гранта тоже. grunt-cli сам вызовет всё, что нужно.

[sapegin]

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