Давайте поговорим о ситуации, над релизом вы работали месяц. Вы используете npm для управления своими зависимостями. После этого вы замораживаете код этого выпуска для развертывания в производственной среде через 2 недели. В день выпуска развертывание завершается ошибкой, но оно по-прежнему работает в вашей системе. Вы чешете затылок и после многих усилий и исследований обнаруживаете, что используемая вами сторонняя зависимость получила обновленную версию, в которой была ошибка, из-за которой ваше приложение ломается.
Найти такие типы проблем не только сложно, но и неприятно. Как и в реальной среде, задержка развертывания по этим причинам может дорого обойтись вашей компании.
Вы можете подумать об исправлении версии этой библиотеки в package.json до более старого номера версии без использования каких-либо операторов, таких как ~, ^ и т. Д. Это будет работать, но в будущем вы перестанете получать какие-либо обновления этой сторонней библиотеки, которые могут включать исправления , улучшения и исправления ошибок.
Но подождите, мы только что сказали, что он все еще отлично работает на вашей машине. Почему даже после переустановки зависимостей на вашем компьютере вы не получили эту ошибку. А вот и интересная часть, которую npm (версия ≥ 5) предоставляет нам из коробки для исправления версий после их установки в нашей установке.
Если вы внимательно присмотритесь, когда создаете новый проект и запускаете на нем npm install. Создается файл, то есть package-lock.json. Этот файл также обновляется всякий раз, когда вы добавляете какую-либо зависимость или удаляете любую зависимость или обновляете любую версию зависимости вручную.
Этот файл в основном содержит номер версии зависимостей, которая устанавливается при запуске npm install. Это в основном означает, что если этот файл находится в папке вашего проекта, в следующий раз, когда вы запустите npm install, он установит ту же версию, которая была установлена ранее, без учета каких-либо обновленных версий.
В ветке, которая помечена как стабильная для производственного выпуска, мы должны зафиксировать этот файл, чтобы он мог стать частью помеченной ветки после выпуска.
Таким образом, в будущем, если какое-либо тело захочет использовать старую помеченную ветку, он получит точно такую же версию зависимостей, которая была упомянута в package-lock.json, без какого-либо влияния на любую операцию, которую вы использовали с версией зависимости в package.json. Это означает, что он не работает на моем компьютере, проблема не возникнет из-за какой-либо третьей стороны.
То же самое будет применяться к производственной версии, потому что в этой ветке теперь есть файл package-lock.json, он установит только те версии, на которых мы проверили стабильность нашего приложения. Но нам также следует подумать об удалении этого файла, если мы хотим автоматически обновлять версии всех зависимостей в ветке, где у нас есть время для подготовки нового выпуска и его тестирования. И снова. Позже повторно загрузите вновь созданный package-lock.json, когда мы проверим, что наша новая ветка стабильна и готова к выпуску в производство.
Кроме того, если у вас есть этот файл в помеченных ветках. Все теги, которые у вас есть, стабильны и их можно запускать после установки зависимости. Потому что теперь они точно знают, для какой версии зависимостей они были стабильными. Потому что в среде с открытым исходным кодом мы знаем, что даже в незначительных версиях иногда сторонние зависимости нарушают существующий код, который был реализован на них.
Хотя наличие стабильного производственного выпуска имеет много других факторов, таких как правильное тестирование, меньше ошибок в коде и т. Д. Но в следующий раз у вас будет сбой развертывания при развертывании на производстве. Шансы получить это из-за зависимости от третьей стороны очень меньше.
При ответственном использовании (фиксация и повторное удаление при необходимости) файл package-lock.json - это еще один шаг на пути к стабильному выпуску без внезапных сюрпризов в день производственного выпуска.
Чтобы узнать о таких операторах package.json, как ~, обратитесь здесь.
