Как "опубликовать" приватный пакет Typescript npm в git?

Question

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

У меня есть два проекта машинописи - LibraryA и WebserverB.Это отдельные проекты, и у каждого есть свой собственный репозиторий git.Они также являются частными проектами - я не хочу, чтобы они были доступны публично.

Очевидно, я хочу использовать LibraryA в WebserverB.Правильный способ сделать это, я думаю, будет через npm, поскольку он управляет всеми остальными библиотеками.К счастью, npm поддерживает URL-адреса git в зависимостях, поэтому я могу указать его непосредственно на репозиторий LibraryA.

Однако этот репозиторий не содержит скомпилированные файлы Javascript, только файлы TypeScript.Как я могу сделать эту работу?Или какой правильный подход в этой ситуации?

Answer 1

Если вы не хотите устанавливать свою зависимость от источников в git-репозитории, вот другие решения:

Решение № 1 - установить зависимость из локальной папки

Простое решение - установить LibraryA через git clone и собрать его. Затем в WebserverB/ вы можете сделать npm install ../path/to/local/LibraryA:

• npm install :

Установить пакет в каталог как символическую ссылку в текущем проекте. Его зависимости будут установлены до того, как он будет связан. Если находится внутри корня вашего проекта, его зависимости могут быть подняты на верхний уровень node_modules , как и для других типов зависимостей. ( Источник: документация NPM )

Решение № 2 - Установить личный реестр прокси npm

Вы можете установить личный реестр прокси-серверов npm на вашем сервере, например Verdaccio . Затем вы сможете опубликовать свой пакет со всеми скомпилированными файлами.

Решение № 3 - Оплатить NPM и опубликовать приватный пакет

Вы можете опубликовать настоящий пакет (также с скомпилированными файлами) в частном репозитории с платной учетной записи.

Решение № 4 - Публикация в виде релиза в вашем хранилище GitHub (не тестировано)

Документация NPM указывает на другую опцию:

• npm install

Получите URL-адрес tarball, а затем установите его. Чтобы различать эту и другие опции, аргумент должен начинаться с «http://” или« https://”

Затем опубликуйте пакет, состоящий из пакета, скомпилируйте и загрузите его в виде нового выпуска в свой личный репозиторий Github. После этого должна быть возможность доступа к тарболу через URL с использованием персонального токена доступа?

Answer 2

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

Подумав, я пришел к осознанию. Вопрос в том, кто и когда запускает tsc для компоновки Typescript из LibraryA в Javascript? По сути, есть только несколько вариантов:

1. Разработчик LibraryA запускает его и публикует скомпилированный результат (где-то);
2. Библиотека A публикуется в виде исходного кода, и компиляция происходит при установке пакета на WebserverB;
3. Библиотека A публикуется в виде исходного кода, и сборка WebserverB также компилирует библиотеку.

Давайте рассмотрим каждый из них подробно.

1. Опубликовать скомпилированный результат

Тогда возникает вопрос: где хранится опубликованный результат? Это должно быть где-то, где NPM может получить к нему доступ. Таким образом, есть только несколько вариантов:

• npm Registry (частный, если вы можете себе это позволить, общедоступный, если вы согласны с этим). Недостаток: ну, за это надо платить.
• Тарбол на каком-то сервере, где вы можете получить URL к нему. Недостаток: вы должны получить сервер для размещения этих. И позаботьтесь об указанном сервере.
• Новый репозиторий GIT. Тарболируется, потому что npm не может разархивироваться из репозитория git. Недостаток: теперь у вас есть два хранилища для одного проекта.
• Тот же самый репозиторий git, где живет LibraryA. По сути, вы не только фиксируете свои исходные файлы TypeScript, но и скомпилированный результат. Недостаток: фиксация артефактов компиляции просто неправильно . И вы публикуете свои источники вместе с скомпилированными результатами. Вам не нужны такие в WebserverB.
• Тот же самый репозиторий git, где живет LibraryA, но в отдельной, отключенной ветке. Недостаток: это сбивает с толку. Сколько репозиториев вы видели с двумя отключенными основными ветками?

Тем не менее, несмотря на недостатки, все они являются исправными вариантами.

2. Компилировать при установке

Основным недостатком здесь является то, что это сразу ставит зависимость от машинописи в WebserverB. И не просто зависимость от разработки, а полная зависимость времени выполнения. Это может быть хорошо, но это становится действительно странным. Как вы планируете развертывать WebserverB? Будет ли это запускать компиляцию? Я не думаю, что это путь. Но это возможно. Подробнее см. H.B. .

3. Компилировать вместе с WebserverB

Ну, если вы планируете использовать его только в проектах машинописного текста, это может быть нормально. Я не уверен насчет его установки. Вам нужно изменить файл tsconfig.json, чтобы включить в компиляцию node_modules/LibraryA. Это странно. И будет ли ваша IDE рада этому? В общем, это тоже не очень хорошая идея. Это похоже на борьбу / злоупотребление системой, и это редко заканчивается хорошо.

В конце, я думаю, я пойду с подходом "commit compiled JS". Потому что " просто неправильно " не является хорошим аргументом. А поскольку это частный проект, дополнительные опубликованные источники также не представляют большой проблемы. На самом деле, возможно, они даже помогут отладить.

Answer 3

Полагаю, вы можете добавить install скрипт в библиотеку package.json, которая его компилирует. Тогда вам просто нужно указать main и types на выходные файлы.