Автоматическое обновление зависимостей, объявленных локальными пакетами Meteor

Это довольно утомительно, когда вы пытаетесь обновить зависимости локальных пакетов Meteor.

В настоящее время они указаны в package.js как и я должен проверить последнюю версию каждой используемой зависимости и обновить вручную.

например.

api.use([
    'alanning:[email protected]',
    'aldeed:[email protected]',
    'aldeed:[email protected]',
    'iron:[email protected]',
    'useraccounts:[email protected]'
]);

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

Ответы

Ответ 1

Не существует реального значения при запуске версии зависимостей в package.js, как я упоминал в своем комментарии. Это может привести к эффекту счетчика и нарушить разрешение версии.

Ожидается упомянуть минимально совместимую версию (с тем же самым номером главной версии). Когда обновляется ваш локальный пакет, его файл .versions также обновляется, что может указывать на систему сборки, какая версия зависимостей является предпочтительной (с той, с которой был построен ваш пакет).

Ближайшая вещь, которую я могу дать в качестве ответа, - это цитата Дэвида Гринспена * взятая с форумов Meteor:

Мы сделали некоторые небольшие улучшения для обновления метеоров с течением времени, но у нас нет способа для пакета запросить одну из его зависимостей для повышения эффективности. обновление метеорита без аргументов будет получать обновления исправлений для косвенных зависимостей, но не младших версий. я недавно улучшили сообщения, которые печатают данные метеоритов, поэтому в в следующем выпуске, он должен сказать вам, не косвенная зависимость последняя версия после запуска (вместо того, чтобы печатать очень неправильно сообщение "Все пакеты находятся в их последних совместимых версиях" ).

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

Итак, когда автор пакета зависеть от выпусков нового:

  • версия патча: вам не нужно ничего делать. Новая версия должна использоваться автоматически.
  • младшая версия: убедитесь, что все работает и выпущена новая версия исправления, чтобы подтвердить новую версию.
  • главная версия: ожидается, что ситуация сломается. Внесите необходимые изменения и отпустите в соответствии с правилами semver.

Я бы не стал рассчитывать на то, что происходит сейчас, поскольку система упаковки претерпевает довольно значительную доработку, чтобы быть более совместимой с NPM (включая возможность напрямую требовать пакеты NPM от Meteor приложения и пакеты), которые, как ожидается, будут включены в v1.3.

* (на самом деле, Саша Грайф опубликовала цитату).

Ответ 2

Это из документов:

В общем, вы должны указать версию пакета (например, '[email protected]' для использования версии 1.0.0 или более высокой совместимой версии(например: 1.0.1, 1.5.0 и т.д.) пакета учетных записей). Если вы являетесь источником ядровые пакеты из релиза Meteor с версиями. Вы можете уйти выдает имена версий для основных пакетов. Вы также можете указать ограничения, таких как my: [email protected]=1.0.0 (этот пакет требует my: forms на 1.0.0 точно), или my: [email protected] || = 2.0.1 (my: формы в 1.x.y или точно 2.0.1).

Итак, ответ: он не обновит ваш package.js script, но он загрузит самые последние совместимые версии, в зависимости от ваших настроек.