#фишка дня

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 #бородач