Package-lock.json

Обсуждения
1

Привет все,
такой вопрос:
Обычно я включаю package-lock.json ( ярн там же) в .gitignore (*-lock.json, *.lock)
Насколько это здраво и почему.

2

совсем не здраво, главная задумка package-lock как раз в том чтоб его коммитить и достичь повторяемых билдов.

1 лайк
3

вот даже в официальной доке “It is highly recommended you commit the generated package lock to source control…”
https://docs.npmjs.com/files/package-locks

1 лайк
4

package-lock.json нужно включать в репозиторий.

Задача package-lock.json (как и ярн файла) - описать точные версии зависимостей и что важнее, зависимостей всех зависимостей (транзитивные зависимости). Это гарантирует что тот кто установит зависимости из твоего репозитория получит именно те же версии что установлены у тебя.

Что может пойти не так. Допустим у тебя зависимость в package.json ^2.4.1 автор выпускает 2.5.0 в которой бага/изменение api. У нового разработчика при установке зависимостей поставится 2.5.0, проект на запустится, а ты не будешь видеть ошибки у себя локально потому что у тебя и package-lock и локальные зависимости вообще про другую версию. Возможно у тебя CI тогда ты узнашешь о проблеме раньше, но все равно причины не будут прозрачны. Возможно проблема не проявит себя до рантайма, тогда еще сложнее найти корень проблемы.

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

При включении package-lock.json в репозиторий ты гарантируешь (с большой но не 100% увереностью) что у других установятся те же пакеты что и у тебя, соответственно окружение будет одинаковым, соответственно поведение будет одинаковым.

Лок файл не самого большого проекта https://github.com/podgorniy/media-manager/blob/master/package-lock.json. Каждая зависимость может сломаться при своем обновлении. Нафик рискровать на таких масштабах.

2 лайка
5

ок package-lock.json - я скачал твой проект и стартанул yarn

  • дружит ли yarn.lock с package-lock.json ?

и есть вопрос с зависимостями типа
dependencies, devDependencies в основном слышал, что это особой роли не играет где будет лижать либа…

One key detail about package-lock.json is that it cannot be published, and it will be ignored if found in any place other than the toplevel package.

6

и да когда мы качаем проекты там какой нибудь kit или ещу там темки или типа CLI - то там никаких lock не прилитает

и тут тоже вопрос @dmitry пишет:

Допустим у тебя зависимость в package.json ^2.4.1 автор выпускает 2.5.0

а если не так, а если я запишу package.json: 2.4.1 как строгое - то отпадет надобность в package-lock.json

7

Без понятия. Но чутье подсказывает что придерживаться нужно только одного пакетного менеджера.

Зависит. dependencies - это рантайм зависимости приложений. Например для nodejs бекенд приложений.

Для пакетов распространяемых через npm dependencies - это те зависимости которые нужны чтобы пакет работал. Тоже можно думать как о runtime зависимостях.

В клиентских приложениях где на выходе получается скомпилированный бандл я складываю все зависимости в devDependencies.

8

Не так просто. Внутри этого пакета могут быть зависимости с ^ от других пакетов (транзитивные зависимости). Получается что конечный список установленных пакетов все равно будет зависить от того в какое время запускался npm install.

9

Этого не знал. Но не вижу в этом поведение чего-то такого что бы говорило о том что package-lock не нужно включать в репозиторий. Тот-же pug локфайл держит в репозитории: https://github.com/pugjs/pug/blob/master/yarn.lock

10

🐀 Всем спасибо