Я хочу разделить кодовую базу нескольких моих проектов на изолированные пакеты, подобные проектам. Они должны легко использоваться npm, но они не кажутся достаточно значимыми для публикации в глобальном реестре npm.
Итак, у меня вопрос: есть ли средний способ обработки их, таких как локально предоставляемые пакеты, и установки их с указанием пути и публикации в глобальном репозитории.
проблемы:
- загромождает реестр npm пакетами, которые кажутся недостаточно значимыми, чтобы занять имя
- необходимость документировать и создавать тесты для каждого пакета кажется слишком большой, и я не буду спать спокойно, публикуя пакеты, которые плохо документированы и протестированы
- Я беру имя, которое может быть более подходящим для использования более сложным пакетом и сопровождающими.
- Я все еще хочу, чтобы другие могли легко попробовать / использовать этот пакет, чтобы посмотреть, соответствует ли он их потребностям
Альтернативы:
A) создание частного репозитория npm (с CouchDB?)
- + в значительной степени идентичен хранилищу npm и прост в использовании
- + версия идентична, просто поиск в чистом semver
- - каждый пользователь должен настроить этот репозиторий, если он хочет использовать этот пакет или он нужен как дочерняя зависимость в своем (публичном npm) пакете (даже если это маловероятно)
- - Нужно потратить время на настройку и обслуживание
B) Использование моего имени пользователя npm namespace
- + решит почти все проблемы
- - пространства имен, похоже, предназначены для проектов и их подпакетов, что не относится к моим пакетам, поскольку их единственное соединение - создатель
- - кажется высокомерным ставить перед вашими пакетами ваше имя, как будто вы пометили его большим знаком ЭТО БЫЛО МЕНЯ
C) Использование GitHub со специальной отдельной веткой, которая содержит (помеченные) выпуски
- + вы можете использовать его как глобальный репозиторий npm, поскольку стратегия разрешения npm позволяет вместо версии * 1054 указывать URL-адрес репозитория с диапазоном полуавтомата.
- - особый случай, который обязательно сломается
- - GitHub не предназначен для предоставления пакетов npm, ни один разработчик не ожидает появления git-URL вместо версии, у инструментов и брандмауэров может быть проблема с этим
- - рабочий процесс на самом деле не предназначен ни для этого, ни для git, ни для npm
- D) используя локальный пакет и установите пакет по его пути
- + прост в настройке и использовании
- - без управления версиями
- - этапы сборки должны быть выполнены заранее вручную
- - не может публиковать пакеты в зависимости от этих пакетов
- - все зависимости должны быть установлены локально
- E) сделать эти пакеты более полезными, реализовать крайние случаи, написать документацию и протестировать весь пакет
- + разрешит все проблемы
- - ОЧЕНЬ много дополнительной работы, в первую очередь думая о крайних случаях и давая разработчику хороший API
- - иногда вы не можете получить имя для вашего пакета (оно сталкивается с другим), что приводит к странным
- - это ваша ответственность, вы должны поддерживать ее, нести ответственность (проверить это хорошо, крайние случаи)
- - загромождение хранилища npm
Так что это все альтернативы, которые приходили мне на ум, когда я пытался найти решение. Пожалуйста, оставьте комментарий / ответ, если у вас есть другая идея или, возможно, вы можете удалить / уменьшить важность этих противопоказаний.
Может быть, вы могли бы включить свой собственный опыт, чтобы я лучше рассмотрел всю проблему.
В настоящее время я бы просто попытался сделать пакет более полезным для подавляющего большинства, но это работает не во всех случаях.
Спасибо всем за потраченное время!