Зачем нужен lock файл

Обновлено: 07.07.2024

Здравствуйте. Я сейчас буду говорить о файлах блокировки пакетных менеджеров.

Все, кто используют(-али) Debian и дистрибутивы, на нем основанные, встречали ответ APT/DPKG про то, что DPKG не может получить доступ к файлу блокировки. В таких случаях я удаляю файлы блокировки, но вам так делать не советую, так как говорят, что это рисково. Но я не про это.

Сегодня, удаляя файл блокировки, я подумал: а чего в нем хорошего? Ответа я на этот вопрос не нашёл. За время использования APT/DPKG я находил только плохое — невозможность запуска установки нескольких программ сразу. Нет, я не говорю про случаи, когда все через APT, я говорю про тот случай, когда устанавливается что нибудь в APT и что нибудь в DPKG. Или DPKG+DPKG.

И какие функции файл блокировки на себя берет, кроме невозможности запустить две копии DPKG параллельно?

Затем, чтобы у тебя БД не расколотило в клочья в момент установки.

В Gentoo можно только собирать параллельно, устанавливать же он будет точно также, с блокировкой.

невозможность запуска установки нескольких программ сразу

это фича, а не баг.

apt - обёртка над dpkg. Больше расстраивает, что во время установки пакетов даже поиском средствами apt пользоваться нельзя

в Gentoo их пакетный менеджер Portage позволяет устанавливать много программ сразу

Позволяет, но файл блокировки на определённых этапах установки пакета всё равно есть. Просто emerge ждёт (и сообщает об этом) пока блокировка снимется в промежутках между фазами установки разных пакетов, например, при установке файлов непосредственно в систему. Дальше параллельно отрабатывает.

Затем, чтобы у тебя БД не расколотило в клочья в момент установки

Это простите как?

В Gentoo можно только собирать параллельно

А ещё чтобы оно вдруг не начало собирать один пакет несколькими билдерами одновременно, превращая workdir в кашу.

Читай про concurrency.

Я слышал, что в Gentoo их пакетный менеджер Portage позволяет устанавливать много программ сразу.

Собирать можно в несколько потоков, устанавливается так же по очереди и с файлом блокировки.

Прочитал и не понял, на каком уровне это связано с файлом блокировки и разносом бд.

Как она может ращнестись, объясните, пожалуйста, понятным языком.

объясните, пожалуйста, понятным языком.

ты не можешь какать и блевать в унитаз одновременно так, чтобы не испачкаться. здесь так же.

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

Два человека заливают в одно ведро каждый своё, игнорируя присутствие друг друга. Один льёт селитру, второый сыпет марганец.

Или один пытается высушить тряпку, второй её постирать.

Только чтобы скачать пакет, я так понимаю

даже если так. Тебя не смущает, что несколько процессов dpkg могут ставить одинаковые пакеты, выполнять различные скрипты (pre/post) одновременно? Один распаковал и начал обработку дальше, а второй в это время потер работу первого.

Больше расстраивает, что во время установки пакетов даже поиском средствами apt пользоваться нельзя

Эм, что? Вот сейчас специально проверил: что apt list , что apt search прекрасно работают во всех трёх стадиях: при показе сводки и запросе подтверждения; при скачивании пакетов; при установке пакетов.

Собирать можно в несколько потоков

Проверил. Можно ёще и несколько emerge запустить, только логи вперемешку.

лоровские аналогии как всегда бесценны

Как она может ращнестись, объясните, пожалуйста, понятным языком.

Что они запишут на самом деле?

В Gentoo можно только собирать параллельно, устанавливать же он будет точно также, с блокировкой.

Ну вот. А в Debian не так.

И если ты поставил установку пакета, который очень медленно скачивается с одного репозитория (что-то Virtualbox вспомнился), то всё…

Неважно, что можешь успеть десять раз поставить крошечный git.

fornlr ★★★★★ ( 26.06.20 07:31:50 )
Последнее исправление: fornlr 26.06.20 07:32:06 (всего исправлений: 1)

Не знаю куда ещё проще, раз до этого было непонятно.

Мож сейчас умеет. А лет 5 назад apt-cache у меня не работал при обновлении системы, сообщая, что работает apt-get или что-то такое.

Ну качаются они всё же параллельно.

эта блокировка действительно говно. защищает она от одновременной установки и удаления одного и того же пакета, или установки 2х конфликтующих пакетов. Хотя по хорошему атомарными должны быть операции над каждым отдельно взятым пакетом, а не над всем процессом установки. Упомянутый emerge, а так же nix в этом плане хороши, но подойдут не всем

когда юзал дебиан, качал он последовательно, и был баш-скрипт apt-fast, который как раз и умел качать параллельно

SR_team ★★★★★ ( 26.06.20 07:50:44 )
Последнее исправление: SR_team 26.06.20 07:52:45 (всего исправлений: 2)

apt install virtualbox

То всё, мне только идти гулять, если я захочу поставить git.

download-only и лок файл не берется :-)

И что мешает делать apt install virtualbox git ?

потому что всем влом распилить систему установки на более мелкие атомарные фнкции и правильно продумать алгоритмы их взаимодействия. это надо думать писать лишний код и допиливать его до рабтоспособного состояния.
учитывая что одновременный запуск нескольких установок явление достаточно редкое.
предложи реализацию и пропихни в продакшен.

потому что всем влом распилить систему установки на более мелкие атомарные фнкции и правильно продумать алгоритмы их взаимодействия. это надо думать писать лишний код и допиливать его до рабтоспособного состояния.

А еще надо придумать адекватное обоснование зачем это может быть нужно. Установка и обновление у тебя идет не 24/7, так что смысла делать бесполезную работу просто нет. И так сойдет.

Composer является стандартом де-факто для управления зависимостями в PHP. Он прост, эффективен и уже стал вездесущ.

Каждый знает, что при использовании Composer вы просто создаёте файл composer.json со списком зависимостей и их версий, а после запускаете composer install и всё готово.

Потом вы коммитите composer.json в ваш проект и каждый разработчик вашей команды может легко установить все небходимые зависимости запустив composer install .

Конечно мы знаем и про composer update , которая обновит установленные пакеты до последний версии (опираясь на указанные версии в composer.json ).

Это действительно просто. Но как насчёт файла composer.lock , который генерируется в корне проекта? Зачем ? И что нам с ним делать ?

А действительно ли вы знаете где находится .lock файл ?

Некоторое время назад я узнал, что проект OpenCFP не хранит файл composer.lock в репозитории. "Ну и что?!" - скажете вы, - “просто запускаем composer install и всё отлично. У нас установятся те же зависимости, верно?”

Предназначение .lock файла - записать в него непосредственно те версии, которые были установлены и под которые велась разработка и тестирование, чтобы в дальнейшем можно было их переустановить. Это означает, что если у вас в composer.json указана версия 1.* , а ваш коллега запустил composer update , которая установила 1.2.4 и закоммитил файл composer.lock , то вы, запустив composer install , получите ту же 1.2.4, даже если 1.3.0 уже вышла. Это позволяет быть уверенным, что каждый, кто работает над вашим проектом будет иметь абсолютно одинаковые версии пакетов.

Теперь вы может быть подумали: при надлежащем семантическом версионировании версия 1.3.0 (или даже 1.2.5) должна быть обратно совместимой, т.к. всё ещё удовлетворяет указанному значению 1.* и major-ная версия не изменилась. В чём же заключается сакраментальная мысль ?

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

Ещё достаточно рапространённая практика для проектов ставить в зависимостях ссылку на dev-master, что позволяет всегда иметь самые последние изменения. Это означает, что при каждом запуске composer install , но без сохранённого lock файла, composer будет устанавливать самый последний код библиотек, который будет напрямую с-pull-ен из их репозиториев.

Опять же, это проблема, если вы беспокоитесь о взломе вашего кода. И это одна из причин почему важно представлять Composer сфокусированным вокруг файла composer.lock . Это некое устройство безопасности и должно использоваться как таковое.

Install или Update?

Часто разработчики теряются когда они должны использовать install update . Как только вы начнёте думать об этом как о действиях с lock файлом, нежели как о зависимостях, всё встанет на свои места и будет более понятным.

Команда composer install делает следующее:

Проверяет существует ли composer.lock
если нет, резолвит зависимости и создаёт его
если composer.lock существует, устанавливает версии, указанные в нём

Команда composer update :

Проверяет composer.json
Определяет последние версии на основе указанных в этом файле
Устанавливает последние версии
Обновляет composer.lock в соответствии с установленными

В любом случае, после запуска любой из команд вы длжны закоммитить composer.lock в вашу систему контроля версий, чтобы быть уверенными, что вся команда имеет одну и ту же картину.

Есть одно исключение из правила. В том случае, если вы устанавливаете что-то вроеде Zend Framework 2 Skeleton App, зависимости должны быть обновлены как только вы установили подобный каркас. Это потому, что Skeleton App является эдаким мета-приложением (карксом-примером). Соответственно в этом случае вы захотите "подтянуть" последние версии зависимостей, которые станут отправной точкой для начала разработки. Поэтому composer.lock не коммитится в репозитории подобных мета-приложений.

Выкладка (deploy)

При deploy-е приложения, имея composer.lock в вашем репозитории, вы должны использовать команду composer install . Так мы будем уверены, что на production сервере используются те же самые версии пакетов, как и при разработке. А также это значит, что Composer-у не требуется выполнять разрешение зависимостей и искать требуемые версии, что увеличивает скорость разворачивания.

Наличие файла composer.lock также обеспечивает консистентность между кластерами серверов, если вы запускаете Composer отдельно на каждой машине. Это позволяет вам развернуть новые ноды(машины) неделями или месяцами позже, не беспокоясь о несовпадении версий зависимостей.

Заключение

Как вы видите, это всё о .lock файле. Если вы задумались какую команду использовать composer install или composer update , пусть .lock файл направит вас. Если вы ассоциируете эти команды с тем, как они работают с содержимым .lock файла (а не с зависимостями) вы никогда не ошибётесь.

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

В данной статье мы хотим познакомить вас с package lock и package json файлами. Разберемся, для чего необходимы lock файлы, при работе с npm.

Давайте начнём с npm (node-modules) - это сборщик пакетов в программной платформе node.js. Актуальную версию node.js можно скачать по ссылке. В основном предназначена для установки модулей. Для просмотра актуальных версий модулей npm создаёт файл package.json.

Что такое пакет в JavaScript?

Пакетом называется один или несколько файлов в JS, в виде инструмента или библиотеки. Npm хранит в себе самый большой набор пакетов. Npm необходим для скачивания пакетов и загрузки их, благодаря этому можно хорошо ускорить своё написание кода.

Что такое package.json?

Package.json - это файл, который представляет зависимости верхнего уровня от других пакетов при помощи семантического управления версиями. Любой пакет, может исходить из другого пакета, у них образуется взаимосвязь.

Package.json файл состоит:
1. Dependencies (зависимости) в которых хранятся названия и версия модуля
2. Метаданные - это описание, автор, лицензия и т.д.
3. Скрипты

Типы зависимостей в package.json

Давайте разберем несколько основных зависимостей проекта, чтобы лучше понимать что в него входит и что можно редактировать.
• dependencies — главные зависимости которые находятся в вашем проекте. Их можно применять и запускать в коде.
• devDependencies — взаимосвязи разработки.
• peerDependencies — равные взаимосвязи, при добавлении которых, мы даем понять какую версию для взаимосвязи следует установить
• optionalDependencies — второстепенные зависимости. Если при установке произойдет сбой, на основную сборку это не повлияет.
• bundledDependencies — в нём содержится массив пакетов. Данный массив нужен, если вам требуется добавить новую зависимость, которой нет в npm.

Назначение package-lock.json

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

Чтобы установить зависимости на основе текущего package-lock.json файла, вы должны использовать npm ci вместо npm install.

Используя, npm ci вы сможете избежать проблем, которые возникают, когда приложение работает на вашем компьютере, но не работает на чужом, потому что они в конечном итоге загрузили различные зависимости из-за использования npm install.
Вот почему при запуске ваших сборок на сервере непрерывной интеграции вам следует устанавливать зависимости, используя npm ci вместо npm install. Это приведет к тому, что сборка CI-сервера будет работать так же, как на вашем компьютере.

Назначение package.json

Как говорилось уже выше, файл package.json - один из основных частей проекта основан на Node.js. Многие уже встречали этот файл у себя в проектах, но открыв его - ничего не поняли, так и остался для вас “тёмным туманом”. Зачем использовать данный файл?

Package специализирован не только лишь на взаимосвязях, но и для определения свойств проекта:

Чтоб отключить автоматическое создания файла следует написать в npmrc package-lock=false. Наличие package-lock.json в проекте необязательно.

Разбивка параметров

name - параметр name обозначает имя создаваемого проекта. Имя не должно превышать 214 знаков. Запрещены пробелы, подчеркивания, дефисы и CAPS LOCK.
Зачем нужно столько ограничений? После создания пакета происходит генерация url страницы.
author - описание об авторе проекта. Может быть имя, фамилия. Может быть представлен в виде массива с указаниями соц. сетей.
contributors - люди, которые разрабатывали данный проект (массив)
bugs - Отслеживание багов в проекте, можно указать ссылку на GitHub трекер.
homepage - Главная страница пакета
version - Указывает текущую версию пакета.

Правила написания версии:
Первая цифра - это внесены критические изменения
Вторая цифра - обозначает, что выпуск содержит новые функции.
Третья цифра - указывает на исправления.

license - лицензия пакета
keywords - ключи(теги) для поиска вашего проекта. Чем лучше их задать, тем легче людям найти ваш пакет.
description - описание проекта. Если выкладывать в сеть, то данное описание обязательно!
repository - добавьте сюда git репозиторий пакета. Данное свойство содержит префиксы (gitlab:url, bitbucket:url)
main - Главная файл пакета
private - если значение true, то оно не даст загрузить набор в npm
scripts - скрипты, которые могут быть доступны через npm
dependencies - перечень установленных взаимосвязей
devDependencies - зависимости разработки
engines - показывает, какие средства и версии Node.js употребляться для работы пакета
browserslist - помогает показать, какие браузеры могут поддерживать пакет

Менеджеры версий

Существует несколько возможностей, разрешающих пользоваться многими версиями Node.js на вашем пк. Одна из них n, вторая - Node Version Manages(nvm). Кто искал данное решение, изучите информацию на ресурсах: Install Multiple Versions of Node.js using nvm.

Что из себя представляет расширение JSON

Формат JSON - это текстовый формат служит для обмена данными созданный на объектах JS. Данные в файле представлены в виде “ключ - значение”.

Как создать package.json?

Из-за того, что package.json довольно глобальный и состоит из множества свойств, то в ручную его писать трудно и очень долго. Для быстроты решения задачи, npm сделали команду init. Откройте консоль в области текущей папки и напишите команду: npm init. Данная команда позволяет создать файл package.json. После этого вы получаете вот такой ответ:

Затем после всех вопросов, в основном вы все пропускаете через Enter, мы получаем те самые данные в виде “ключ - значение”

Наш package.json создан!

Установка модулей

Для начала в своём проекте в консоли напишите команду
npm install

Данная команда установит файл node_modules(короткий вариант команды npm i). Вторым этапом мы установим какую-нибудь библиотеку. К примеру: gulp-sass - помогает скомпилировать код, и сжать стили. Для установки напишем команду
npm install gulp-sass --save

Если вам нужны еще библиотеки просто перечисляете их, отделяя отступом. Но не забывайте добавлять аргумент --save, для сохранения библиотеки как зависимость самого проекта.

Аргумент --save показывает npm следить за актуальной версией package.json. Хорошая возможность, дать другим разработчиком увидеть какие зависимости необходимы проекту.

По итогу у нас получились созданные файлы: package.json, package-lock.json, node_modules.

Сгенерированная папка node_modules хранит в себе все модули вашего проекта. Данную папку в Git репозиторий мы не добавляем! Так как в ней хранится множество зависимостей и они будут только добавляться, вы будете очень долго ждать загрузки. Загружать нужно только 2 файла package.json, package-lock.json, даже после того, как другой разработчик сделает копию вашего проекта, он сможет установить нужные зависимости сохраненные в package.json.

Не забудьте добавить файл node_modules в gitignore.

Заключение

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

Углубились в структуру файлов. Показали как установить node_modules, а также научились устанавливать дополнительные библиотеки.

В конечном итоге помните, что на git node_modules лучше не добавлять. И теперь любой скопированный проект вы сможете настроить сами, так, чтобы он работал.

Читайте также: