Каретка, тильда или фиксированный package.json для большого производственного приложения?

#javascript #reactjs #npm

#javascript #reactjs #npm

Вопрос:

У меня есть большое приложение react в производстве, и мне интересно, лучше ли использовать фиксированные версии для моих пакетов? Я слышал, что использование каретки (^) является хорошей практикой, но мне кажется, что это оставило бы приложение открытым для большего количества ошибок?

Я немного погуглил эту проблему, и, похоже, существует разделение между версиями ^ и fixed. Есть ли где-нибудь в документах (npm) окончательный ответ о том, какой подход использовать?

Комментарии:

1. Я не думаю, что когда-либо будет окончательный ответ, поскольку это зависит от того, какие пакеты вы используете. ^ следует устанавливать только непрерывные обновления, поэтому, если вы доверяете разработчикам пакета, проблем возникнуть не должно. Очевидно, что если ваше приложение используется по медицинским показаниям для транзакций на миллионы долларов, я мог бы проявить осторожность и заблокировать все версии пакетов.

2. Такой хороший вопрос (почему так мало просмотров?) Новички, не стесняйтесь делиться своим мнением

Ответ №1:

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

 npm shrinkwrap
  

Эта команда преобразуется package-lock.json в общедоступную npm-shrinkwrap.json или просто создает новую. Файл, созданный и обновленный этой командой, будет иметь приоритет над любыми другими существующими или будущими package-lock.json файлами. Подробное объяснение конструкции и назначения блокировок пакетов в npm см. npm-package-locks .

Таким образом, вы можете оставить зависимости, объявленные в package.json , такими, какие они есть (тильда / каретка), но точные версии, объявленные в npm-shrinkwrap.json , будут использоваться только при установке npm.

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

Вы всегда можете обновить свой, npm-shrinkwrap.json сначала выполнив npm update <package_name> указание пакета, который нуждается в обновлении, а затем выполнив повторно, npm shrinkwrap чтобы обновить существующий npm-shrinkwrap.json .

…и не забывайте npm ci