#фишка дня

TIL что в CodePen можно просто бросать файлы и он их подхватит. Подумалось, а нет ли возможности извлекать разметку, стили и скрипты из локальных файлов и забрасывать их в CodePen максимально автоматизированно?

Так вот, есть! Утилита буквально называется codepen-prefill и создана именно для этой цели: https://github.com/yuanchuan/codepen-prefill

npx codepen-prefill index.html

Извлечёт все встроенные стили и скрипты из файла и закинет их в окно редактора. Останется лишь сохранить.

👉 @htmlshit
#codepen #npm #npx #utility

#фишка дня

TIL что в CodePen можно просто бросать файлы и он их подхватит. Подумалось, а нет ли возможности извлекать разметку, стили и скрипты из локальных файлов и забрасывать их в CodePen максимально автоматизированно?

Так вот, есть! Утилита буквально называется codepen-prefill и создана именно для этой цели: https://github.com/yuanchuan/codepen-prefill

npx codepen-prefill index.html

Извлечёт все встроенные стили и скрипты из файла и закинет их в окно редактора. Останется лишь сохранить.

#codepen #npm #npx #utility

#тред дня

Задержался с постом, релизил обновление продукта. Ух у юзеров будет бомбить, изменение уровня ribbon в MS Office.

Да, почти никакого автопостинга, с пылу с жару, цените, мои дорогие 😙

Итак, тут Андрей Ситник в очередной раз поднял тему безопасности npm-пакетов. Думаю, нелишним будет и тут сохранить. Далее слово автору с незначительной редактурой:

Угон пакета и вставка вредоносного кода — риски большинства пакетных менеджеров.

В npm при деплое можно снизить риски и ускорить деплой:

npm install --production --ignore-scripts

--production не будет ставить devDependencies, --ignore-scripts выключит postinstall-скрипты.

Использование --production при деплое, значит что вам более системно надо разделять dependencies (только что нужно для сборки) и devDependencies (всё остальное).

Но так даже лучше — при обновлении зависимостей сразу понятны риски (обновления devDependencies менее опасно).

TS и файлы типов не нужны для компиляции .ts в .js — swc и babel умеют отрезать типы.

Поэтому и для фронтенд-проекта и для nodejs-сервиса tsc и типы должны быть в devDependencies.

Проверка типов должна идти как тесты в отдельном задании.

Для nodejs-сервиса в dependencies записываются только те зависимости, что нужны для запуска сервера (а не его компиляции).

Отдельным заданием ставятся все зависимости и собирается JS-файлы. А внутри docker-образа сервиса установка только с --production.

#npm #yarn #pnpm #node #security

#заметка дня

Заменили уже node-sass в своих проектах на sass?

Нет? А чего ждём?

Чем больше в компании людей на Apple M1, тем веселее становится поддержка проектов, использующих node-sass (libsass, сиплюсплюсовая реализация): он компилируется нормально только когда Меркурий в ретрограде. Или если не дышать.

А ещё оно deprecated уже года полтора: https://sass-lang.com/blog/libsass-is-deprecated

Сегодня набралась критическая масса таких людей у нас, поэтому я дропнул node-sass в пользу sass (релизация, написанная на Dart, DartSass; не спрашивайте).

Заодно убрал normalize-scss в пользу modern-normalize, ибо старый normalize уже не нужен.

На Webpack 5 переходить не буду, уйду на Vite.

Обновляйтесь, котаны.

P. S. речь о node-пакетах. Оригинальный отдельный sass — он на Ruby, RubySass :)

#scss #m1 #yarn #npm

#новость дня

Народ, отложили волчистость, убрали руки от клавиатуры на минутку и срочно смотрим сюда: https://blog.reversinglabs.com/blog/iconburst-npm-software-supply-chain-attack-grabs-data-from-apps-websites

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

Как происходило внедрение? По опечаткам :) Регистрировались похожие на уже существующие пакеты имена. А дальше человеческая невнимательность делала своё чёрное дело.

Пройдите проверьте, нет ли у вас по-глупости чего-либо подобного. Сверьте названия, версии и хеши.

Будьте внимательны, котаны!

#js #npm #security

#статья дня

npm, Yarn 1, Yarn 2 или pnpm?

Знакомые слова? Если нет, это всё — менеджеры пакетов (библиотек и т. п.) node.js. И каждый из них имеет свои особенности и по поводу каждого из них всегда идут баталии.

На чём запускать новый проект? На что переводить старый? Что быстрее? Что меньше места на диске съест? Что безопаснее?

Итого, сегодня тема — сравнение менеджеров пакетов: https://blog.logrocket.com/javascript-package-managers-compared/

Ну и заодно её перевод на русский язык на Medium.

У нас пока Yarn 1 aka Classic, а что у вас, котаны?

#node #npm #yarn #pnpm

#фишка дня

TIL что в CodePen можно просто бросать файлы и он их подхватит. Подумалось, а нет ли возможности извлекать разметку, стили и скрипты из локальных файлов и забрасывать их в CodePen максимально автоматизированно?

Так вот, есть! Утилита буквально называется codepen-prefill и создана именно для этой цели: https://github.com/yuanchuan/codepen-prefill

npx codepen-prefill index.html

Извлечёт все встроенные стили и скрипты из файла и закинет их в окно редактора. Останется лишь сохранить.

#codepen #npm #npx #utility

#заметка дня

Заменили уже node-sass в своих проектах на sass?

Нет? А чего ждём?

Чем больше в компании людей на Apple M1, тем веселее становится поддержка проектов, использующих node-sass (libsass, сиплюсплюсовая реализация): он компилируется нормально только когда Меркурий в ретрограде. Или если не дышать.

А ещё оно deprecated уже года полтора: https://sass-lang.com/blog/libsass-is-deprecated

Сегодня набралась критическая масса таких людей у нас, поэтому я дропнул node-sass в пользу sass (релизация, написанная на Dart, DartSass; не спрашивайте).

Заодно убрал normalize-scss в пользу modern-normalize, ибо старый normalize уже не нужен.

На Webpack 5 переходить не буду, уйду на Vite.

Обновляйтесь, котаны.

P. S. речь о node-пакетах. Оригинальный отдельный sass — он на Ruby, RubySass :)

#scss #m1 #yarn #npm

#статья дня

Справочная статья от Вари Степановой об использовании GitHub Packages как альтернативе NPM Registry: https://varya.me/blog/publish-packages-on-github/

Пригодится на случай, если у компании уже есть не только, собственно, GitHub, но и приватные пакеты других видов непосредственно в Packages. А их много разных: https://docs.github.com/en/packages

Ruby, NPM, Docker, Apache Maven…

В общем, уютненько.

#npm #packages

#новость дня

Наконец-то в каталоге npm появилась возможность посмотреть код пакета! Даже с подсветкой.

Да-да, всегда можно было перейти на гитхаб и посмотреть там. Но зачем лишний клик, когда можно детектить говнокод не отходя от кассы?

Впрочем, к библиотеке на скрине понятие «говнокод» неприменимо 😉

#npm #node

#инструмент дня

С места в карьер: утилита qnm предназначена для поиска установленных пакетов в node_modules. Зачем?

Ну, как минимум, это офигенно быстрый способ просмотреть версии всех установленных лично и не очень лично модулей: https://github.com/ranyitz/qnm

Почему ремарка про "не очень лично"? Потому что какой-либо пакет может запросто тянуть за собой более старую или более новую версию некой утилиты, на которую вы так сильно опирались.

Почему-то меня в этом отношении очень раздражает emotion. Его тащат просто куда ни попадя, а у людей потом на CSS-in-JS аллергия...

Так или иначе, посмотреть, почему тот или иной модуль был установлен — это очень полезно.

Моя рекомендация!

#npm #node #package

#инструмент дня

С места в карьер: утилита qnm предназначена для поиска установленных пакетов в node_modules. Зачем?

Ну, как минимум, это офигенно быстрый способ просмотреть версии всех установленных лично и не очень лично модулей: https://github.com/ranyitz/qnm

Почему ремарка про "не очень лично"? Потому что какой-либо пакет может запросто тянуть за собой более старую или более новую версию некой утилиты, на которую вы так сильно опирались.

Почему-то меня в этом отношении очень раздражает emotion. Его тащат просто куда ни попадя, а у людей потом на CSS-in-JS аллергия...

Так или иначе, посмотреть, почему тот или иной модуль был установлен — это очень полезно.

Моя рекомендация!

#npm #node #package #бородач

#инструмент дня

С места в карьер: утилита qnm предназначена для поиска установленных пакетов в node_modules. Зачем?

Ну, как минимум, это офигенно быстрый способ просмотреть версии всех установленных лично и не очень лично модулей: https://github.com/ranyitz/qnm

Почему ремарка про "не очень лично"? Потому что какой-либо пакет может запросто тянуть за собой более старую или более новую версию некой утилиты, на которую вы так сильно опирались.

Почему-то меня в этом отношении очень раздражает emotion. Его тащат просто куда ни попадя, а у людей потом на CSS-in-JS аллергия...

Так или иначе, посмотреть, почему тот или иной модуль был установлен — это очень полезно.

Моя рекомендация!

#npm #node #package #бородач

#инструмент дня

С места в карьер: утилита qnm предназначена для поиска установленных пакетов в node_modules. Зачем?

Ну, как минимум, это офигенно быстрый способ просмотреть версии всех установленных лично и не очень лично модулей: https://github.com/ranyitz/qnm

Почему ремарка про "не очень лично"? Потому что какой-либо пакет может запросто тянуть за собой более старую или более новую версию некой утилиты, на которую вы так сильно опирались.

Почему-то меня в этом отношении очень раздражает emotion. Его тащат просто куда ни попадя, а у людей потом на CSS-in-JS аллергия...

Так или иначе, посмотреть, почему тот или иной модуль был установлен — это очень полезно.

Моя рекомендация!

#npm #node #package #бородач

#новость дня

Как вам такое: взломать npm, получить доступ к пулу пакетов, которые скачивают по два миллиарда раз в неделю и всё ради чего? Ради призрачного шанса попасть в UI какой-нибудь крипто или NFT-биржи и украсть эфирчик-другой.

Звучит как плохая серия сериала Скорпион? А нет, это вот буквально вчера случилось. Да-да, я опоздал с новостью.

Итак, некто с помощью фишингового письма с требованием обновить 2FA-токены умудрился обмануть ментейнера нескольких пакетов для работы с командной строкой (chalk, например, чтобы эту самую строку красить. Очень полезно.) Джоша Джунона.

В такие моменты я понимаю, что рабочие тренинги по фишингу не настолько уж и тупые.

В выпущенные атакующими обновления пакетов был подставлен вредоносный код, выполняемый на системах пользователей, работающих с сайтами или приложениями, использующими скомпрометированные версии пакетов. Вредоносная вставка для браузеров осуществляла перехват трафика и активности Web API, прикрепляя свои обработчики к функциям fetch и XMLHttpRequest, а также вмешивалась в работу типовых интерфейсов криптокошельков для скрытой подмены реквизитов получателя при переводе. Подмена осуществлялась на уровне модификации значений в запросах и ответах, незаметно для пользователя (в интерфейсе пользователя показывались корректные реквизиты). Поддерживались форматы транзакций Ethereum, Bitcoin, Solana, Tron, Litecoin и Bitcoin Cash.

В общем, технические подробности и список пакетов есть тут: https://www.aikido.dev/blog/npm-debug-and-chalk-packages-compromised

Очень рекомендую проверить установленные версии даже если вы не держите у себя на сайтах кошельки и биржи. А если держите — тем более.

И вообще, котаны, проверяйте, откуда письма и их смысл. Вы прочитайте письмо с иллюстрации — ну курам на смех.

Впрочем, такое письмо может кого угодно застать врасплох, да.

#npm #security

#молния дня

По данным Aikido, в экосистеме npm снова обнаружена очередная атака на цепочку поставок.

Речь идёт о новом черве, который действует автоматически и был создан той же группой, что стояла за инцидентом в августе. Кажется, они прочитали комментарии к предыдущему посту: https://t.iss.one/htmlshit/3761

Схема атаки выглядела так: в репозиторий загружались вредоносные версии пакетов. При установке они собирали информацию из окружения и CI — переменные process.env, ключи облачных сервисов и другие секреты.

Эти данные выгружались в GitHub в репозитории с названием «Shai-Hulud». Параллельно добавлялись workflow в GitHub Actions, которые отправляли содержимое на внешний сервер (через webhook) и дублировали его в логи.

Если у жертвы находились npm-токены, вредоносный код автоматически модифицировал другие пакеты этого же мейнтейнера: версия повышалась, в package.json добавлялся вызов скрипта, а вместе с пакетом публиковался payload. В результате заражение распространялось дальше без участия человека. Кроме того, в некоторых случаях приватные репозитории переводились в публичный режим, что увеличивало масштаб утечек.

Проверьте свои машины на наличие червя:

find . -type f -name "*.js" -exec sha256sum {} \; | grep "46faab8ab153fae6e80e7cca38eab363075bb524edd79e42269217a083628f09"

Кстати, на сей раз снова началось с утилитки про цвета, @ctrl/tinycolor.

Чтобы снизить риски, рекомендуется фиксировать версии зависимостей, не обновляться сразу на latest, использовать lock-файлы (все же знают, что для CI запуск установки надо проводить с ключом фриза?) и инструменты проверки.

Отдельно стоит отметить, что pnpm уже предпринял шаги для сокращения таких рисков: некоторое время назад был удалён механизм postinstall-скриптов, который часто использовался злоумышленниками. А недавно появилась опция minimumReleaseAge, позволяющая задерживать публикацию новых версий на сутки или дольше. Это даёт время на анализ и позволяет заметить подмену до того, как пакет попадёт в продакшен.

Но любим мы pnpm не только за это.

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

#npm #security #attack