Прочитал интересную статью Джека Арчибальда про относительно недавний хак npm-пакета event-stream. В ней очень много дельных советов про то, как свести к минимуму подобные атаки и ликвидировать их последствия.

Чтобы вредоносный пакет не смог своровать ваши ssh-ключи с компьютера или что-нибудь натворить на сервере, используйте сандбоксинг с помощью Docker или обычную виртуальную машину во время разработки. С предотвращением атак на пользователей сайта, на котором работает вредоносный скрипт, всё гораздо сложнее. Для себя я выделил следующие моменты: аудит зависимостей тех приложений, которые работают с финансами, разделение процесса сборки на два этапа (“trusted”, “untrusted”) и подключение на сайт политик csp, чтобы минимизировать риски для атакованного пользователя.

Ещё в статье мне понравился интересный трюк с полной очисткой всех сохранённых сайтом данных (куки, кеши, localStorage, sessionStorage и т. п.) Для этого серверу достаточно отправить http-заголовок Clear-Site-Data: *, браузер почистит всё сам, но работает пока это только в Chrome и Firefox.

https://jakearchibald.com/2018/when-packages-go-bad/

#security #npm

Для меня было небольшим открытием, что на сайте npm есть semver-калькулятор.

Вводите в поле "pick a package" интересующий пакет, в поле "enter a range" диапазон версий и вуаля - зелёным цветом будут показаны все нужные версии.

В самом низу есть небольшая шпаргалка по тому, как задавать разные диапазоны версий. Удобно.

#npm #tool

https://semver.npmjs.com

В блоге NPM была опубликована статья, посвящённая проблемам безопасности при работе с зависимостями, — "AppSec POV on Dependency Management".

В статье рассматриваются подходы, которые могут снизить риск атаки. Первое, на что стоит обращать внимание при выборе пакета, метрики качества (наличие тестов, актуальные версии зависимостей и т.п.) Стоит посмотреть на активность поддержки пакета. Если версии выходят нерегулярно или последнее обновление выходило очень давно, есть риск, что пакет может попасть в руки злоумышленников. Именно это произошло с пакетом event-stream в прошлом году.

Есть пара советов, что делать при исследовании потенциально-опасных пакетов. Для безопасной установки можно использовать npm install --ignore-scripts. В этом случае скрипты установки не будут выполняться. Можно запустить npm audit для проверки наличия уязвимостей в зависимостях. Для того чтобы можно было запустить аудит без установки пакетов, следует использовать флаг --package-lock-only.

Статья очень толковая. Очень рекомендую почитать... Пойду-ка проверю зависимости в своих проектах.

#npm #security

https://blog.npmjs.org/post/187496869845/appsec-pov-on-dependency-management

Недавно в Node.js 13.2.0 появилась стабильная поддержка ECMAScript modules. Это событие можно считать началом "Великого исхода с CommonJS на ESM". Шучу. CommonJS будет продолжать жить и здравствовать, пока вся экосистема JS не перейдёт на нативную модульную систему. Тем не менее разработчикам библиотек теперь надо иметь в виду, что пакеты могут быть импортированы в CommonJS- и ESM. Какими способами можно поддержать оба окружения, Аксель Раушмайер рассказал в статье "Hybrid npm packages (ESM and CommonJS)".

Основным механизмом для создания гибридных пакетов будет новое поле exports в package.json, поддержка которого находится в экспериментальном режиме за флагом --experimental-conditional-exports. Благодаря ему один и тот же спецификатор импорта можно будет использовать как в CommonJS, так и в ESM. Логика работы exports похоже на switch-case. Символ точки используется для обозначения main:

{
  "type": "commonjs",
  "main": "./commonjs/entry.js",
  "exports": {
    ".": {
      "require":  "./commonjs/entry.js",
      "default": "./esm/entry.mjs"
    }
  }
}

Node.js поддерживает условия: require — для импортов из CommonJS, node — для Node.js, default — для всех импортов, не попавших под условие require и node. Другие платформы и инструменты могут поддерживать свои собственные условия, например: browser, electron, deno, react-native.

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

#esm #nodejs #npm

https://2ality.com/2019/10/hybrid-npm-packages.html

Прочитал статью Мэтта Голдуотера про историю появления 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

Сегодня во всех каналах прогремела новость — GitHub купил npm. В блоге GitHub появился пост Ната Фридмана о том, что это значит для сообщества — "npm is joining GitHub".

В ближайшем будущем усилия будут сфокусированы на инфраструктуре реестра. Также продолжается работа над седьмой версией npm — самая большая фича следующего релиза Workspaces (управление множеством пакетов из пакета верхнего уровня). Обещают активно сотрудничать с сообществом и ментейнерами пакетов — планируют расширить программу GitHub Sponsors на экосистему npm. Платные сервисы npm будут продолжать работать, но в этом году приватные пакеты npm можно будет переместить в GitHub Packages. Фокус в развитии npm смещается исключительно на публичный реестр.

Так как GitHub принадлежит Microsoft, это означает: что npm переходит под её крыло. Уж что-что, а инструменты для разработчиков Microsoft умеет делать хорошо.

#announcement #npm #github #microsoft

https://github.blog/2020-03-16-npm-is-joining-github/

25 апреля npm немного поштормило. Ошибка в пакете is-promise, привела к поломке трёх миллионов зависимых проектов. Форбс Линдсей — автор библиотеки — написал постмортем.

После добавления поддержки ESM новый файл index.mjs не был добавлен в секцию files в package.json. Также в секции exports идентификатор модуля был без префикса ./. Из-за опубликованного кода перестал работать require вида require('is-promise/index'), require('is-promise/index.js'), require('is-promise/package.json').

С момента публикации сломанной библиотеки до её полного фикса прошло четыре часа. Для предотвращения проблем в будущем был удалён .npmignore и добавлен прогон тестов для Node.js 12 и 14, также были добавлены тесты, использующие npm pack для проверки публикуемого API и настроена публикация пакетов из CI. Разработчики Node.js в свою очередь обновили документацию, уточнив, что package.exports должен явно включать в себя все необходимые точки входа.

#npm #postmortem #esm #nodejs

https://medium.com/@forbeslindesay/is-promise-post-mortem-cab807f18dcc

В постмортеме инцидента с is-promise одна из проблем была в конфиге, в который не был добавлен новый файл. Это случилось из-за того, что автора библиотеки запутало наличие файла .npmignore. Когда писал пост про постмортем, нашёл статью Джефа Дики про вред .npmignore — "For the love of god, don’t use .npmignore".

В npm есть два механизма для исключения попадания ненужных файлов в пакет: файл .npmignore (blacklist) и секция files в package.json (whitelist). По умолчанию npm игнорирует файлы, которые находятся в .gitignore, но при добавлении в проект конфига .npmignore .gitgnore перестаёт учитываться. Из-за этого нюанса у автора статьи утекли данные для аутентификации в S3, поэтому он рекомендует использовать только белый список файлов в package.json (явное лучше неявного). Но .npmignore может быть полезен, когда надо исключить раскиданные по проекту юнит-тесты __test__ / *.test.js и т.п.

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

#npm

https://medium.com/@jdxcode/for-the-love-of-god-dont-use-npmignore-f93c08909d8d

Айзек Шлутер опубликовал первую статью про изменения в следующей версии npm — "npm v7 Series - Introduction".

В первой статье Айзек делает обзор всех фич, которые будут доступны в седьмой версии. В ней будет улучшен процесс работы с пакетами. Будет добавлена поддержка воркспейсов и возможность переопределения пакетов. Будет упрощён вывод результата выполнения разных команд. Вывод npm audit в новой версии занимает гораздо меньше места, показывая только самую необходимую информацию. В кодовой базе был сделан большой рефакторинг, благодаря которому npm стал работать быстрее. Появится интеграция с yarn. Процесс установки пакетов будет учитывать yarn.lock. Yarn.lock также будет обновляться вместе с package-lock.json при добавлении в проект новых пакетов.

В следующих статьях про npm v7 будет более подробное описание работы всех новых фич.

#npm #announcement

https://blog.npmjs.org/post/617484925547986944/npm-v7-series-introduction

Гари Чу — devrel из Google — опубликовал статью про проблемы использования транспилированного кода в современных браузерах — "Bringing Modern JavaScript to Libraries".

На данный момент многие библиотеки из npm транспилируются в ES5. Это проблема, так как даже если проект не поддерживает legacy-браузеры, он должен "заплатить налог" в виде размера бандла. Этот налог для разных библиотек может быть как 7%, так и 40%.

В январе 2020 года в Node.js 13.7.0 появилась поддержка условных экспортов, с помощью которых можно указать разные сборки для разных типов окружений. Гари предлагает добавить новый тип окружения в условный экспорт для бандлов, которые транспилируются в ES2017 (один из возможных вариантов — browser2017 ). Предполагается, что бандлеры могут использовать это окружение для создания облегчённой версии бандла приложения. Также рассматривается вариант публикации кода без транспиляции, но в этом случае увеличится время сборки.

Очень полезное предложение. Думаю, что бандлеры адаптируют предлагаемый подход или как минимум придут к какому-нибудь другому альтернативному решению

#proposal #perfomance #npm

https://dev.to/garylchew/bringing-modern-javascript-to-libraries-432c

Сегодня вышла седьмая версия npm. Майлз Боринс рассказал про новые фичи релиза — "Presenting v7.0.0 of the npm CLI ".

В npm v7 была добавлена поддержка воркспейсов (workspaces). С их помощью добавляется возможность удобного управления вложенными пакетами из корневого пакета.

В новой версии peerDependencies будут устанавливаться автоматически. В npm v6 установщику не предоставлялась информация о peerDependencies, поэтому их надо было устанавливать самостоятельно.

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

Ломающие изменения: автоматическая установка peerDependencies; теперь нельзя зареквайрить внутренние модули npm; npx был переписан, в новой версии он работает поверх npm exec, что повлекло за собой разные изменения; изменился вывод команды npm audit.

Седьмая версия будет поставляться с Node.js v15 (выходит на следующей неделе) или её можно установить самостоятельно ( npm i -g npm@7 ).

#npm #release #nodejs

https://github.blog/2020-10-13-presenting-v7-0-0-of-the-npm-cli/

Лукас Ф. Коста — автор библиотеки Chai.js — написал статью про package-lock.json — "Why does package-lock.json exist, and how does it work?".

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

При запуске команды npm i установщик получает список зависимостей проекта из package.json и во время их установки обновляет package-lock.json, записывая туда полное дерево зависимостей с необходимой метаинформацей. Для установки пакетов из package-lock.json нужно использовать другую команду — npm ci. Эта команда устанавливает все зависимости, создавая идентичное дерево зависимостей на момент последнего выполнения npm i. Кроме детерминированности npm ci даёт очень хороший буст в скорости установки пакетов, поэтому чаще всего её используют в CI-системах.

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

#npm

https://lucasfcosta.com/2020/10/17/lockfile-guide.html

Алекс Бирсан — исследователь в области информационной безопасности — опубликовал статью о том, как ему удалось получить доступ к внутренним сетям 35 организаций — "Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies".

Из публичных источников (GitHub, ресурсы сайтов и т.п.) были собраны имена приватных пакетов, которые доступны только из внутренних сетей организаций. Для этих пакетов в публичных репозиториях (npm, PyPi, RubyGems) были опубликованы одноимённые пакеты. Из-за ошибки в конфигурации некоторые билд-системы начали скачивать и устанавливать пакеты из публичного репозитория. Таким образом Алекс получил доступ к внутренним сетям Apple, Microsoft, PayPal, Uber, Yelp.

После публикации статьи Microsoft выпустила документ с рекомендациями для предотвращения подобных ошибок в npm, yarn, NuGet Gallery, Pip, Gradle и Maven Central.

Советы для npm: используйте scoped packages, настройте npm так, чтобы в приоритете был приватный реестр, не удаляйте package-lock.json и используйте npm ci для установки зависимостей.

#security #npm

https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610
https://azure.microsoft.com/en-us/resources/3-ways-to-mitigate-risk-using-private-package-feeds/

Том МакРайт рассказал о своём подходе к работе с зависимостями — "Vendor by default".

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

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

#npm #js #musings

https://macwright.com/2021/03/11/vendor-by-default.html

Уменьшение размера npm-пакетов AWS SDK

Тривикрам Камат из Amazon написал статью про опыт уменьшения размера npm-пакетов — "How we halved the publish size of modular AWS SDK for JavaScript clients".

Тривикрам работает над JavaScript-версией AWS SDK, который используется в окружениях с жёсткими квотами, поэтому размер npm-пакетов играет важную роль. Для сокращения объёма устанавливаемого кода были удалены JSDoc-комментарии из JS- и d.ts-файлов, сгенерированных с помощью библиотеки downlevel-dts для старых версий TypeScript. Был удалён исходный TypeScript-код и сорсмапы. Для удобства отладки запланирован релиз специальной дебаг-версии пакетов.

Благодаря удалению лишнего кода размер пакетов уменьшился на ~50%.

#npm #optimization #typescript

https://aws.amazon.com/blogs/developer/how-we-halved-the-publish-size-of-modular-aws-sdk-for-javascript-clients/

Компроментация npm-пакетов coa и rc

В четверг были скомпрометированы npm-пакеты coa и rc. На первый пакет приходится 7 миллионов загрузок в неделю, на последний — 14 миллионов.

Во взломанных пакетах был размещён Windows-троян, который воровал сохранённые пароли, данные кредитных карт и т.п.

На данный момент вредоносные версии пакетов уже удалены, но специалисты по безопасности рекомендуют на всякий случай проверить в системе наличие вредоносных файлов: compile.js, compile.bat, sdd.dll. Для предотвращения подобных инцидентов npm советует включить двухфакторную аутентификацию.

#npm #security

https://www.bleepingcomputer.com/news/security/popular-coa-npm-library-hijacked-to-steal-user-passwords/

Преимущества хранения node_modules в git

Джек Франклин из команды разработки Chrome DevTools написал статью о том, почему они коммитят зависимости в систему контроля версий — "Why you should check-in your node dependencies".

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

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

#npm

https://www.jackfranklin.co.uk/blog/check-in-your-node-dependencies/

Cовременные возможности для работы с JavaScript-модулями

Аксель Раушмайер написал статью про современные возможности для работы с JavaScript-модулями — "Publishing and consuming ECMAScript modules via packages – the big picture".

Последние версии Node.js поддерживают package exports и package imports. Package exports используются авторами библиотек для настройки путей, по которым будет доступен импорт модулей. Package imports позволяют создавать альясы на пакеты или модули. Их можно использовать для подмены реализации модуля в зависимости от окружения. Package exports и package imports настраиваются в package.json.

В браузерах скоро появится поддержка import maps. С их помощью можно создавать альясы, относительно которых будут резолвиться спецификаторы модулей в браузере. Это полезно при доставке кода пользователям в чистом ESM, когда в названии файлов модулей есть хеши. Import maps уже используют в проде авторы почтового клиента hey.

#js #esm #nodejs #npm

https://2ality.com/2022/01/esm-specifiers.html

Ускорение установки зависимостей с помощью tnpm

На dev.to была опубликована статья разработчика Alibaba про ускорение установки зависимостей в Node.js — "In-depth of tnpm rapid mode - how we managed to be 10 second faster than pnpm".

Автор статьи занимается разработкой tnpm — проприетарного реестра JavaScript-пакетов и клиента, использующихся в проектах Alibaba.

Для ускорения процесса установки команда переделала архитектуру tnpm. В новом решении построение графа зависимостей пакетов происходит на сервере, значительно снижая количество HTTP-запросов на стороне клиента. Зависимости перед отправкой на клиент бандлятся в небольшое количество tar-файлов, улучшая утилизацию сети и уменьшая число обращений к диску. Полученные тарболлы не распаковываются, а лежат в хранилище, доступ к которому предоставляется с помощью npmfs — FUSE-модуля, реализующего кастомную файловую систему для работы с пакетами. Таким образом для пользователя и для Node.js ничего не меняется — они видят файлы, которые на самом деле лежат в запакованном виде. Использование FUSE накладывает ограничения на поддерживаемые операционные системы — на данный момент поддерживается только Linux.

Эти изменения позволили значительно улучшить скорость установки зависимостей, опередив в бенчмарке pnpm на 9 секунд. Автор пишет, что они планируют открыть исходный код npmfs в будущем.

Меня лично немного пугает получившийся монстр, но с точки зрения ускорения воркфлоу разработки — это очень интересное решение.

#npm #performance

https://dev.to/atian25/in-depth-of-tnpm-rapid-mode-how-could-we-fast-10s-than-pnpm-3bpp