Я бы хотел объективных аргументов, почему new Promise - плохо. У автора bluebird, я увидел только информацию о том, что не надо использовать new Promise, для callback wrap, когда есть функции промисификации. Но кейс, который изначально рассматривался, это не тупая промисификация колбэка. И я считаю, что это вполне корректно использовать в том случае new Promise, по крайней мере до тех пор, пока не получу объективных аргументов, а не субъективных вроде "разработчик обычно не обрабатывает ошибки", или ещё в этом духе.

Самая важная вещь --- бабел все равно сделает все в виде промисов, но он расставит их так через статистический анализ кода, что утечек не будет.

Ага.

Какой ещё бабел в ноде????

Он реализуется в пару строк. И сейчас он даже может и есть но называется finished

В общем это явно несущественно и странно что ты на этом внимание заостряешь

Это неправда, в ядре этого ещё нет, есть finished, но работает он немного иначе(он не агрегирует чанки).

Несущественно то, что ты говорил, что не втащил ни одной либы, но по факту втащил
Пара строк, ок. И тесты на них
Уже строк десять получится :)

Вообще я его либой вставил потому что вообще говоря уже написанное кем-то нужно использовать.

А не велопарк городить.

Первое предложение правда. Второе: я сказал слово может

Я вас понял.

Но этот АПИ постепенно переедет туда весь. Вот увидите

Сейчас уже появились поля readable а не только событие

Для проверки наличия данных в буфере стрима

Это решает самую большую проблему альтернативного pull api

А есть название этой проблемы, чтобы почитать структурировано?

Или как загуглить

Что нужно было помнить о том что случилось readable или считывать данные до упора

Streams Handbook