Lock файл что это
двоичный
Этот файл сохраняется в двоичном формате, который требует определенной программы для чтения его содержимого.
Что такое lock-файл?
Lock-файл описывает полное дерево зависимостей в том виде, который оно приобрело в ходе работы над проектом. В это описание входят и вложенные зависимости. В файле содержатся сведения о конкретных версиях используемых пакетов. В менеджере пакетов npm такие файлы называются package-lock.json , в yarn — yarn.lock . И в том и в другом менеджерах эти файлы находятся в той же папке, что и package.json .
Вот как может выглядеть файл package-lock.json .
Вот пример файла yarn.lock . Он оформлен не так, как package-lock.json , но содержит похожие данные.
Оба эти файла содержат некоторые крайне важные сведения о зависимостях:
- Точную версию каждой установленной зависимости.
- Сведения о зависимостях каждой зависимости.
- Данные о загруженном пакете, включая контрольную сумму, используемую для проверки целостности пакета.
Самое главное в двух словах
Lock-файлы крайне полезны при разработке Node.js-приложений вроде веб-серверов. Однако если речь идёт о создании библиотеки или инструмента командной строки с прицелом на публикацию в npm, то нужно знать о том, что lock-файлы в npm не публикуются. Это означает, что если при разработке применяются эти файлы, то у создателя npm-пакета, и у тех, кто этот пакет использует, будут задействованы разные версии зависимостей.
Содержание:
Тип файла 2Minecraft World Lock File
разработчик | Моджанг Технические характеристики |
популярность | 3,4 (20 голосов) |
категория | Файлы игр |
Формат | Бинарный Х |
Альтернативные типы LOCK
Расширение: | .lock |
Тип: | Minecraft World Lock File |
расширение файла LOCK может ссылаться на файл, используемый Minecraft по имени Session.lock. Minecraft является блок-строительная игра, которая является открытым. Этот файл LOCK входит как часть мировых данных Minecraft. Он предусматривает применение Minecraft с возможностью блокировки мира так, когда мир был последним доступен только один экземпляр Minecraft должен быть открыт и сохраняет метку времени для этого. Одна из политики блокировки, использование Minecraft является то, что владелец мир является последней инстанцией, чтобы открыть мир. Если содержимое Session.lock изменились после того, как его временной метки письменного вида, например, экземпляр и прерывает отдает замок.
Программист: | Mojang |
Класс: | Файлы игр |
Программы, открывающие файлы Minecraft World Lock File :
Автор материала, перевод которого мы сегодня публикуем, говорит, что одна из проблем, с которыми приходится сталкиваться программистам, заключается в том, что у них их код работает, а у кого-то другого выдаёт ошибки. Эта проблема, возможно, одна из самых распространённых, возникает из-за того, что в системах создателя и пользователя программы установлены разные зависимости, которые использует программа. Для борьбы с этим явлением в менеджерах пакетов yarn и npm существуют так называемые lock-файлы. Они содержат сведения о точных версиях зависимостей. Механизм это полезный, но если некто занимается разработкой пакета, который планируется опубликовать в npm, lock-файлы ему лучше не использовать. Этот материал посвящён рассказу о том, почему это так.
Видео: Расширение файла LOCK - Что такое файл .lock и как я могу его открыть?
Отказ от lock-файлов и использование технологии shrinkwrap
Для начала нужно предотвратить включение lock-файлов в репозиторий проекта. При использовании git для этого нужно включить в файл проекта .gitignore следующее:
В документации к yarn говорится, что yarn.lock нужно добавлять в репозиторий даже если речь идёт о разработке библиотеки, которую планируется публиковать. Но если вы хотите, чтобы вы и пользователи вашей библиотеки работали бы с одним и тем же кодом, я порекомендовал бы включить yarn.lock в файл .gitignore .
Отключить автоматическое создание файла package-lock.json можно, добавив в папку проекта файл .npmrc со следующим содержимым:
При работе с yarn можно воспользоваться командой yarn install --no-lockfile , которая позволяет отключить чтение файла yarn.lock .
Однако то, что мы избавились от файла package-lock.json , ещё не означает, что мы не можем зафиксировать сведения о зависимостях и о вложенных зависимостях. Есть ещё один файл, который называется npm-shrinkwrap.json .
В целом, это такой же файл, как и package-lock.json , он создаётся командой npm shrinkwrap . Этот файл попадает в реестр npm при публикации пакета.
Для того чтобы автоматизировать эту операцию, команду npm shrinkwrap можно добавить в раздел описания скриптов файла package.json в виде prepack-скрипта. Того же эффекта можно добиться, используя хук git commit. В результате вы сможете быть уверены в том, что в вашем окружении разработки, в вашей CI-системе, и у пользователей вашего проекта используются одни и те же зависимости.
Стоит отметить, что этой методикой рекомендуется пользоваться ответственно. Создавая shrinkwrap-файлы, вы фиксируете конкретные версии зависимостей. С одной стороны это полезно для обеспечения стабильной работы проекта, с другой — это может помешать пользователям в установке критически важных патчей, что, в противном случае, делалось бы автоматически. На самом деле, npm настоятельно рекомендует не использовать shrinkwrap-файлы при разработке библиотек, ограничив их применение чем-то вроде CI-систем.
.LOCK File Association 2
Файл LOCK - это файл блокировки, используемый Minecraft, открытой игрой для создания блоков. Он включен как часть данных для мира Minecraft и позволяет приложению Minecraft заблокировать мир так, чтобы открыть его мог только один экземпляр Minecraft. Файлы LOCK сохраняют временную метку для времени последнего доступа к миру. Дополнительная информация
Файл LOCK обычно называется session.lock. Minecraft использует политику блокировки так, что последний случай, чтобы открыть мир, является мировым владельцем. Если содержимое файла session.lock изменяется после того, как экземпляр записал свою временную метку, экземпляр прерывается и снимает блокировку.
package-lock.json
При возникновении конфликта при вызове команд Git в консоли будет выведено:
Для работы с lock-файлами не требуется каких-то особых действий со стороны разработчика, npm автоматически обновляет lock-файл, когда в этом есть необходимость. Например, если вы вызываете команду npm install lodash , то помимо того, что npm добавит новую зависимость в манифест и установит её, он автоматически обновит lock-файл. Таким образом, npm всегда следит, чтобы lock-файл был в актуальном состоянии.
Однако если вы вносите изменения в манифест проекта вручную, например, добавляя новую зависимость, то возникает «дрифт» (рассинхронизация) между манифестом и lock-файлом. Менеджер пакетов достаточно умён, чтобы обнаружить этот дрифт: когда вы вызовете команду npm install , npm проанализирует актуальность lock-файла, и если он устарел, то менеджер пакетов автоматически обновит lock-файл, используя данные из манифеста.
Как я сказал выше, если npm обнаружит отставание lock-файла от манифеста, то это приведет к обновлению lock-файла и установке зависимостей из манифеста. Такое поведение очень удобно при разработке, но совершенно непригодно, и даже опасно в контексте конвейера CI/CD, потому что может привести к неожиданным результатам из-за слетевшей блокировки зависимостей.
Чтобы этого не происходило, разработчики npm добавили специальную команду npm ci. В отличие от npm install , эта команда никогда не обновляет lock-файл. Более того, если в проекте отсутствует или устарел lock-файл, то npm ci вернет код ошибки и прервет выполнение конвейера, гарантируя, что ничего плохого не случится (принцип Fail-fast). Кроме того, npm ci полностью удаляет директорию node_modules перед установкой зависимостей, что гарантирует установку на чистый лист.
По этой причине никогда не следует использовать команду npm install в рамках конвейера CI/CD, обязательно используйте npm ci вместо нее. Идите и проверьте это прямо сейчас! (я подожду).
Давайте теперь поговорим про особенности использования lock-файлов в проектах разных типов. Первое, о чём стоит сказать: файл package-lock.json не публикуется в npm registry. Это означает, что если вы публикуете свой пакет в реестр npm (библиотека), то содержимое вашего lock-файла не будет оказывать влияния на дерево зависимостей при установке вашего пакета в чей-то проект. В этом случае играет роль только содержимое вашего манифеста. Это и хорошо: если бы каждая библиотека замораживала свои зависимости, то дерево зависимостей в конечном проекте было бы ещё больше (куда уж больше?) и содержало огромное количество дублей. Адекватно управлять зависимостями стало бы невозможно.
Однако в npm есть специальная команда npm shrinkwrap. Она создает файл npm-shrinkwrap.json в корне проекта, который является тем же lock-файлом, только с другим именем и семантикой. Особенность его в том, что, в отличие от package-lock.json , он таки публикуется в реестр npm и оказывает непосредственное влияние на дерево зависимостей при установке вашего пакета. Фактически, он замораживает дерево зависимостей вашего пакета, даже если тот устанавливается в другой проект.
Как я сказал выше, использовать это решение для библиотек очень вредно, поэтому не стоит этого делать. Однако, оно может быть полезно, если вы разрабатываете программу на Node.js, которая должна выполняться на компьютере пользователя (например, аналог webpack, gulp, create-react-app и т. д.). Если программа устанавливается преимущественно глобально на компьютере пользователя ( npm i -g ), то использование shrinkwrap-файла гарантирует, что на машине пользователя программа будет иметь те же зависимости, что и на вашей машине. Так что, если у вас есть явные причины опасаться дрифта зависимостей в вашей программе, то вы можете воспользоваться npm shrinkwrap . В остальных случаях я не рекомендовал бы использовать эту команду.
Кстати, файл npm-shrinkwrap.json имеет приоритет над файлом package-lock.json . В проекте достаточно только одного файла.
Важным этапом в работе над проектом библиотеки является его тестирование. Дело в том, что вы полностью не контролируете внешние условия, в которых будет вызываться ваша библиотека. Даже если вы зафиксируете прямые зависимости, вы не сможете зафиксировать транзитивные (разве что будете использовать shrinkwrap , но мы уже выяснили, что это плохая практика).
По этой причине вы не можете гарантировать среду, однако можете протестировать работу библиотеки со свежими версиями всех зависимостей, чтобы убедиться, что в новых и свежих проектах ничего не сломается. Однако, если вы будете использовать lock-файл в вашем проекте, то он будет постоянно оттягивать версии ваших зависимостей назад, не давая вам полноценно тестировать совместимость с самыми свежими версиями всех зависимостей (которые наверняка будут у ваших пользователей). Либо вам придется постоянно вызывать глубокий npm update перед каждым тестом.
Руководствуясь этим, некоторые разработчики советует вообще не использовать lock-файлы для проектов библиотек. Однако, я считаю это слишком радикальным советом. Дело в том, что помимо продуктовых runtime-зависимостей вашего пакета существуют еще и dev-зависимости. Если вы откажетесь от lock-файла, то ваши dev-зависимости выйдут из-под контроля, то есть вы потеряете некий островок стабильности.
Более подходящим решением, на мой взгляд, была бы реорганизация конвейера CI/CD таким образом, чтобы код библиотеки тестировался в проекте без использования lock-файла, путем установки самых свежих доступных зависимостей. Собирать же пакет (если требуется) можно и с участием lock-файла (для этого можно использовать два разных этапа в вашем CI/CD конвейере).
У многих разработчиков lock-файлы вызывают чувство раздражения, видимо, из-за непонимания их предназначения или особенностей их работы. Такие разработчики норовят добавить package-lock.json в .gitignore или вообще настроить npm, чтобы запретить генерирование lock-файлов. При этом они (часто сами того не понимая) жертвуют стабильностью и безопасностью своего приложения, а также теряют достаточно мощный инструмент отслеживания изменений зависимостей в проекте. Часто эти же люди начинают строго прописывать версии зависимостей в основном манифесте, чтобы как-то компенсировать эту нестабильность, не отдавая себе отчета в том, что это не решает проблему, а только создает иллюзию её решения. Я уже не говорю о том, что они используют инструмент не по назначению, теряя гибкость разработки, которая обеспечивается, в том числе, и механизмами семантического версионирования.
Надеюсь, теперь, лучше понимая, как работают эти механизмы, вы сможете эффективнее наладить управление зависимостями в вашем проекте и повысить его надежность и безопасность.
Помните, задача lock-файлов заключается не в том, чтобы навсегда заблокировать все зависимости и больше никогда их не обновлять, а в том, чтобы обеспечить повторяемость их установки и прозрачность их обновления.
Залог высокого качества, поддерживаемости и удобства разработки вашего проекта заключается в частом обновлении зависимостей. Согласитесь, гораздо проще обновлять зависимости маленькими порциями по мере их выхода. Diff lock-файла всегда покажет, что именно обновилось. Если он будет небольшим, то вы легко сможете его прочитать. Если же после обновления возникнет проблема, то, скорее всего, она будет одна, и её будет несложно обнаружить и изолировать.
С другой стороны, если вы не будете полгода обновлять зависимости, то потом сделать это будет очень сложно, потому что крупное обновление очень сложно разделить на маленькие части. Вы получите огромный ворох изменений разной степени тяжести, а в случае возникновения проблемы (а она, скорее всего, придет не одна) выявить точное место будет гораздо сложнее (diff здесь уже будет бесполезен в силу его гигантского размера).
Поэтому не запускайте ваши зависимости, обновляйтесь регулярно, возьмите это в привычку, тогда издержки на поддержку кодовой базы будут минимальны. Переход же на новые мажорные версии библиотек будет более планомерным: гораздо проще обновиться на одну мажорную версию библиотеки, чем на несколько сразу.
Мы рассмотрели столь важный инструмент повышения надежности и безопасности управления зависимостями, как lock-файлы npm. Использование этого механизма позволит вам существенно повысить стабильность работы вашего проекта и улучшить качество и удобство разработки.
В следующем посте я еще дальше углублюсь в вопросы безопасности npm.
Если вам понравился материал, то, пожалуйста, ставьте лайки, подписывайтесь на наш блог и делитесь ссылками с коллегами. Так мы будем понимать, что наша работа востребована, и будем продолжать радовать вас новыми полезными материалами.
Если у вас есть вопросы или желание что-то добавить по теме, то не бойтесь оставлять комментарии, я с радостью приму участие в обсуждении и учту ваши пожелания в следующих постах.
Следующая мажорная версия NPM приносит ряд улучшений по сравнению с предыдущими версиями с точки зрения скорости, безопасности и множества других отличных вещей. Однако самым необычным с точки зрения пользователя является новый lock-файл. Фактически, теперь у нас несколько lock-файлов: «старый» npm-shrinkwrap.json и новый package-lock.json . Подробнее об этом чуть ниже, а пока небольшая вводная для непосвящённых. Файл package.json описывает зависимости верхнего уровня от других пакетов с помощью semver. Каждый пакет может, в свою очередь, зависеть от других пакетов и так далее, тому подобное. Lock-файл — это моментальный снимок всего дерева зависимостей, включающий все пакеты и их установленные версии.
В отличие от предыдущей версии, lock-файл теперь включает в себя поле целостности (integrity), использующее Subresource Integrity (SRI) для проверки того, что установливаемый пакет не был подменён или иным образом недействителен. В настоящее время он поддерживает SHA-1 для пакетов, опубликованных с помощью NPM предыдущей версии, и SHA-512 для текущей.
В файле больше нет поля from , которое вместе с иногда неконсистентной version , как известно, было источником боли при просмотре изменений файлов во время процесса код-ревью. Теперь изменения в пулл-реквестах должны быть намного чище.
Lock-файл теперь также содержит версию формата, указанную в поле lockfileVersion , установленную в значение 1 . Это значит, что при будущих обновлениях формата не придётся угадывать, какую конкретную версию использует lock-файл. Предыдущий формат по-прежнему поддерживается и распознается как версия 0 .
Возможно, вы заметили, что поле resolved все еще присутствует в файле и указывает на определенный URI. Обратите внимание, однако, что NPM теперь может определить (на основе параметров в .npmrc ), что система настроена на использование другого реестра, и если это так, он будет прозрачно использовать его вместо указанного. Это хорошо работает с полем целостности, потому что теперь, пока пакет соответствует сигнатуре, не имеет значения, откуда он пришел.
Еще одна вещь, о которой стоит упомянуть: lock-файл точно описывает физическое дерево каталогов в директории node_modules . Преимущество этого заключается в том, что даже если разные разработчики используют разные версии NPM, они все равно должны иметь не только одни и те же версии зависимостей, но и то же самое дерево каталогов. Этим NPM 5 отличается от других пакетных менеджеров, таких как Yarn. Yarn описывает только зависимости между отдельными пакетами в плоском формате и опирается на свою текущую реализацию для создания структуры каталогов. Это означает, что при изменении внутреннего алгоритма структура также изменится. Если вы хотите узнать больше о различиях между Yarn и NPM 5, когда дело доходит до lock-файла, почитайте про детерминизм Yarn.
Я уже упоминал, что сейчас на самом деле имеется больше одного lock-файла. Теперь NPM автоматически генерирует lock-файл с именем package-lock.json всякий раз, когда устанавливается новая зависимость или файл еще не существует. Как уже упоминалось в начале, lock-файл представляет собой моментальный слепок текущего дерева зависимостей и позволяет воспроизводить сборки между машинами разработчиков. Поэтому рекомендуется добавить его в свою систему контроля версий.
Возможно, вы думаете, что то же самое уже может быть достигнуто с помощью npm shrinkwrap и её npm-shrinkwrap.json . И вы правы. Причиной создания нового файла является попытка лучшего донесения мысли о том, что NPM действительно поддерживает блокировку зависимостей, что, видимо, было проблемой в прошлом.
Однако есть несколько отличий. Во-первых, NPM гарантирует, что package-lock.json никогда не будет опубликован. Даже если вы явно добавите его в свойство файлов пакета, оно не будет частью опубликованного пакета. Это не относится к файлу npm-shrinkwrap.json , который может быть частью опубликованного пакета, и NPM будет использовать его даже для вложенных зависимостей. Просто попробуйте сами, запустив npm pack и посмотрев, что находится внутри созданного архива.
Также вам может быть интересно узнать, что происходит, когда вы запускаете npm shrinkwrap в каталоге, который уже содержит package-lock.json . Ответ довольно прост: NPM просто переименует package-lock.json в npm-shrinkwrap.json . Это возможно, потому что формат файлов совпадает.
Самое любопытные также спросят, что происходит, когда присутствуют оба файла. В этом случае NPM полностью игнорирует package-lock.json и просто использует npm-shrinkwrap.json . Однако такая ситуация не должна возникать при манипулировании файлами средствами NPM.
- NPM автоматически создаст package-lock.json при установке пакетов. Если уже присутствует npm-shrinkwrap.json , то будет использован он (и при необходимости обновлён).
- Новый package-lock.json никогда не публикуется и должен быть добавлен в вашу систему контроля версий.
- Запуск npm shrinkwrap в случае наличия package-lock.json просто переименует его в npm-shrinkwrap.json .
- Когда оба файла присутствуют по какой-либо причине, package-lock.json будет проигнорирован.
Это здорово, но как выбрать: использовать новый lock-файл вместо старого доброго shrinkwrap или наоборот? Обычно это зависит от типа пакета, над которым вы работаете.
Если вы работаете с библиотекой (то есть пакетом, от которого будут зависеть другие пакеты), вы должны использовать новый lock-файл. Альтернативой является использование shrinkwrap, но убедитесь, что он никогда не будет опубликован вместе с пакетом (новый lock-файл защищён от публикации автоматически). Почему бы не опубликовать shrinkwrap? Это связано с тем, что NPM обрабатывает shrinkwrap-файлы, которые он находит в пакетах, и поскольку shrinkwrap всегда указывает на конкретные версию отдельных пакетов, вы не сможете воспользоваться тем фактом, что NPM может использовать один и тот же пакет для разрешения зависимостей нескольких пакетов, если диапазон semver позволяет это. Другими словами, не заставляя NPM устанавливать определенные версии, вы позволяете NPM эффективнее повторно использовать пакеты, что в результате приводит к более компактному дереву зависимостей и упрощает сборку.
Однако есть одно предостережение. Когда вы работаете в своей библиотеке, вы получаете одинаковые зависимости каждый раз, потому что в репозитории присутствует либо package-lock.json , либо npm-shrinkwrap.json . То же самое относится к вашему серверу непрерывной интеграции, на котором вы проверяете ваш код. Теперь представьте, что в вашем package.json указана зависимость от некоторого пакета как ^1.0.0 . Каждый раз устанавливается версия, указанная в lock-файле и всё прекрасно работает. А что происходит, если публикуется новая версия зависимости, случайно нарушившая semver, и ваш пакет ломается из-за этого?
К сожалению, вы не сможете заметить этого до тех пор, пока не появится отчет об ошибке. Без каких-либо lock-файлов в репозитории ваша сборка завершится неудачно, по крайней мере, в CI, поскольку она всегда будет устанавливать последние версии зависимостей и, таким образом, запускать тесты с новой сломанной версией (при условии, что сборка выполняется периодически, а не только для PR). Однако при наличии lock-файла CI-сервер всегда будет устанавливать рабочую заблокированную версию.
Есть несколько вариантов решения этой проблемы. Во-первых, вы можете пожертвовать точной воспроизводимостью и не добавлять lock-файл в свою систему контроля версий. Во-вторых, вы можете создать отдельную конфигурацию сборки, которая будет запускать npm update перед запуском тестов. В-третьих, вы просто удаляете lock-файл перед запуском тестов. Как на самом деле поступать с сломанной зависимостью, когда она была обнаружена, это отдельная тема, главным образом потому, что semver, реализованный NPM, не имеет концепции указания разрешения широкого диапазона и также не имеет черного списка конкретных версий.
Это, конечно, ставит вопрос о том, стоит ли добавлять lock-файл в систему управления версиями при работе с библиотеками. Однако следует иметь в виду, что lock-файл содержит не только runtime-зависимости, но и зависимости для разработки (dev dependencies). В этом смысле работа над библиотекой аналогична работе над приложением (смотрим следующий раздел).
Хорошо, что насчёт пакетов, используемых конечными пользователями для запуска в консоли или в комплекте исполняемых файлов? В этом случае пакет — это конечный результат, приложение, и вы хотите, чтобы конечные пользователи всегда получали точные зависимости, которые вы имели при публикации. Здесь вы захотите использовать shrinkwrap и не забудьте также опубликовать его с пакетом, чтобы NPM использовал его во время установки. Помните, что вы всегда можете проверить, как выглядит пакет, если он будет опубликован с использованием npm pack .
Обратите внимание, что указание на определенные версии зависимостей в package.json - не лучшая идея, потому что вы хотите, чтобы конечные пользователи получили то же самое дерево зависимостей, включая все подзависимости. Конкретная версия в package.json гарантирует версию только на верхнем уровне.
Что насчет других типов приложений, например, проектов, которые вы запускаете из своего репозитория? В этом случае это не имеет большого значения. Имеют значение только установленные правильные зависимости, и оба lock-файла могут это обеспечить. Выбор за вами.
Выяснение сведений о пакетах и зависимостях
К сожалению, при всём богатстве сведений об управлении зависимостями в документации npm, в этих сведениях иногда сложно бывает сориентироваться. Если вы хотите узнать о том, что именно устанавливается при установке зависимостей или упаковывается перед отправкой пакета в npm, вы можете, с разными командами, воспользоваться флагом --dry-run . Применение этого флага приводит к тому, что команда не оказывает воздействия на систему. Например, команда npm install --dry-run не выполняет реальную установку зависимостей, а команда npm publish --dry-run не запускает процесс публикации пакета.
Вот несколько подобных команд:
Сравнение package.json и lock-файлов
Цель поля dependencies файла package.json заключается в том, чтобы показать зависимости проекта, которые должны быть установлены для его правильной работы. Но сюда не входят сведения о зависимостях этих зависимостей. В сведения о зависимостях могут входить точные версии пакетов или некий диапазон версий, указанный в соответствии с правилами семантического версионирования. При использовании диапазона npm или yarn выбирают наиболее подходящую версию пакета.
Предположим, для установки зависимостей некоего проекта была выполнена команда npm install . В процессе установки npm подобрал подходящие пакеты. Если выполнить эту команду ещё раз, через некоторое время, и если за это время вышли новые версии зависимостей, вполне может случиться так, что во второй раз будут загружены другие версии использованных в проекте пакетов. Например, если устанавливается зависимость, наподобие twilio , с использованием команды npm install twilio , то в разделе dependencies файла package.json может появиться такая запись:
Если посмотреть документацию npm по семантическому версионированию, то можно узнать, что значок ^ указывает на то, что подходящей является любая версия пакета, номер которой больше или равен 3.30.3 и меньше 4.0.0. В результате, если в проекте нет lock-файла и выйдет новая версия пакета, то команда npm install или yarn install автоматически установит эту новую версию пакета. Сведения в package.json при этом обновляться не будут. При использовании lock-файлов всё выглядит иначе.
Если npm или yarn находят соответствующий lock-файл, они будут устанавливать пакеты, опираясь именно на этот файл, а не на package.json . Это особенно полезно, например, при использовании систем непрерывной интеграции (Continuous Integration, CI) на платформах, на которых нужно обеспечить единообразную работу кода и тестов в окружении, характеристики которого известны заранее. В подобных случаях можно использовать особые команды или флаги при вызове соответствующих менеджеров пакетов:
Это крайне полезно в том случае, если вы занимаетесь разработкой проекта наподобие веб-приложения или сервера, так как в CI-окружении нужно сымитировать поведение пользователя. В результате, если мы будем включать lock-файл в репозиторий проекта (например, созданный средствами git), мы можем быть уверенными в том, что каждый разработчик, каждый сервер, каждая система сборки кода и каждое CI-окружение используют одни и те же версии зависимостей.
Почему бы не сделать то же самое при публикации библиотек или других программных инструментов в реестре npm? Нам, прежде чем ответить на этот вопрос, нужно поговорить о том, как устроен процесс публикации пакетов.
Что такое файл LOCK?
Файл LOCK - это файл, используемый различными операционными системами и программами для блокировки ресурса, такого как файл или устройство. Обычно он не содержит данных и существует только в виде пустого файла маркера, но также может содержать свойства и настройки для блокировки. Дополнительная информация
Файлы LOCK сигнализируют приложениям, что ресурс не должен использоваться до снятия блокировки. Это полезно для программ, которым необходимо предотвращать одновременный доступ к критически важным ресурсам. Для блокировки файлов программы обычно создают новый файл и добавляют расширение «.lock» для исходного имени файла. Например, файл блокировки для «example.file» будет «example.file.lock».
Файлы LOCK обычно встречаются в системах на основе Unix, включая системные блокировки файлов Red Hat Linux. Другие примеры файлов LOCK включают файл parent.lock Mozilla, который блокирует профили Windows Firefox, и файлы блокировки веб-сервера Apache, которые создаются с использованием директивы LockFile.
Ведущий тип LOCK
Расширение: | .lock |
Тип: | Lock File |
LOCK расширение файла представляет собой текстовый и бинарный файл типа, который ссылается на файл, используемый для блокировки ресурса, такие как; файлы или устройства. Он используется различными операционными системами и программами. Как правило, она не содержит данных и существует как пустой файл маркера. Свойства и параметры блокировки могут быть включены в файл. LOCK файлов отметьте приложения, ресурсы внутри него не следует использовать до тех пор, отпустив замок. Программы, которые должны предотвратить его критические ресурсы от одновременного доступа будет найти LOCK файл полезно для него. системы Unix на основе, такие как системы Red Hat Linux обычно используют LOCK файлов, а также файл parent.lock Mozilla, и файлы блокировки Apache Web Server.
Программист: | Mozilla |
Класс: | Необычные файлы |
Ключ: | HKEY_CLASSES_ROOT\.lock |
Программные обеспечения, открывающие Lock File:
![](https://www.solvusoft.com/file-extensions/images/os-family/windows.jpg)
Windows |
![](https://www.solvusoft.com/file-extensions/images/os-family/apple.jpg)
![]() | Mac |
![]() | iOS |
![](https://www.solvusoft.com/file-extensions/images/os-family/android.jpg)
Android |
![](https://www.solvusoft.com/file-extensions/images/os-family/linux.jpg)
Linux |
![](https://www.solvusoft.com/file-extensions/images/os-family/solaris.jpg)
Solaris |
![](https://www.solvusoft.com/file-extensions/images/os-family/unix.jpg)
![]() | illumos |
![](https://www.solvusoft.com/file-extensions/images/os-family/saas.jpg)
Web |
![](https://www.solvusoft.com/file-extensions/images/os-family/linux.jpg)
Linux |
Известные LOCK-файлы
2 существующих типов файлов используют это расширение
Процесс публикации пакетов
Некоторые разработчики полагают, что то, что публикуется в npm, является в точности тем, что хранится в git-репозитории, или тем, во что превращается проект после завершения работы над ним. На самом деле это не так. В процессе публикации пакета npm выясняет то, какие файлы нужно опубликовать, обращаясь к ключу files в файле package.json и к файлу .npmignore . Если же ничего из этого обнаружить не удаётся — используется файл .gitignore . Кроме того, некоторые файлы публикуются всегда, а некоторые никогда не публикуются. Узнать о том, что это за файлы, можно здесь. Например, npm всегда игнорирует папку .git .
После этого npm берёт все подходящие файлы и упаковывает их в файл tarball , используя команду npm pack . Если вам хочется взглянуть на то, что именно упаковывается в такой файл, можете выполнить в папке проекта команду npm pack --dry-run и посмотреть на список материалов в консоли.
Результаты выполнения команды npm pack --dry-run
Затем полученный файл tarball загружается в реестр npm. При запуске команды npm pack --dry-run можно обратить внимание на то, что если в проекте есть файл package-lock.json , он в tarball-файл не включается. Происходит это из-за того, что этот файл, в соответствии с правилами npm, всегда игнорируется.
В результате получается, что если кто-нибудь устанавливает чей-нибудь пакет, файл package-lock.json в этом участвовать не будет. То, что имеется в этом файле, который есть у разработчика пакета, не будет учитываться при установке пакета кем-то другим.
О файлах блокировки
Наша цель - помочь вам понять, что такое файл с суффиксом * .lock и как его открыть.
Все типы файлов, описания форматов файлов и программы, перечисленные на этой странице, были индивидуально исследованы и проверены командой FileInfo. Мы стремимся к 100% точности и публикуем информацию только о тех форматах файлов, которые мы тестировали и проверяли.
Если вы хотите предложить какие-либо дополнения или обновления на этой странице, пожалуйста, сообщите нам об этом.
Расширение файла LOCK включает в себя два основных типов файлов и его можно открыть с помощью Mozilla Firefox (разработчик — Mozilla). В общей сложности с этим форматом связано всего четыре программное (-ых) обеспечение (-я). Чаще всего они имеют тип формата Lock File. Большинство файлов LOCK относятся к Uncommon Files, однако они также могут относится к Game Files.
Расширение файла LOCK поддерживается Windows, Mac и iOS. Данные типы файлов можно найти в основном на настольных компьютерах и некоторых мобильных устройствах. Рейтинг популярности данных файлов составляет «Низкий», что означает, что они не очень распространены.
Если у вас возникли проблемы с открытием файлов LOCK, или если вы просто хотите узнать больше о связанных с ними программах и разработчиках см. полную информацию, представленную ниже.
Распространенность
Позиция
Режим
Редактировано
FileViewPro открывает файлы LOCK
Тип файла 1Lock File
разработчик | N / A |
популярность | 4,2 (78 голосов) |
категория | Разные файлы |
Формат | Текст и Двоичный X |
Текст и Двоичный
Этот файл сохраняется в текстовом формате или в двоичном формате. Если в текстовом формате, его можно просмотреть в текстовом редакторе.
Итоги
Многое из того, о чём мы тут говорили, полагается на особенности выполнения различных операций средствами npm. Речь идёт об упаковке, публикации, установке пакетов, о работе с зависимостями. А если учесть то, что npm постоянно развивается, можно сказать, что всё это в будущем может измениться. Кроме того, возможность практического применения приведённых здесь рекомендаций зависит от того, как разработчик пакета воспринимает проблему использования различных версий зависимостей в разных средах.
Надеемся, этот материал помог вам лучше разобраться в том, как устроена экосистема работы с зависимостями в npm. Если вы хотите ещё сильнее углубиться в этот вопрос — здесь можно почитать о различиях команд npm ci и npm install . Тут можно узнать о том, что именно попадает в файлы package-lock.json и npm-shrinkwrap.json . Вот — станица документации npm, на которой можно узнать о том, какие файлы проектов включаются и не включаются в пакеты.
Всем привет! В прошлом посте мы рассмотрели экосистему npm в качестве источника хаоса в нашем проекте, и научились с умом подходить к выбору зависимостей, чтобы минимизировать наши риски. Сегодня мы пойдем дальше и рассмотрим lock-файлы npm, которые помогают повысить стабильность проекта в процессе работы над ним.
Как мы уже определили, npm берёт на входе манифест проекта (файл package.json) и описанные в нем зависимости, а на выходе мы получаем локально сгенерированную директорию node_modules , в которой содержатся все установленные зависимости.
Не будем сейчас касаться деталей структуры node_modules , однако замечу, что установленные пакеты не всегда имеют плоскую структуру, а могут в отдельных случаях формировать некую иерархию, когда один или несколько пакетов вложены в другой пакет. Как правило, это происходит, когда в дереве зависимостей присутствует один и тот же пакет, но разных версий. При этом сама структура в файловой системе не детерминирована на 100 %, и может зависеть, в том числе, от порядка установки зависимостей.
Также разные версии npm могут иметь различные алгоритмы установки зависимостей, и структура файлов будет отличаться.
Вы помните, что список зависимостей в манифесте проекта содержит диапазон версий semver, что позволяет обновлять зависимости? Получается, что установка зависимостей в разное время будет приводить к разным результатам, потому что содержимое npm registry постоянно меняется, регулярно выходят новые пакеты. Кроме того, поскольку мы имеем дело с деревом зависимостей, то транзитивные зависимости (зависимости ваших зависимостей) тоже будут меняться во времени.
А еще может возникнуть ситуация, когда содержимое пакета, лежащего в npm registry, было заменено без обновления версии. Это называется мутацией пакетов и запрещено в официальном npm registry, однако в частных реестрах вполне возможно. А что, если содержимое пакета было заменено злоумышленником, чтобы внести в код какие-то закладки?
Учитывая все эти факторы, становится очевидно, что структура данных в директории node_modules очень нестабильна и может меняться во времени, даже если ваш манифест при этом остается нетронутым.
Наивно было бы попытаться зафиксировать зависимости, прописывая строгие версии в манифесте проекта (вместо диапазонов semver): как мы рассмотрели выше, это не даст существенных результатов, потому что транзитивные зависимости всё равно будут обновляться. Да и другие факторы не перестанут влиять на установку зависимостей. Кроме того, если вы заморозите ваши прямые зависимости, то получится ситуация, когда более старые версии будут работать с более свежими версиями транзитивных зависимостей, и потенциально это повышает вероятность проблем с интеграцией.
А теперь представьте, что у нас в проекте есть конвейер CI/CD и специальный сервер, который собирает, тестирует и выкатывает приложения в разные среды выполнения. Как правило, такие решения привязываются к ID коммита в Git (или к Git-тегам), и на каждый коммит система генерирует готовый к выкатке артефакт (архив с готовыми для выполнения файлами). Таким образом, на вход конвейера поступает код из Git-репозитория, версионированный через ID коммита, а на выходе вы получаете протестированный и готовый к выкатке артефакт. В идеале, это должно работать как чистая функция (pure function): если вы пересоберёте коммит, созданный несколько месяцев назад, то должны получить на выходе тот же самый артефакт. Однако мы не можем хранить содержимое node_modules в Git, и получается, что после клонирования репозитория нам необходимо вызывать установку зависимостей из реестра npm. А, как мы уже выяснили, этот процесс довольно нестабилен и привязан к глобальному состоянию экосистемы (содержимому npm registry, версиям npm и т. д.). Получается, что npm вносит хаос в наш конвейер CI/CD и мы уже не можем получить одинаковую сборку по ID коммита.
Чтобы предотвратить все описанные выше проблемы и сделать использование зависимостей гораздо более стабильным, npm (как и любой другой современный менеджер) предлагает специальный механизм заморозки зависимостей. Работает это автоматически и прямо из коробки: впервые вызывая команду npm install , npm не только устанавливает все зависимости и создаёт директорию node_modules , он также создает специальный файл package-lock.json . Этот файл называется lock-файлом и содержит в себе полную информацию обо всех установленных зависимостях, включая их точные версии, URL npm registry, из которого был скачан пакет, а также SHA-хэш самого архива с пакетом. Помимо прочего, lock-файл npm описывает еще и порядок установки зависимостей, и их вложенность в файловой системе.
При повторном вызове команды npm install менеджер пакетов увидит, что lock-файл содержится в директории проекта, и в дальнейшем зависимости будут устанавливаться в полном соответствии с информацией из lock-файла. Таким образом, вы можете вызывать команду npm install сколько угодно раз на любой машине и в любое время (даже спустя месяцы), и на выходе будете получать одинаковую структуру файлов в директории node_modules . Также стоит заметить, что установка зависимостей через lock-файл осуществляется быстрее, потому что npm не нужно сверять диапазоны зависимостей из манифеста с данными, доступными в реестре npm. Даже если версия npm обновится и алгоритм установки зависимостей поменяется, lock-файл всё равно будет гарантировать точный и стабильный результат, потому что файл, по сути, описывает результат работы алгоритма на основе входных данных. В каком-то смысле эта концепция аналогична кэшированию.
Чтобы использовать преимущества lock-файла, его необходимо добавить в систему контроля версий. Таким образом, вы строго привяжете полное дерево зависимостей к коммитам в Git. Это будет гарантировать стабильное воспроизводство сборок в вашей системе CI/CD и позволит надежно «путешествовать во времени».
Кроме того, каждый разработчик, который склонирует Git-репозиторий к себе на машину, получит точно такое же дерево зависимостей, как и у вас. Это устранит известную проблему из разряда «странно, а у меня всё работает» (“it works on my machine”).
Npm генерирует lock-файл полностью автоматически на основе данных из манифеста проекта, глобального состояния npm registry и алгоритма установки зависимостей npm. Однако содержимое файла вполне читаемо человеком и может быть использовано даже на этапе code review. Diff lock-файла покажет, какие зависимости в дереве были обновлены, какие были удалены, а какие добавлены. Наверное, нет смысла изучать изменения этого файла при каждом обновлении, но при обнаружении каких-то деградаций это может сильно помочь в поиске виновного пакета и сэкономить вам кучу времени. Но чтобы это работал эффективнее и размер изменений был минимальным, я рекомендую обновлять зависимости как можно чаще (гораздо проще выявить проблему, если у вас обновилось три пакета в дереве зависимостей, а не сотня).
Давайте теперь рассмотрим содержимое файла package-lock.json в тестовом проекте, где установлена только одна зависимость — express .
Оригинальный файл содержит почти 400 строк, но чтобы пример получился достаточно читабельным и наглядным, я показал только часть дерева зависимостей.
Читайте также: