Какой смысл в объявлении package.json «совместимой версии» (^ version), если package-lock.json ее блокирует?

Question

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

Но одна вещь, которая кажется странной дляу меня есть то, что package.json имеет функцию объявления зависимости как dependency: ^1.0.0, которая должна делать npm для загрузки самой последней и совместимой версии этого пакета в каждой установке.

Я работаю над проектомчто мне на самом деле это нужно.В противном случае каждый раз, когда моя зависимость выпускает патч, потребуется сделать новое обновление фиксации package.json, только изменив версию, поэтому мой конвейер также может перезаписать package-lock.json.

Короче говоря, кажется, что покаpackage.json использует функцию ... package-lock.json предотвращает ее.

Я что-то упустил?

Answer 1

Как я уже упоминал в комментарии выше, краткий ответ таков: update облегчает ваши зависимости.

Однако другой способ, которым мне нравится думать о двух файлах: package.json - это файл, который читает человек, а package-lock.json - это файл, который читает компьютер.

NPM - менеджер пакетов / зависимостей.Итак, в вашем файле package.json вы пишете «эти библиотеки необходимы для работы моей библиотеки».Как функция , у вас есть ряд версий, в которых вы можете перечислить зависимости.Это помогает, когда вы запускаете npm update для определенного пакета.Он посмотрит, какая последняя версия соответствует вашему * package.json **, и обновит ваш файл блокировки.

Файл блокировки package-lock.json полезен, потому что онПодробно описывает, как выглядит ваша папка node_modules / , чтобы ее можно было точно воссоздать, когда кто-то другой установит вашу библиотеку.Кроме того, поскольку этот файл генерируется автоматически, вам не нужно беспокоиться о его поддержке.

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

По сути, это просто удобство.У вас есть один файл, чтобы кратко перечислить, какие зависимости нужны вашим проектам.Это читается и легко обновляется.Другой файл, файл блокировки, генерируется автоматически и гарантирует, что каждая npm install предоставляет вам ту же самую папку node_modules / , что и раньше.

Answer 2

Смысл package-lock.json состоит в том, чтобы точно представить дерево , поскольку оно действительно существует в определенный момент времени, чтобы кто-то, клонирующий проект, получил точно то же дерево, что и у вас.

Если вы хотите обновить эту зависимость до более новой версии, просто используйте npm update и затем подтвердите обновленный package-lock.json.Другие члены вашей команды получат это обновление как часть обычного процесса получения последней версии.

Подробнее на странице npmjs.com о блокировках пакетов .

Давайте рассмотрим сценарий, когда мы с вами в команде, и наш проект использует nifty-lib, где package.json говорит "nifty-lib": "^0.4.0", а мы не разделяем package-lock.json.Возможно, я работал над проектом на пару месяцев дольше, чем вы, и я получил nifty-lib v0.4.0, когда я его установил.Но когда вы подняли его и установили, вы получили v0.4.1 (обновление с исправлением ошибок, которое, к сожалению, представило новую ошибку).В какой-то момент вы замечаете что-то вроде ошибки в нашем проекте, но я не могу ее воспроизвести.Некоторое время мы вращаемся, пытаясь понять, почему это происходит с тобой, а не со мной.В конце концов, мы понимаем, что на самом деле это ошибка в nifty-lib, которую они представили в v0.4.1.Надеемся, что тогда мы получим 0.4.2 или что-то в этом роде (или, если его нет, мы исправим ошибку и сделаем пиар, при этом откатившись до 0.4.0 по всему проекту).

Если бы мы былиподелившись package-lock.json, мы бы не развернулись, задаваясь вопросом, почему проблема произошла с вами, а не со мной, потому что у вас была бы та же версия nifty-lib, что и у меня.Как часть нашего обычного цикла, мы будем периодически делать npm update, и если в наших тестах обнаружится новая ошибка, мы узнаем из истории коммитов, что это произошло из-за ошибки в зависимости.

Теперь для «я» и «вы» читайте «dev» и «production».: -)

Именно поэтому package-lock.json блокирует версию, а package.json позволяет вам сказать «это или лучше».package-lock.json сохраняет вашу команду унифицированной в версиях, но вы можете намеренно обновлять с помощью npm update, который отображается в истории коммитов, чтобы вы могли отслеживать регрессии к нему.