Как же я кринжанул с этих ребят.
На страничке ts-node написано “Thus it is not recommended for production”. Плюс к этому в каждой второй статье где пишут про ts-node кричат “Не надо юзать в проде!”.

Эти же ребята запускали свое Node.js приложение через ts-node в проде. То есть компилировали все все файлики во время запуска приложения. А когда начали бандлить вебпаком, то получили ускорение старта в 80% и написали статью.

Наверное это очень хороший пример, почему все таки стоит прислушиваться к рекомендациям, они не просто так появились.

Залетаю с новым выпуском

https://anchor.fm/under-a-dome/episodes/ep-e1hpjch

Ссылки на ваши любимые сервисы можно найти тут: https://podcast.ru/1586738556

Я люблю таймлапсы. Особенно если удается запечатлеть прогресс.

Это мне помогает ощутить, что время потрачено не впустую, я что-то делал и тому, что сделал мало есть причины.

Вот небольшой таймлапс реализации темного режима в effector repl.

В общем и целом так проходят почти все мои разработки.
У кого похожим образом? Может кто в меня закинет свой таймлапс?

14 выпуск полезнейших статей уже отправлен
Остается лишь выбрать максимально интересные для вас и поставить лайк

Node.js 18, поиск утечек памяти, производительность React и SSR практики тестирования в Javascript и Rust!

https://news.sova.dev/issues/14-1119050

Выкладываю выпуск так

Причина, почему ZigLang сразу летит в помойку

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

https://news.sova.dev/issues/15-1139774

Решил продолжать выкладывать timelapse в отдельном месте.
Пока что буду вкидывать в группу в вк. Выглядит так, будто это очень специфичный контент

Перехожу в своих проектах на pnpm.
На чистой установке работает действительно быстрее, чем yarn1, yarn3 и npm.

Оказалось, что ничего не ломается, а в некоторых случаях работает корректнее. Потому что pnpm устанавливает в корень только зависимости из package.json, а зависимости зависимостей накатывает в отдельную директорию и их нельзя просто так require’нуть.

Это очень хорошо, ведь иначе в коде появляется неявная зависимость, версия которой не описана в package.json. Если какой-то пакет её обновит в своей минорной версии (или даже патч), в коде приложения что-то может отвалиться, хотя поведение пакета не поменялось.

Очень приятное следствие pnpm. Рекомендую

А теперь вопрос, который я анонсировал в рассылке.

У меня довольно часто случаются несколько кейсов в процессе поиска решений в коде или выработки своих собственных. Мне кажется их можно объединить в одном сервисе.

1. Сохранение актуальных решений
Я довольно часто гуглю как сделать то, как с делать это. Но всегда мне важны некоторые особенности, например платформа, где я выполняю действия или же версия конкретного софта.
Я хочу сохранить найденное решение куда-то себе в базу знаний/личную коллекцию и потом не потерять. С закладками проблема в том, что они легко устаревают, блоги падают, авторы меняют контент, иногда не указывают версию и платформу.
Фактически я просто пробую все подряд, пока не заработает. А в следующий раз начинаю поиск заново и снова пробую всё подряд.

2. Поиск по своей базе знаний
После того как я насохранял начинается вторая проблема. Если код я сохранил в gist, ссылки на ресурсы в закладках, а еще в закладках бывают примеры кода, где-то еще хочется приложить свои комментарии к ресурсу или статье, я получаю огромный размазанный набор данных.
Хочется иметь единое место, куда я могу легко сохранять все, что касается кодовых решений, но при этом с добавлением своих комментариев, версий софта, платформ и прочего важного.
Подобная база знаний должна иметь гибкий поиск: хочу найти всё связанное с prometheus, но с деплоем на heroku, написанное на javascript, с nodejs 18, но без nestjs. Я должен иметь возможность составить такой запрос и получить более менее актуальные результаты.

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

4. Полезное != популярное
Довольно часто в гугле или в других сервисах вверх результатов поиска поднимаются статьи с большим количеством лайков написанные популярными авторами. Но ведь это ничего не говорит о качестве контента или релевантности моему запросу.
Нужна какая-то более адекватная метрика полезности, нежели звездочки, лайки, популярность автора. Я не хочу, чтобы мне приходилось перелопачивать десятки популярных, но бесполезных для меня статей, прежде, чем я найду необходимое мне решение.

5. Персистентность
После того, как я нашел решение, я точно не хочу его потерять. Я хочу сохранить найденную статью в свою личную коллекцию и быть уверен, что она оттуда не пропадет. Даже если автор решил поменять контент или удалить её. Но при этом, я мог бы её актуализировать в любой момент, если увижу, что изменения мне подходят.
Сюда же хочется добавить возможность экспорта личной коллекции с сервиса целиком в любом открытом формате. Может быть работа оффлайн.

6. Краткость
Самый сложный пункт. Я крайне сильно не люблю статьи на сотни тысяч слов, из которых найти решение своего кейса очень тяжело. Когда автор расплывается на десятки абзацев рассказывая каждый аспект своей библиотеки. Мне нужно конкретное решение, выжимка всех идей автора в виде короткой карточки, с кодом, комментариями и релеватными ссылками.

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

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