Node.js-проекты, в которых лучше не использовать lock-файлы

[aol-nnov]

признаюсь, читал по диагонали, но…

Node.js-проекты, в которых лучше не использовать lock-файлы

выглядит так, будто вы собираетесь их поименно перечислить, проекты эти…

Сравним с оригиналом: «When Not to Use Lock Files with Node.js» — тоже не фонтан, конечно (не понятно, о каких локфайлах автор), но это «Когда не стоит использовать локфайлы в node.js»

[ru_vds]

Название, которое было в оригинале, «Когда не стоит использовать локфайлы в node.js» нам показалось слишком общим. В статье речь идёт о том, что эти файлы лучше не использовать при разработке того, что будет публиковаться в npm, то есть о Node.js-проектах, в которых лучше не использовать такие файлы. В результате и название — «Node.js-проекты, в которых лучше не использовать lock-файлы»

[index0h]

npm с 5-ой версии при обновлении затрагивает не только ваши зависимости, а и зависимости зависимостей (ЗЗ). В случае появления ошибки в ЗЗ+ исправить ее можно будет только вручную пропатчив код конкретной зависимости, зафиксировать ее в своем проекте не выйдет.
Это значит, что при сборке и заливке на production приложения вы не знаете, какие зависимости подтянутся в процессе.

Пример: https://github.com/raml-org/raml-js-parser-2/issues/775, так получилось, что этот пакет был зависимостью 3-го уровня, фактически мы получили не работающее приложение, без возможности зафиксировать рабочую версию ЗЗЗ.

К чему я это все? Локфайлы необходимы. Мне не ясны причины такого наплевательского отношения команды npm к этой проблеме. Так же не ясна причина появления shrinkwrap, если уже есть package-lock.

На данный момент рабочий вариант работы с зависимостями:

yarn install --ignore-optional --frozen-lockfile --non-interactive

[symbix]

Shrinkwrap был задолго до появления package-lock.

[serf]

Глупости написаны, лок файл необходим. Конечно в публикацию он не попадает и это потому что консьюмер модуля:
— Должен получить зависимости от зависимости согласно semver версиям указанным в засисимости. Если бы лок файл зависимости учитывался, то использовались бы зависимости на момент публикации что было бы плохой идее в большинстве случаев.
— Сам ответственен за работоспособность своего модуля. То есть проверяется работоспособность всей системы/модуля и лочатся все зависимости включая транзитивные при любом обновлении модулей. Это отвественность потребителя/консьюмера модуля.

[slonopotamus]

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

[slonopotamus]

локфайлы тут это конкретные версии библиотек, с которыми работает приложение

Я не понимаю чем это отличается от того что я сказал.

[justboris]

Если разработчик библиотеки захочет привязаться к конкретным версиям своих зависимостей, он может легко это сделать, указав их в package.json, то есть написать "lodash": "4.17.11", вместо "lodash": "4.x.x". Но этого не делают по двум причинам:

1. Фиксированные версии ухудшают дедупликацию зависимостей. Если одна библиотека запросит lodash строго 4.17.11, а другая строго 4.17.9, то они получат ровно эти версии, хотя они фактически ничем не отличаются, по правилам semver все 4.x релизы совместимы. В самом запущенном случае у вас может оказаться 43 копии lodash – вся линейка их релизов 4й версии.
2. Если зафисировать версии своих зависимостей, пользователи не получат баг-фиксы в них. В результате пользователи завалят вас запросами на обновление зависимостей. Примеры: раз, два, три. Если у вас много зависимостей, то придется каждую неделю выпускать такой псевдо-релиз.

А нынешняя ситуация всех устраивает. Авторы пакетов указывают допустимый диапазон версий и не отвлекаются на рутинные обновления. Пользователи записывают конкретные версии в package-lock и получают воспроизводимую сборку.

[slonopotamus]

Моя библиотека совместима с lodash-4.x.x, но тестировал я её с 4.17.9 и поскольку 100% обратной совместимости не бывает, имейте это в виду.

«Совместима с» — это package.json, а «тестировал с» — это лок-файл. Никто вам как пользователю библиотеки не запрещает положить болт как на одно, так и на другое, и насильно запустить мою библиотеку с другой версией lodash. Но зачем вы хотите убрать информацию о том с какой версией проверялась работоспособность?

[justboris]

А как эту информацию можно использовать? Допустим, эта информация есть, вы запускаете npm install, и дальше что происходит?

[slonopotamus]

Очевидно как: если у вас что-то не работает в районе моей библиотеки, то проверить не чинится ли всё магическим образом при использовании именно той версии зависимостей с которой она проверялась. Проблеме «что делать если по транзитивным зависимостям приехало две версии одного и того же» примерно столько же лет, сколько и в принципе пакетным менеджерам, и способы их разрешения давно придуманы:

1. Молча взять максимальную из требуемых
2. Потребовать пользователя выбрать
3. Поюзать _обе_ версии. Не во всех языках и окружениях такое возможно
4. Прочие безумия. Например, Maven молча выбирает ту версию, которая ближе по графу зависимостей. Здесь же вариант npm «а давайте забьём на информацию о желаемой библиотекой версии зависимостей». Нет информации — нет проблемы с выбором.

[L2jLiga]

А что мешает указать, версию ^4.17.9 в списке зависимостей? В таком случае вы явно указываете, что надо брать lodash >= 4.17.9, но < 5. Это отлично вписывается в semver и если авторы lodash не будут нарушать правила семантического версионирования, то ваша библиотека не сломается.