Что такое пакеты javascript? Как разработчик, я волей-неволей использовал пакеты в своем коде javascript, зная, что они что-то делают. Я смутно понимал, что эти пакеты позволяют различным библиотекам, которые я хотел включить в работу, фактически встраиваться в мой код. Я понял, что для включения этих пакетов в код требуется какой-то менеджер пакетов. Я даже знал, что мне нужно время от времени, как цветы в саду, ухаживать за этими пакетами, обновляя их — опять же через волшебный менеджер пакетов. Но что именно составляет индивидуальный пакет? Из чего он состоит? Почему сумасшедший мир javascript требует этих пакетов? Что, по сути, есть?

Пакет — это небольшой набор программного обеспечения и данных, хранящихся в архивных файлах как единое целое — пакет или пакет. Один пакет содержит основную информацию (метаданные), такую ​​как имя, номер версии, поставщик, описание и назначение. Пакет также обычно включает список всех зависимостей (зависимости: другие вещи, которые нужны пакету, которых у него нет), необходимых для запуска его программного обеспечения. Смысл пакета в том, что приложение может иметь повторно используемый блок или библиотеку кода, который не влияет на другие фрагменты кода. Пакеты, как правило, общедоступны, ими можно делиться через онлайн-репозитории, и часто они представляют собой повторно используемые фрагменты кода, которые разработчики могут включать в свои проекты.

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

Допустим, вы создаете проект, в котором необходимо установить пакет gandalf, чтобы сделать определенные разделы вашего проекта непроходимыми. НО пакет gandalf зависит от пакета hobbit и требует пакета gandalf-the-gray. Тем временем вашему проекту также требовался пакет aragorn, который имел зависимость gandalf-the-white, которая является другой версией gandalf-the-gray. Кроме того, для пакета aragorn также требовался пакет hobbit версии 4. Уже на этом простом примере зависимости, способ их взаимосвязи и версии каждого пакета, которые вам могут понадобиться, сошли с ума. (Забавный факт: вам понадобятся как gandalf-the-gray, так и grandalf-the-white, чтобы ваши пакеты gandalf и aragorn работали правильно)

К счастью, установка приличного менеджера пакетов позаботится обо всем этом за счет автоматизации с помощью простых обновлений команд и добавления дополнительных зависимостей. Кроме того, при работе над проектом в команде менеджеры пакетов помогают убедиться, что у всех установлена ​​одинаковая версия пакетов. Наконец, у большинства менеджеров пакетов даже есть простые автоматизированные инструменты, позволяющие создавать собственные пакеты! (например, создайте свой собственный пакет пряжи!)

Но пакеты и менеджеры пакетов не живут как независимые, свободные сущности в дикой природе, счастливо кормящиеся травой, пока они случайным образом не включаются в проекты. В конце концов, пакеты должны иметь возможность запускаться в вашей программе. В результате пакеты классифицируются по среде выполнения, для которой они написаны. Наиболее распространенной средой выполнения для проектов javascript является Node.js. (Есть и другие, но, поскольку Node является наиболее распространенным, в этой публикации в качестве основного примера будет использоваться Node.) Короче говоря, среда выполнения Node.js включает в себя все необходимое для выполнения и запуска. javascript-приложение. (Длинное объяснение потребует отдельного поста)

npm — это менеджер пакетов узлов, то есть он управляет пакетами узлов, т. е. пакетами, которые были созданы для совместимости с узлом и соответствуют структуре узла. Конечно, существуют и другие типы менеджеров пакетов, такие как yarn (похожий на npm и использующий тот же реестр и структуру, что и npm), deno, bower, gulp и т. д. Хотя все они управляют пакетами, способ, которым они это делают, немного отличается, и важно убедиться, что менеджер пакетов создан для типов пакетов, требуемых средой выполнения.

Где живут пакеты после их установки? Итак, теперь, когда у нас есть базовое представление о том, что такое пакет, что он делает и как им управлять — где эти вещи живут, когда они установлены в проекте?

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

Затем вы заметите, что после установки пакета не всегда очень очевидно, что было установлено, за исключением некоторых незначительных обновлений файла package.json. Если пользователь не указывает глобальную установку, менеджеры пакетов создают папку node_modules на корневом уровне, куда помещаются все файлы пакета. Если пакет устанавливается для использования в вашей программе, лучше всего установить его локально в корне вашего проекта. Это позволяет вам получить код пакета, который вам нужен, с помощью require(the stuff i need), import the stuff i need или import * from the stuff i need.. Но скажите, что вы хотите использовать что-то в своей оболочке или, может быть, в своем терминале в командной строке; здесь предлагается установить пакет глобально. В большинстве случаев рекомендуется локальная установка.

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