Разработчики Wasmer — рантайма для WebAssembly — представили пакетный менеджер WAPM.

WAPM расшифровывается как "WebAssembly Package Manager". Он состоит из двух частей: приложения командной строки wapm и реестра пакетов wapm.io. Цель нового пакетного менеджера — упрощение работы с модулями WebAssembly (запуск, распространение), поддержка разных видов ABI (WASI, Emscripten), простая интеграция с разными экосистемами языков (Python, PHP, Ruby, JavaScript). В разделе про NPM разработчики пишут про то, что WebAssembly на сервере — это совершенно новый сценарий использования технологии, поэтому при создании WAPM они решили отказаться от экосистемы JavaScript.

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

https://medium.com/wasmer/announcing-wapm-the-webassembly-package-manager-18d52fae0eea

#webassembly #package #announcement

Прочитал статью Мэтта Голдуотера про историю появления npm, yarn и pnpm — "An abbreviated history of JavaScript package managers". В статье рассказывается, почему у нас сейчас есть три конкурирующих менеджера, их плюсы и минусы.

Npm был стандартом де-факто, до появления yarn, в котором были исправлены проблемы со скоростью установки пакетов, была добавлена возможность offline-установки и предсказуемые сборки благодаря yarn.lock. Появление конкурента повлияло на развитие npm и уже в пятой версии в нём появились практически все возможности, которые на то время предоставлял yarn.

Летом 2017 года Золтан Кохан представил первую версию pnpm. В этом пакетном менеджере была решена проблема потребления дискового пространства и проблема прямого доступа к зависимостям зависимостей. Первый пункт стал киллер-фичей нового менеджера, что в свою очередь побудило разработчиков yarn реализовать своё решение для сокращения объёма хранящихся зависимостей — Yarn Plug'n'Play (Yarn PnP), который будет включён по умолчанию во второй версии yarn. Разработчики npm пошли дальше и представили новый пакетный менеджер — tink, в котором установка пакетов (то есть использование команд npm install some-package ) становится не нужна благодаря использованию особого механизма резолвинга зависимостей, который при необходимости автоматически устанавливает пакеты в общее хранилище.

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

#package #history #js #npm

https://medium.com/javascript-in-plain-english/an-abbreviated-history-of-javascript-package-managers-f9797be7cf0e

Недавно вышел Yarn 2. Джэмон Холмгрен из Inifinite Red поделился, к чему пришла команда после оценки перехода c первой версии Yarn на вторую версию и NPM — "Yarn 1 vs Yarn 2 vs NPM".

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

Краткие итоги статьи. По уровню поддержки победили Yarn 1 и NPM — Yarn 2 не поддерживает React Native; для них это было критично. По скорости установки пакетов победил Yarn 1. С утилизацией кеширования не было замеров, но разработчики утверждают, что Yarn 1 потребляет меньше траффика по сравнению с NPM. Также Yarn 1 распространён среди сообщества React/React Native. Многие дополнительные фичи, которые предоставляет Yarn 2 некритичны для их проектов. Мне показалось сомнительным, что в пункте про надёжность и предсказуемость NPM немного уступил Yarn 1 из-за статьи 2018 года. После оценки команда решила остаться на Yarn 1.

Рекомендую почитать статью, если вы тоже задумываетесь о переходе на новый пакетный менеджер.

#package #yarn #npm #comparison

https://shift.infinite.red/yarn-1-vs-yarn-2-vs-npm-a69ccf0229cd

Кроме npm и yarn существует ещё другой малоизвестный пакетный менеджер — pnpm. Эндрю Спрус написал статью "Why we switched from Yarn to pnpm", в которой рассказал, почему они для своего проекта выбрали именно pnpm.

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

После оценки возможных решений с помощью yarn 2, lerna и pnpm решили остановиться на последнем варианте. Он позволяет устанавливать пакеты рекурсивно и выполнять работу над подгруппой пакетов с помощью флага --filter.

Интересная статья. Кстати, там упоминается, что pnpm используют в Microsoft.

#package #js

https://www.takeshape.io/articles/why-we-switched-from-yarn-to-pnpm/

Кристоф Наказава из Facebook поделился большим количеством советов, которые помогли уменьшить размер зависимостей React Native на порядок — "Dependency Managers Don’t Manage Your Dependencies".

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

В статье рассказывается о том, как быстро найти тяжёлые пакеты, как выстроить процесс добавления новых пакетов в проект с отслеживанием их размера, как избежать проблем с устареванием зависимостей и т.п. Также в статье рассказывается про утилиты, которые полезно использовать при работе с зависимостями. Например, для поиска и удаления дубликатов можно использовать yarn-deduplicate, для поиска неиспользуемых зависимостей — depcheck.

#yarn #package

https://cpojer.net/posts/dependency-managers-dont-manage-your-dependencies