npm публикуют только если изменено в угловых монорепо - PullRequest
0 голосов
/ 12 февраля 2019

У меня есть угловой монорепо с «приложением» и библиотекой, которая публикуется в виде собственного пакета npm.Это делается автоматически в среде CI.До сих пор библиотека и приложение были отдельными и имели отдельные задания по сборке.Теперь, когда они собраны вместе, я сталкиваюсь с проблемой, что библиотека публикуется при каждой сборке (каждое изменение в master), даже если это изменение было (и, скорее всего, так) в приложении.

Есть ли простой способ опубликовать пакет npm, если его содержимое изменилось с момента последней публикации?

Если я запустил npm info <the-package>, то есть .shasum и .integrity контрольная сумма, и я надеялся, что смогу сравнить их с теми же значениями при запуске npm publish <directory> --dry-run.К сожалению, эти команды приводят к разным контрольным суммам, хотя содержимое пакетов в точности совпадает.**

**, чтобы убедиться в этом, я сравнил содержимое опубликованного архива с недавно созданной дистрибутивной версией библиотеки.* diff -r по обоим каталогам не обнаруживает различий.

Обновление

Из-за отсутствия лучшей идеи я взломал ручное решение в bash (с момента публикациимоя библиотека в любом случае происходит в bash-скрипте).Поскольку в моем случае каждый релиз помечен тегом, я получаю последний помеченный коммит и проверяю, изменилось ли что-либо в lib с тех пор.Это ни в коем случае не хорошее решение, и вы, вероятно, не должны его использовать, но в случае, если оно кому-то поможет:

PATH_TO_LIB='./projects/the-lib'

# find the last tagged commit and assume it was the last release
TAG=$(git describe --abbrev=0)
COMMIT=$(git rev-list -n 1 $TAG)

# check if anything changed in the lib since the last release
CHANGED=$(git diff --name-only HEAD $COMMIT $PATH_TO_LIB)
if [ ! -n "$CHANGED" ]; then
    exit 0
fi

Есть несколько очевидных улучшений, которые мне сейчас не хочется решать:

  • скрипт должен игнорировать коммиты, которые были помечены по другой причине, отличной от релиза
  • последний релиз должен как-то сохраняться, иначе нет никакой гарантии, что вы действительно проверяете последний релизсо времени последней публикации lib
  • может иметь смысл игнорировать определенные типы изменений, которые не требуют новой версии
...