Ответ 1
Редактировать: обнаружение установки пакета из git repo
Я не правильно понял вопрос. Ниже приведены вещи, которые я написал, но немного не по теме. Пока, если вы хотите запускать build.js только при установке из репозитория:
Файлы в репо:
.gitignore
.npmignore
ThisIsNpmPackage
build.js
package.json
.gitginore:
ThisIsNpmPackage
.npmignore:
!ThisIsNpmPackage
В package.json:
"scripts": {
"install": "( [ ! -f ./ThisIsNpmPackage ] && [ ! -f ./AlreadyInstalled ] && echo \"\" > ./AlreadyInstalled && npm install . && node ./build.js ) || echo \"SKIP: NON GIT SOURCE\""
}
Идея состоит в том, чтобы сделать файл ThisIsNpmPackage доступным в репозитории, но не в пакете npm.
Установите hook, это всего лишь кусок скрипта, чтобы проверить, существует ли ThisIsNpmPackage. Если да, тогда мы выполняем npm install . (это гарантирует, что у нас есть devDependencies. Файл AlreadyInstalled генерируется, чтобы предотвратить бесконечный цикл
(npm install будет рекурсивно вызывать установочный хук)
При публикации я делаю git push и npm publish
Обратите внимание, что публикация npm может быть автоматизирована с помощью инструментов CI - githooks
Этот небольшой взлом файла ThisIsNpmPackage делает доступным обнаружение источника.
Результаты вызова npm install dumb-package:
"SKIP: NON-GIT SOURCE"
И выполнение npm install https://github.com/styczynski/dumb-package
Файлы будут построены
Проблемы
Вот основные проблемы, с которыми мы сталкиваемся:
Нужно делать
npm publish ...каждый раз
Иногда бывает слишком сложно исправить небольшую ошибку, затем нажать на репо и забыть опубликовать на npm. Когда я работал с проектом на основе микросервисов, в котором около 5 отдельных подпроектов были разделены на модули, проблема, в которой я обнаружил проблему, устранила ее и забыла публиковать в каждом месте, где должен был, действительно раздражала.Не хочу вставлять
libв репозиторий, потому что он взят из источниковПеребазировка и слияние еще более раздражают.
Не связывайтесь с
.gitgnoreЧерт, я знаю эту проблему, когда у вас есть проблемные файлы, которые вы должны включить в репозиторий, но никогда не изменяете их или иногда удаляете? Это просто тошнит.
Изменение: крючки npm
Как упомянул @Roy Tinker, существует возможность, что пакет может выполнить команду после установки.
Это может быть достигнуто через npm-хуки.
"install": "npm run build"
И мы выполняем:
npm install https://github.com/<user>/<package>
Изменить:
ОП вопрос из комментариев:
Но это запустит установку для всех, кто скачивает модуль с npm, верно? Это чрезвычайно проблематично, учитывая, что dev-зависимости не будут установлены для тех, кто скачивает модуль с npm. Библиотеки, используемые для сборки приложения - babel и т.д. Не будут установлены.
Примечание. Но , если вам нужна конкретная версия пакета (production/dev) с зависимостями dev или без, вы можете установить ее с помощью:
npm install --only=dev
Аргумент --only = {prod [uction] | dev [elopment]} вызовет установку только devDependencies или только non-devDependencies независимо от NODE_ENV.
На мой взгляд, лучшим решением является использование:
npm install <git remote url>
А затем внутри package.json укажите:
"scripts": {
"prepare": "npm run build"
}
Если устанавливаемый пакет содержит сценарий подготовки, будут установлены его зависимости и devDependencies, а сценарий подготовки будет запущен до упаковки и установки пакета.
Пример:
npm install git+https://[email protected]/npm/npm.git
Прочитайте документы npm там: npm install
Изменение: прокси-модуль (продвинутая техника)
Это плохая практика, но полезно знать.
Иногда (как в случае с платформой Electron вам необходимо установить другие внешние пакеты или ресурсы/модули в зависимости от различных условий).
В этих случаях используется идея прокси:
- Вы делаете модуль, который ведет себя как установщик и устанавливает все, что вам нужно
В вашем случае подготовить сценарий будет достаточно, но я оставляю эту опцию, потому что это может быть иногда полезно.
Идея состоит в том, что вы пишете модуль и пишете для него установочный kook:
"scripts": {
"install": "<do the install>"
}
В этом сценарии вы можете разместить там:
npm install . && npm run build
Которые в любом случае устанавливают все devDependencies (как и в случае с подготовленным кейсом), но это немного взлом.
Если вы хотите сделать настоящий взлом там:
"scripts": {
"install": "curl -L -J -O \"<some_url>\""
}
который вручную загружает файлы с помощью команды -nix curl
Этого следует избегать, но это вариант, если модуль имеет огромные двоичные файлы для каждой платформы, и вы не хотите устанавливать их все.
Как и в случае с Electron, где вы скомпилировали двоичные файлы (каждый для отдельной платформы)
Итак, вы хотите, чтобы люди сделали install package не install package-linux или package-window и т.д.
Таким образом, вы предоставляете собственный скрипт install в package.json
{
...
"scripts": {
"install": "node ./install_platform_dep.js"
}
}
Затем при установке module будет выполнен скрипт install_platform_dep.js. Внутри install_platform_dep.js вы размещаете:
// For Windows...
if(process.platform === 'win32') {
// Trigger Windows module installation
exec('npm install fancy-module-windows', (err, stdout, stderr) => {
// Some error handling...
}
} else if ... // Process other OS'es
И этот чисто ручным способом устанавливает все.
Примечание: Еще раз этот подход можно использовать с зависящими от платформы модулями, и если вы его используете, он, вероятно, создает проблемы с вашим кодом.
Построить на CI
Что мне приходит в голову, так это решение, которое я действительно использовал в течение долгого времени (автоматическое создание с помощью служб CI).
Основная цель большинства служб CI - это тестирование/сборка/публикация кода при отправке в ветку или выполнении других действий с репо.
Идея состоит в том, что вы предоставляете файл настроек (например, travis.yml или .gitlab-ci.yml), а все остальное заботятся инструменты.
Если вы действительно не хотите включать библиотеку в проект, просто доверьтесь CI делать все:
- Githook запустит сборку на коммите (на ветке или любой другой - это всего лишь вопрос настроек)
- CI создаст ваши файлы, затем передаст их на фазу тестирования и опубликует
Сейчас я работаю над Gitlab над своим собственным проектом и создаю (как часть хобби) некоторую веб-страницу. Конфигурация Gitlab, которая создает проект, выглядит следующим образом:
image: tetraweb/php
cache:
untracked: true
paths:
- public_html/
- node_modules/
before_script:
- apt-get update
stages:
- build
- test
- deploy
build_product:
stage: build
script:
- npm run test
build_product:
stage: build
script:
- npm run build
deploy_product:
stage: deploy
script:
- npm run deploy
При слиянии с основной веткой происходят следующие события:
- КИ работает на этапе
build - Если сборка прошла успешно, запускается этап
test - Если фаза
testв порядке, то, наконец, активируется стадияdeploy
Сценарий - это список команд Unix, которые нужно выполнить.
Вы можете указать любой образ Docker в конфигурации, так что фактически используйте любую версию Unix, которую вы хотите, с некоторыми (или нет) предустановленными инструментами.
Существует пакет deploy-to-git, который развертывает артефакты в нужной ветке репо.
Или здесь (для Travis CI) фрагмент конфигурации, который публикует артефакты в репозитории:
(Я использовал это сам)
Тогда, конечно, вы можете позволить CI работать:
npm publish .
Поскольку CI выполняет команды Unix, он может (по крайней мере, несколько поставщиков CI):
- Опубликовать теги (возможно, освободить тег?)
- Сценарий запуска для обновления версии проекта во всех файлах README и везде
- Отправьте вам уведомление, если все этапы выполнены успешно
Итак, что я делаю:
Я фиксирую, нажимаю и позволяю инструментам делать все, что я хочу.
Тем временем я делаю другие изменения и через одну-десять минут получаю отчет об обновлениях по почте.
Там много провайдеров CI:
Здесь я прилагаю другой пример моего другого проекта (.travis.yml):
language: generic
install:
- npm install
script:
- chmod u+x ./utest.sh
- chmod u+x ./self_test/autodetection_cli/someprogram.sh
- cd self_test && bash ../utest.sh --ttools stime --tno-spinner
Если вы настроили CI для отправки и публикации своего пакета, вы всегда можете использовать последнюю передовую версию своего кода, не беспокоясь о да, мне нужно запустить и эту команду сейчас... проблема.
Я рекомендую вам выбрать одного из провайдеров CI.
Лучшие из них предлагают вам сотни способностей!
Когда вы привыкнете автоматически выполнять этапы публикации, тестирования и сборки, вы увидите, как это помогает наслаждаться жизнью!
Затем, чтобы запустить другой проект с автоматическими скриптами, просто скопируйте конфиги!
Резюме
На мой взгляд, сценарий подготовки npm - вариант.
Вы также можете попробовать другие.
Каждый из описанных методов имеет свои недостатки и может использоваться в зависимости от того, чего вы хотите достичь.
Я просто хочу предоставить некоторые альтернативы, надеюсь, что некоторые из них будут соответствовать вашей проблеме!