В настоящее время разработка программного обеспечения с использованием пакетов стала стандартной практикой в самых популярных языках программирования. Существуют различные менеджеры пакетов, такие как Maven, Composer, npm и другие, которые помогают управлять зависимостями проектов путем кэширования зависимостей в операционной системе (например, в папках ~/.cache/composer/repo/
или ~/.npm/
). Обычно проекты хранят свои зависимости внутри своей файловой структуры, например, в папках ./node_modules/
или ./vendor/
. Если два проекта на одном компьютере используют одну и ту же зависимость, то обычно эта зависимость будет присутствовать в трех экземплярах: в файлах первого проекта, в файлах второго проекта и в кэше менеджера.
Клиентская часть веб‑приложений работает внутри браузера, и для нее браузер играет роль своего рода «операционной системы«. Существует множество популярных библиотек, таких как jQuery, Lodash, Three.js и другие, которые широко используются множеством веб‑сайтов и веб‑приложений. Поскольку клиентская часть часто собирается с помощью бандлеров, таких как Webpack, эти библиотеки многократно кэшируются браузерами. Ресурсы, такие как unpkg.com и jsdelivr.com, в некоторой степени помогают уменьшить дублирование, поскольку если несколько сайтов ссылается на один и тот же ресурс на unpkg.com, то все они будут использовать один и тот же объект из кэша браузера.
Учитывая, что основным языком программирования для фронтенда в веб‑приложениях является JavaScript/TypeScript, у которого есть собственный формат пакетов (package.json
), и что сборщики бандлов для фронтенда используют эти пакеты для формирования клиентской кодовой базы, возникает вопрос: почему бы не хранить npm‑пакеты (или хотя бы транспилированные значимые объекты кода) прямо в браузере, учитывая версионность и другие свойства, присущие пакету? Таким образом, можно было бы ссылаться на зависимости и их версии в каком‑нибудь «манифесте веб‑приложения«, вместо использования ссылок на unpkg.com/:package@:version/:file. Браузер мог бы автоматически загружать необходимые пакеты, если они еще не находятся в локальном хранилище, и предоставлять доступ к соответствующим файлам внутри пакета веб‑приложению или странице.
Мне кажется, что это весьма вероятный вектор развития веб‑разработки. Пакетные менеджеры уже доказали свою полезность в серверных приложениях, и этот опыт может быть применим и в браузерах. Возможно, этот функционал не появится уже завтра или послезавтра, но на мой взгляд, уже сейчас существует потребность в таком решении, иначе не было бы ресурсов, таких как unpkg.com.
Если у вас есть информация о движении в этом направлении, я буду очень признателен, если вы поделитесь этими данными в комментариях. Спасибо.