Так не ты ли вчера позиционные аргументы с именованными удивлённо сравнивал? Сегодня уже спец по потокам? Во прогресс

Посмотри историю по сообщениям от моего лица, чего спрашивать?

Чтобы следующее сообщение о том, что в настоящее время новичкам следует при возможности стараться использовать асинхронные итераторы / генераторы, если не стоит задача разработки системного пакета для ноды, выглядело обоснованным

Выглядело потому что не буду участвовать в сраче)

И "обосновывать"

Тут как-то градус споров последнее время слегка неадекватный.

Про что и речь, цель была написать альтернативу, имеющий уши да услышит. Некорректно советовать новичкам кидать туториал для системных кодеров ноды. Список граблей по которым пройдется новичек в минимальном виде:
1) текст файла разбивается не по строкам, а как реализация пожелает
2) Чтобы зафиксировать положения разделителей от потока-трансформатора делящего как надо, нужно использовать objectMode, даже если все ещё строка.
3) Совершенно разные подходы к работе с потоками в одном месте. Неочевидно, что они несовсемы, и как точно не потерять данные
4) Попытка стандартизации в ядре ноды была признана как ошибка самими авторами

Ребят, а подскажите пжлст, как лучше всего организовать именование и хранение кастомных кодов ошибок? К примеру у меня есть эндпоинт, и если юзер стучится по нему чаще раза в минуту, я хочу отдать ему 403 с кодом ошибки аля «стучишься слишком часто». При этом на фронте я хочу понимать «а куда именно стучусь часто», чтоб указать правильный перевод ошибки. Для этого мне нужен кастомный эррор код. Но чет вообще нету идей как его называть. TOO_MANY_CALLS_TO_<ENDPOINT> смотрится дико))

Ну или может я вообще не так думаю и нужно это организовывать как-то иначе?
Проект довольно тривиален, никаких сверх уникальных кейсов в нем нету, потому вариант «зависит от проекта» прошу не предлагать :)

5) Нет надёжного и простого одновременно способа завершить поток раньше времени, управлять ими в процессе их работы.

Посмотри, как сделано в yarn2 и TypeScript

Они используют одинаковый способ решить эту проблему

У Yarn 2 это даже в блоге было упомянуто

https://yarnpkg.com/advanced/error-codes
Типо этого?

Да, но это скорее их список

А есть ещё обоснование почему такие

Я просто не уверен а есть ли вообще смысл каждому эндпоинту давать свои еррор коды
Может быть стоит определить какие-то generic эррор коды, а фронт уже пусть сам из контекста понимает? Аля если фронт стучится на запрос 1, то он должен понимать что здесь только один вариант ошибки 403 и он значит конкретную вещь, а потому эррор код не нужен

Честно говоря хз как загуглить

Нет. Каждому не имеет. Более того для конкретно HTTP и около него есть стандарт

Эти самые 404 и все такое

Ну да, потому и 403 юзаю
Правда сейчас нагуглил что конкретно мой кейс это 429, too many requests