Javascript-форум (https://javascript.ru/forum/)
-   Node.JS (https://javascript.ru/forum/node-js-io-js/)
-   -   NPM: совместное использование зависимостей (https://javascript.ru/forum/node-js-io-js/60730-npm-sovmestnoe-ispolzovanie-zavisimostejj.html)

vasa_c 16.01.2016 21:06

NPM: совместное использование зависимостей
 
Как известно, новомодные менеджеры зависимостей (в том числе NPM) славятся тем, что, в отличии от старинных, ставят все зависимости не глобально, а локально в каталог проекта. Это спасает нас от депенденсис-хэла и вообще теоретически очень здорово выглядит. До того момента, когда в очередной раз npm install не выкачивает те же 300 мегабай барахла, которые уже установлены в соседнем каталоге.

В NPM3 хоть как-то это почистили в рамках одного модуля. Мне непонятно, что мешает сделать тот же финт глобально - ставить всё глобально, но с разделением на версии. Но не будем о вечном.

Что вы с этим делаете? Просто миритесь или есть какие-то хаки и практики?

У меня, например, есть несколько модулей, у которых в devDependencies примерно одно и тоже, так я просто создал один каталог node_modules и в каждый модуль кинул на него символическую ссылку. Так туда всё и валится.

Какие есть более сносные варианты?

Gurylyov 17.01.2016 18:59

А в чём проблема? Не знаю на счёт третьей, но пятая нода создаёт сама символические ссылки на модули внутри одного проекта и ничего не захламляет, вроде как.
Да, нужно писать npm i в каждом проекте, но эта папка не отправляется в гит, поэтому проблемы никакой не составляет.
Я так понял, напрягают именно одни и те же модули в каждом проекте? Если так, то по идее можно правильно организовать файловую структуру во избежание этого. К примеру, есть папка projects, в ней все проекты. Нода в каждом из проектов ищет модули вначале в node_modules, а потом ищет в node_modules на уровень выше. И так пока не дойдёт до корня файловой системы. В качестве решения можно все модули положить в projects/node_modules. Тогда нода будет брать их оттуда. Тогда ставить модули нужно будет командой npm i ../ то есть с указанием флага folder - на уровень выше.

vasa_c 17.01.2016 19:35

Цитата:

Не знаю на счёт третьей, но пятая нода создаёт сама символические ссылки на модули внутри одного проекта и ничего не захламляет, вроде как.
Я имею ввиду NPM. 3-я NPM последняя. Сама нода, насколько я понимаю, никаких модулей не создаёт и никуда не кладёт. Это нпм всё.

Где можно почитать про символические ссылки?

Цитата:

Да, нужно писать npm i в каждом проекте, но эта папка не отправляется в гит, поэтому проблемы никакой не составляет.
Как минимум забивает диск и канал.

Цитата:

Нода в каждом из проектов ищет модули вначале в node_modules, а потом ищет в node_modules на уровень выше. И так пока не дойдёт до корня файловой системы.
Да, и эта фишка теперь используется в NPM3. И в моём хаке описанном выше тоже.
Но сам NPM при установке не будет искать выше, не установлено ли там.

Цитата:

ставить модули нужно будет командой npm i ../
Это могло быть вариантом решения, но, к сожалению, у меня не работает: "EISDIR: illegal operation on a directory, read".

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

Gurylyov 18.01.2016 21:55

Прошу прощения. Всё время путаю версии npm и ноды. Настолько привык, что они в паре, что не замечаю отдельно npm :)

Про символические ссылки в википедии.

На диске место почти не занимает. У меня папка projects весит 5мб. И там почти 30 проектов. За вычетом проектов не на nodejs, разумеется.
Канал - не понимаю, о каком канале речь.

Быть может, эта статья поможет запустить проекты с общей папкой модулей на уровне проектов.

И да, от проблемы с версиями модулей уйти можно будет только доставляя нужные версии всё-таки в локальную папку проекта. Но зато можно переставлять версию ноды в проекте при помощи утилитки со скромным названием "n"

nerv_ 19.01.2016 00:11

vasa_c, плюс тебе за тему

Цитата:

Сообщение от vasa_c
В NPM3 хоть как-то это почистили в рамках одного модуля. Мне непонятно, что мешает сделать тот же финт глобально - ставить всё глобально, но с разделением на версии.

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

у меня на машине кеш по умолчанию лежит в
Код:

~/.npm
Если рассмотреть один из пакетов в кеше, например
Код:

~/.npm/isarray/
то внутри данной директории обнаружим (в моем случае)
Код:

~/.npm/isarray/0.0.1/
~/.npm/isarray/1.0.0/

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

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

upd2: вероятно, надо читать
https://docs.npmjs.com/files/folders
https://docs.npmjs.com/files/npmrc
:)

vasa_c 20.01.2016 17:17

В общем, под убунтой у меня следующая ситуация.
В ~/.npm действительно лежит куча кэша, по версиям, в том числе, видимо, старым, которые уже нигде не используются.

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

Если мониторить сеть, каждый раз npm качает мегабайты трафа. То есть даже кэш этот не задействован.

Пока я в печали.

nerv_ 20.01.2016 21:59

Я задал вопрос об использовании символических ссылок разработчикам npm. Был получен ответ :)
https://github.com/npm/npm/issues/11210

Цитата:

Сообщение от vasa_c
Если мониторить сеть, каждый раз npm качает мегабайты трафа. То есть даже кэш этот не задействован.

должен брать из кеша... по идее


Часовой пояс GMT +3, время: 05:15.