Чем управлять модулями?

Question

[nickerlan]

Вот написал я пару симпатичных классов на nodejs. В моем случае - обертки вокруг API нескольких сервисов
Хочу теперь использовать их как "арсенал" в разных проектах.
Проекты, в основном, веду один, на одной и той же машине. Иногда подключаются по несколько человек.

Вот вижу у меня написано
const myscript = require('./myscript')

Как теперь это превратить в "универсальную кодовую базу"? Хотя бы для личного использования?

Пробовал репозиторий на гитхабе. Потом npm publish.

На новом проекте npm install myscript

А теперь как мне оперативно изменения внести в этот модуль? Прямо в node_modules править (выискивая свой модуль каждый раз в этой огномной простыне), потом прямо оттуда-же пушить изменения, а затем паблишить их?

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

Как это по-человечески делается?

Comments

[Сергей delphinpro]

Если ваш модуль все еще требует частых правок, значит он не дорос до паблик версии. В простейшем случае можно тупо положить пакет в отдельную папку на компе и сделать симлинки на нее в проектах.
Когда разработка устаканится, можно будет опубликовать в npm под версией 1.0 и в дальнейшем правки уже вносить как положено: push в репу -> тегирование по semver -> паблиш в npm -> update в проектах.

Answer 1

[Антон Швец]

Можно забирать модуль не из npm, а напрямую из git репозитория.
А можно и в npm паблишить обновленные версии.
Если вам нужно редактировать модуль прям на месте, луше тогда подключить этот код как git submodule, а не пакет npm. Редактировать прям в node_modules не стоит.

Comments

[nickerlan]

А как потом синхронизовать его между проектами?

[Артем]

nickerlan, git submodule add -b master https://github.com/{user}/{repo}
Далее вносите изменения в {user}/{repo}, коммитите их, пушите в master
После чего достаточно git submodue update --init сделать в вашем проекте и все изменения из ветки master подтянуться

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

Использовать сабмодуль можно также, как обычный пакет npm:
npm i --save-dev ./submodule-directory
Точку для локальных каталогов указывать обязательно!

Answer 2

[Vitaliy]

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

А теперь как мне оперативно изменения внести в этот модуль? Прямо в node_modules править (выискивая свой модуль каждый раз в этой огномной простыне), потом прямо оттуда-же пушить изменения, а затем паблишить их?

Можно установить локальный пакет (npm i ../module-folder): в самом проекте (в package.json будет путь к пакету, вместо версии на npmjs) или выделить дев проект-обертку, чтобы в основном проекте каждый раз не свапать этот пакет между локальным и удаленным. Таким обрабом можно с тем же HMR нормально редактировать пакет, без правок в node_modules и публикаций на каждый чих

Comments

[nickerlan]

А этот же локальный пакет как подключить в другой проект?
Как его синхронизовать между этими проектами?

[Vitaliy]

nickerlan, npm i <путь к пакету>

[Vitaliy]

nickerlan, при остановке он не копируется, при импорте будут браться файлы напрямую в указанной директории, как будто она лежит в node_modules

[nickerlan]

Вот как бы написать что то в духе
npm i /home/common/module

А потом запушить так, чтобы корректно задеплоилось...

[Антон Швец]

nickerlan, никак. не надо так делать

Answer 3

[Руслан Лопатин]

Есть ещё npm link (yarn link). Полезно, чтобы отладить изменения локально. Но как только отлажены - публиковать. Не вижу проблемы с этим.

Если не хочется публиковать вручную - научите CI делать это автоматически. Например, при внесении изменений в ветку master формировать и публиковать dev-версию. Посмотрите, сколько dev-версий у того же typescript.

Если же изменения вносятся постоянно сразу в несколько модулей, то в таких модулях нет смысла. Подумайте, чтобы поместить их в один репозиторий. Кстати, yarn понимает ссылки прямо в package.json:

{
  "devDependencies": {
    "my-local-dep": "link:../my-local-dep"
  }
}

Comments

[Руслан Лопатин]

Дополню. Ещё в Yarn есть рабочие области. Может, это то, что вы ищете. Можно использовать в моно-репозитории, либо в сочетании с git submodules