RUVDS.com corporate blog
Website development
JavaScript
Node.JS
Comments 14
+7
признаюсь, читал по диагонали, но…
Node.js-проекты, в которых лучше не использовать lock-файлы

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

Сравним с оригиналом: «When Not to Use Lock Files with Node.js» — тоже не фонтан, конечно (не понятно, о каких локфайлах автор), но это «Когда не стоит использовать локфайлы в node.js»
-1
Название, которое было в оригинале, «Когда не стоит использовать локфайлы в node.js» нам показалось слишком общим. В статье речь идёт о том, что эти файлы лучше не использовать при разработке того, что будет публиковаться в npm, то есть о Node.js-проектах, в которых лучше не использовать такие файлы. В результате и название — «Node.js-проекты, в которых лучше не использовать lock-файлы»
0

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

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

+2

Нет, локфайлы тут это конкретные версии библиотек, с которыми работает приложение. А распространяется же приложение с package.json файлом, в котором указаны минимальные версии библиотек, с которыми приложение работает. Все версии подчиняются semver, это значит, как минимум на уровне minor версии библиотеки будут обратно совместимы. Разработчик самой либы это гарантирует. И это позволит подхватывать все совместимые обновления.


В других языках тоже не стоит таскать локфайлы вместе с либами, у раста как минимум видел объяснение. Так что это не чисто js практика.

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

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

+1

Если разработчик библиотеки захочет привязаться к конкретным версиям своих зависимостей, он может легко это сделать, указав их в 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 и получают воспроизводимую сборку.

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

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

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

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

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

В JS как раз используется третий вариант, но он плох тем, что некоторые пакеты, которые спроектированы как синглтоны, станут в нескольких экземплярах, отчего приложение начнёт вести себя некорректно. Конечно, таких пакетов не очень много, но ситуация реальная.


Другой момент — множественные версии пакетов увеличивают объём приложения. Это критично для фронтенда. Соответственно разработчикам конечного приложения лучше самостоятельно выбрать подходящую версию пакета.

0

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

Only those users with full accounts are able to leave comments. , please.