Изначально эта статья задумывалась, как рассказ о различиях и назначении полей dependencies, devDependencies и peerDependencies в package.json. Эту тему выбрали ребята в моем телеграм-канале, кстати подписывайтесь, если еще не. Однако, когда я посмотрел количество контента на эту тему, то понял, что его достаточно даже в русском сегменте. При этом я прочитал одну статью, которая показалась мне очень хорошей, а также там были мысли на тему будущего управления зависимостями.

В итоге, я решил кратко пересказать вышеупомянутую статью, чтобы лучше самому усвоить тему, а также набросать проект по управлению зависимостями прямо на клиенте, через ES Modules. Так что вы можете прочитать либо оригинальную и полную статью у автора, либо сокращенную версию в первой половине этой статьи. А разбор работы ESM будет во второй половине.

История развития управления зависимостями

В далекие времена, которые, я полагаю, уже многие забыли, не было NodeJS, поэтому библиотеки или скрипты подключали напрямую в HTML с помощью тэга script:

<script src="<URL>"></script>

На место <URL> необходимо поставить ссылку на js файл. Как правило, это была ссылка на CDN:

<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.6.1/jquery.min.js"></script>

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

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

Здесь на свет вышел Bower - пакетный менеджер, который автоматизирует загрузку библиотек. При этом все, что с его появлением требовалось хранить в репозитории с приложением -bower.json, который выглядит так:

{
  "name": "my-app",
  "dependencies": {
    "react": "^16.1.0"
  }
}

Здесь уже видно сходство с тем, что используется сейчас.

Достаточно было выполнить команду bower install и Bower установит все зависимости, что есть в dependencies. При этом использовать их в проекте можно было, как с помощью различных менеджеров задач по типу Grunt или Gulp, так и по старинке, через тег script:

<script src="bower_components/jquery/dist/jquery.min.js"></script>

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

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

Ключевым моментом в понимании работы любого пакетного менеджера является понимание работы разрешения (resolution) зависимостей. В момент установки Bower подбирает подходящие зависимости согласно полю dependencies, но так как появляются и транзитивные зависимости, то процесс разрешения становится рекурсивным и представляет собой обход дерева.

Тут же стоит отметить, что помимо dependencies с появлением Bower появилось и поле devDependencies. По префиксу dev понятно, что здесь указываются все зависимости, которые помогают нам в разработке, но не нужны в самом коде приложения, то есть различные библиотеки для тестирования, форматирования и т.п. Пакетный менеджер при установке загрузит только прямые devDependencies, а транзитивные проигнорирует:

При этом в Bower все загруженные зависимости будут лежать в одной директории в плоском виде:

При такой структуре растет риск конфликтов, которые могут возникнуть, когда зависимости проекта зависят от разных версий одной и той же библиотеки:

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

Для этой цели появилось поле resolutions:

{
  "resolutions": {
    "library-d": "2.0.0"
  }
}

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

NPM изначально имел nested модель разрешения зависимостей, то есть для каждой зависимости создается своя директория node_modules, где хранятся ее собственные зависимости, что позволяет избежать конфликтов.

Однако такой подход также имеет свои недостатки, а именно проблемы с дублями пакетов и глубиной иерархии. Поэтому при безответственном подходе вес директории node_modules мог стать колоссальным, а также можно было нарваться на ограничение максимальной длины путей на Windows.

В итоге в NPM 3 перешли на hoisted модель разрешения, в которой менеджер пакетов старается расположить все пакеты на верхнем уровне. И только когда возникает конфликт версий, то создается отдельная вложенная директория node_modules для конкретного пакета, где и располагается конфликтующая зависимость.

Принцип этой модели заключается в том, что NodeJS при поиске зависимости проходит по всей директории node_modules снизу вверх, то есть «всплывает».

Когда шла речь о Bower были представлены dependencies и devDependencies, которые также присутствуют и в NPM. Однако в NPM есть еще ряд полей с зависимостями, которые также подробно описаны в оригинальной статье, что я упомянул в начале, и еще здесь. Поэтому я пробегусь кратко. К dependencies и devDependencies добавляются:

1. peerDependencies - этот тип зависимостей чаще всего используется для разработки библиотек. Яркий пример - это react-dom - это библиотека для работы с DOM, которая подразумевает, что вы в своем проекте будете использовать react. То есть react-dom не указывает явно, что ей нужен react, но почему? React может применяться в разных средах. Для front end разработки привычна связка react и react-dom, однако для для мобильной разработки react-dom не нужен, а нужен react-native. Таким образом peerDependencies указывает на связь, но не жестко, перекладывая ответственность за наличие нужной зависимости на разработчика.

2. bundledDependencies - предназначены для тех случаев, когда вы упаковываете свой проект в один файл. Это делается с помощью команды npm pack, которая превращает вашу папку в тарбол (tarball-файл). Таким образом все зависимости идут сразу с пакетом и менеджер пакетов уже не резолвит их.

3. optionalDependencies - эту директорию обычно используют для установки зависимостей, которые зависят от контекста. Например при различных сценариях CI/CD или операционной системы.

Однако про peerDependencies хочется добавить еще пару моментов. NPM 7 и выше уже автоматически будет устанавливать недостающие peerDependencies. При этом если версии буду конфликтовать, то установка упадет с ошибкой. Например следующая ошибка возникнет при попытке установить Storybook 6-ой версии в приложение с React 18:

Если запустить установку с флагом --force или --legacy-peer-deps, как подсказывает сам текст ошибки, то NPM будет работать как до NPM 7, но это может привести к проблемам с дубликатами.

Для решения подобных проблем в NPM по аналогии с Bower есть поле overrides, где можно решить эту проблему:

{
  "dependencies": {
    "react": "18.2.0"
  },
  "devDependencies": {
    "@storybook/react": "6.3.13"
  },
  "overrides": {
    "@storybook/react": {
      "react": "18.2.0"
    }
  }
}

Как я уже писал ранее peerDependencies, как правило, используются для разработки библиотек, которые требуют хост-библиотеку (в примере с react-dom react выступает хост-библиотекой). Однако некоторые библиотеки могут работать и без хост-библиотеки, то есть работать без нее в одном ключе, а с ней в другом. В таком случае зависимость от хост-библиотеки является опциональной и это также можно указать в package.json через поле peerDependenciesMeta:

{
  "peerDependencies": {
    "react": ">= 16"
  },
  "peerDependenciesMeta": {
    "react": {
      "optional": true
    }
  }
}

Однако не только NPM играет весомую роль в области управления зависимостями. Со временем появились аналоги: Yarn и PNPM. Они также внесли свой вклад и подтолкнули тот же NPM к развитию. Например, Yarn решил проблему возможности загрузить разные версии зависимостей в разный момент времени.

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

Для решения этой проблемы Yarn добавил lock-файл, который сохраняет результат процесса разрешения зависимостей, то есть сохраняет версии пакетов, что были установлены. В последствии, используя yarn.lock, Yarn просто установит зависимости по списку, пропустив этап их разрешения. Это делает этап установки предсказуемым и более быстрым.

NPM также использовал этот метод и добавил свой lock-файл, чтобы учитывать его как основной источник, необходимо провести установку через команду npm ci.

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

В свою очередь PNPM также решил еще одну проблему NPM, а именно проблему фантомных зависимостей. NPM использует hoisted модель разрешения зависимостей, когда все пакеты «всплывают» на самый верх, а только дубли пакетов с другими версиями остаются на месте. Это поведение дает не очевидный на первый взгляд эффект. Все пакеты, что «всплыли» становятся доступными для импорта в приложении, хотя они могут быть не указаны как dependencies в package.json.

А теперь представьте ситуацию, что вышел патч library-a, который уже не использует library-b. В этом случае приложение упадет, так как импорт library-b закончится ошибкой.

В NPM следить за этим можно с помощью ESLint-плагина, а PNPM в отличие от NPM и Yarn не пытается сделать структуру node_modules как можно более плоской, вместо этого он скорее нормализует граф зависимостей.

Пока что все, что мы видели больше напоминало дерево нежели граф. И действительно «nested» модель наиболее близка к структуре дерева, но по факту она просто дублирует зависимости, которые можно расположить в ориентированный ациклический граф.

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

После установки PNPM создаёт в node_modules директорию .pnpm, которая концептуально представляет собой хранилище ключ-значение. В этом файле ключом является название пакета и его версия, а значением — содержимое этой версии пакета.

Такая структура данных исключает возможность возникновения дубликатов. Структура самой директории node_modules будет подобна "nested"-модели из NPM, но вместо физических файлов там будут симлинки, которые ведут в то самое хранилище пакетов.

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

В версии NPM 9 появился флаг install-strategy, значение «linked» в нём включает подобную PNPM модель установки с симликами, но на текущий момент вышел уже NPM 10, а эта фича остается экспериментальной.

Будущее развития управления зависимостями

Сейчас все больше библиотек переходят с CommonJS-модулей на EcmaScript-модули. В частности моя предыдущая статья о переходе с Webstorm на Cursor появилась благодаря тому, что msw второй версии имеет одну проблему с Jest. Из-за этого я начал переход на Vitest, что в свою очередь вызвало переход с Webstorm на Cursor, так старый Webstorm не поддерживал Vitest.

Как вы надеюсь помните, что первая часть этой статьи - это более менее краткая выдержка из другой статьи, в которой автор также поделился тем, что ESM - это, на его взгляд, будущее управления зависимостями. С момента написания той статьи прошло уже больше года, поэтому мне стало интересно попробовать реализовать приложение не используя NodeJS и сборщики. И сейчас я поделюсь тем, что у меня вышло.

Раньше интерактивность приложению мы добавляли, подключая скрипты прямо в HTML. Поэтому, на мой взгляд, иронично, что постепенно все возвращается к тому, от чего давно ушли. Но не буду забегать вперед и начну рассказ по порядку.

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

1. How to use ESM on the web and in Node.js

2. Building a TODO app without a bundler

3. Developing Without a Build (1): Introduction

Вторая статья вызвала у меня наибольший интерес, так как там уже есть реализация приложения на ESM - классическое ToDo App, которое я и использовал, как пример. Также там вы найдете доклад 2019 года от Фреда Шотта, где он поднял вопрос почему нужны сборщики и нужны ли они вообще.

Основной посыл этого доклада, даже можно сказать ответ на вопрос: «Почему было бы здорово использовать ESM прямо на клиенте?» - это отказ от огромного инструментария. Только вспомните сколько часов за свою жизнь вы потратили на настройки того или иного сборщика или менеджера задач. К тому же не придется тратить время на саму сборку, что порой бывает утомительно. А также достигается идентичность окружения для разработки и прода.

С момента публикации этого доклада до выхода статьи прошло 5 лет. Изменилось ли что-то глобально за это время?

Нет.

NPM был создан для Node, Web нашел в свое время выход в виде сборщиков и развернуть эту машину очень трудно. Все библиотеки пишутся на CJS, а поддержку ESM добавляют не все. К тому же остались открыты еще ряд критических моментов:

1. Теряется возможность использовать такие инструменты как Typescript;

2. Нет возможности минифицировать код и использовать Tree-shaking;

3. Нет возможности использовать алиасы для импортов.

И на мой взгляд минусы пока перевешивают плюсы.

В любой случае, давайте рассмотрим как использовать ESM на примере старого доброго Lodash. Мы можем импортировать нужную нам функцию или всю библиотеку напрямую в любом js файле:

import get from "https://esm.sh/lodash-es@4.17.21/get.js";

Но вставлять подобный путь каждый раз накладно, поэтому рекомендуется использовать тэг script с типом importmap:

 <script type="importmap">
  {
    "imports": {
      "get": "https://esm.sh/lodash-es@4.17.21/get.js"
    }
  }
</script>

После чего в любом js файле можно будет использовать следующую нотацию:

import get from "get";

Рассмотрев, как работать с ESM, осталось выбрать ряд инструментов, которые потребуются для разработки. Я выбрал следующие:

1. preact - так как я пишу в основном на React;

2. htm - так как люблю jsx.

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

import { h, render } from 'https://esm.sh/preact';
import htm from 'https://esm.sh/htm';

// Initialize htm with Preact
const html = htm.bind(h);

const MyComponent = (props, state) => html`<div ...${props} class=bar>${foo}</div>`;
render(htm`<${MyComponent} />`, container);

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

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

Чтобы запустить его локально установите serve и выполните команду npx serve, находясь в директории проекта.

Начнем с index.html :

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Agify</title>
    <link
      href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/css/bootstrap.min.css"
      rel="stylesheet"
      integrity="sha384-QWTKZyjpPEjISv5WaRU9OFeRpok6YctnYmDr5pNlyT2bRjXh0JMhjY6hW+ALEwIH"
      crossorigin="anonymous"
    />
    <link
      rel="stylesheet"
      href="https://cdn.jsdelivr.net/npm/bootstrap-icons@1.11.3/font/bootstrap-icons.min.css"
    />
    <link href="styles/styles.css" rel="stylesheet" />
    <link rel="manifest" href="./manifest.json" />
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <script type="importmap">
      {
        "imports": {
          "preact": "https://esm.sh/preact",
          "preact/": "https://esm.sh/preact/",
          "htm": "https://esm.sh/htm",
          "bootstrap": "https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/js/bootstrap.esm.min.js"
        }
      }
    </script>
  </head>
  <body>
    <script type="module" src="js/App.mjs"></script>
  </body>
</html>

Здесь подключаем готовые bootstrap-стили, нужные библиотеки и модуль App.mjs, о котором и пойдет дальнейший рассказ.

import { render } from "preact";
import html from "./render.mjs";
import { Agify } from "./Agify/index.mjs";
import { Footer } from "./Footer/index.mjs";
import { Header } from "./Header/index.mjs";
import { Layout } from "./Layout/index.mjs";

const App = () => {
  return html`
    <${Layout} Header=${Header} Content=${Agify} Footer=${Footer} />
  `;
};

render(html`<${App} />`, document.body);

Здесь вызывается renderиз preact, который отрисует приложение. Обратите внимание на компонент App. Я набросал его схематично, чтобы показать синтаксис и способ передачи свойств в дочерние компоненты. Также отдельно стоит отметить функцию html, если перейдете в файл render.mjs, то увидите ту связку preact и htm, о которой я писал выше:

import { h } from 'preact';
import htm from 'htm';

export default htm.bind(h);

Все действительно очень близко к React. Правда так как jsx передается в функцию html jsx в виде строки, то в IDE нет подсветки. Для VS Code я обошел это через плагин lit-html. Lit - это еще одна библиотека, с помощью которой можно реализовать подобную задачу.

В модуле App.mjs отрисовывается компонент Layout, куда через свойства передаются ряд других компонентов: Header, Agify и Footer. Все кроме Agify отвечают за отображение соответствующих секций, а с Agify все немного интереснее.

Для тех кто не в курсе, я скопировал приложение Agify из моей другой статьи о Typescript Generics. Так что, если кому интересна реализация этого же приложения на React, то добро пожаловать в песочницу. А здесь давайте посмотрим на код компонента Agify:

import { useState } from "preact/compat";
import get from "get";
import html from "../render.mjs";

export const Agify = () => {
  const [value, setValue] = useState("");
  const [age, setAge] = useState("");
  const [loading, setLoading] = useState(false);

  const handleSubmit = (e) => {
    e.preventDefault();
    setLoading(true);
    fetch(`https://api.agify.io?name=${value}`)
      .then((res) => {
        return res.json();
      })
      .then((data) => {
        setAge(get(data, "age"));
      })
      .finally(() => {
        setLoading(false);
      });
  };

  const handleReset = () => {
    setValue("");
    setAge("");
  };

  return html`
    <div class="h-100 d-flex justify-content-center align-items-center agify">
      ${loading
        ? html`
            <div
              class="h-100 w-100 d-flex justify-content-center align-items-center agify-spinner-container"
            >
              <div class="spinner-border" role="status">
                <span class="visually-hidden">Loading...</span>
              </div>
            </div>
          `
        : ""}
      <div class="w-50 d-flex flex-column gap-3 agify-content">
        <h2 class="text-center agify-title">
          Estimate your age based on your first name
        </h2>
        <form class="agify-form" onSubmit=${handleSubmit}>
          <div class="input-group mb-3">
            <input
              aria-describedby="button-addon2"
              aria-label="Enter your first name"
              class="form-control"
              onChange=${(e) => setValue(e.target.value)}
              placeholder="Enter your first name"
              type="text"
              value=${value}
            />
            <button
              class="btn btn-outline-secondary"
              disabled=${!value}
              type="submit"
              id="button-addon2"
            >
              <i class="bi bi-search"></i>
            </button>
          </div>
          <div
            class="d-flex flex-column justify-content-center align-items-center gap-3 agify-result"
          >
            <h3 class="agify-result-title">
              Your age is:
              ${age ? age : html`<i class="bi bi-question-circle"></i>`}
            </h3>
            <button
              class="btn btn-secondary"
              disabled=${!age}
              type="button"
              onClick=${handleReset}
            >
              Reset
            </button>
          </div>
        </form>
      </div>
    </div>
  `;
};

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

Но интересно, что preact предоставляет нам возможность использовать уже знакомый многим API React, в данном случае useState, а также интересны примеры вложенного в условные операторы рендера html:

${age ? age : html`<i class="bi bi-question-circle"></i>`}

Подводя итоги, скажу, что, как и в 2019, как и в 2022, так и в 2024 году, сообщество не накопило достаточное количество удобных инструментов и подходов для реализации серьезных проектов без сборщиков. Приходится жертвовать слишком многим в пользу малого. Выбор инструментов — это компромисс между сложностью процесса сборки и производительностью + оптимизацией. Использование сторонних библиотек в приложении без сборки может оказаться затруднительным, если нет доступной версии ESM. К тому же я слишком люблю Typescript, чтобы отказаться от него.

Но в целом мне очень интересна мысль о том, что все ходит по спирали. И такой концепт приводит нас к тому, с чего все начиналось. Очень интересно узнать приведет ли.

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