лучший способ - ломать периодически

Нет, лучший способ — понять, в чём дело, и предоставить нормальный API для начала.

Если возможно - да

Но иногда люди так делают, просто потому что могут

А старые кишки задепрекейтить, спрятать внутрь, и отломать.

Как в случае с grceful-fs

Если это необходимо.

Например, тот же самый readable-stream

Который как модуль в npm.

До совсем недавнего времени он дёргал внутренний API евентемиттера.

Внутренние _headers дёргают все кому не лень.

Ну без этого всего явно обойтись можно

С readable-stream было нельзя, для достижения того, чего они хотели.

Только недавно новое апи появилось.

https://github.com/nodejs/readable-stream/blob/master/lib/_stream_readable.js#L58-L69 — вот там feature detection

проблема в том, что этого не нужно хотеть)

в js люди не понимают, что такое абстракция зачастую

в event emitter нельзя полагаться на порядок - в этом суть асбтракции

Да, это было так, но readable-stream из ядра полагался.

Оттуда это перекочевало в отдельный модуль.

Если это нужно настолько — то тогда само API пора менять.

в этом и есть ошибка - нельзя было выделять это в модуль в таком виде

Что, кстати, и сделали.

Конечно, нельзя.

Вообще, дёргать из модулей недокументированное API очень некруто.

https://github.com/nodejs/node/pull/6032 — вот тут добавили prependListener

А, я вижу там твой комментарий.

readable-stream не был единственным модулем, которому был важен порядок.

И я не вижу ничего плохого в том, чтобы предоставить гарантии порядка на уровне абстракции.

так там нужно чтобы хэндлер вызвался первым - такой гарантии все равно нет

Пока это гарантируется в документированном апи и пока никто не пользуется недокументированным апи и не полагается на недокументированное поведение — всё хорошо.

так там нужно чтобы хэндлер вызвался первым - такой гарантии все равно нет

М. Оно делает ровно то, что описано в документации — добавляет хэндлер в самое начало. Остальные по умолчанию добавляются в конец.

да, но модулям то нужно не это

им нужно чтобы он был строго первым

Тогда надо было делать иначе и кидать исключение, если там уже есть «строго первый».

Емнип, это обсуждалось, надо смотреть.

Кстати, такую фичу всё ещё можно добавить флагом к prependListener

Но точно ли оно нужно?

ну если оно не нужно, то и prepend не нужен был

наоборот, prepend позволяет сломать поведение с помощью публичного api

Поведение чего?

readable-stream?

Или чего-то другого?

нет, родного нодвского стрима

Ну, это фактически одно и то же. Что не очень хорошо, конечно.

Собственно, это и было причиной проблемы.

В какой-то степени.

здравствуйте. не могу понять, как мне в модуль передать подключение к бд. т.е. заного чтоли коннект инициализировать или как то можно передать?

создай прослойку, где будешь создавать коннект и будешь экспортировать его

@ChALkeR https://gist.github.com/vkurchatkin/15d731e44785dce4fe4d6b9bba0308b1

вот так можно обойти обойти unpipe при ошибке, раньше это было невозможно

создай прослойку, где будешь создавать коннект и будешь экспортировать его

м, спс

вот так можно обойти обойти unpipe при ошибке, раньше это было невозможно

Точно ли это плохо?

ну весь смысл этого кода, в том чтобы гарантировать вызов хэндлера

раньше его можно было гарантировать

Нет, я к тому что код с препендом делает то, что я от него ожидаю — перехватывает ошибку первым и кидает её наверх.

да, и ломает заложенное в стрим поведение

Это можно без process.once('uncaughtException' воспроизвести?

думаю нет

Ну тогда я не вижу в этом ничего особо страшного.

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

когда мы не даем остальным хэндлерам выполниться

мне кажется это можно только так сделать

(потому что кто не валит процесс в uncaughtException — ссзб)

но суть не в этом - error хэндлер больше не выполняется первым

если это важно, это плохо

если не важно - то зачем поднимать шума, добавлять api?

ERROR: S client not available

Это с https://github.com/nodejs/node/commit/545807918ee72f55dfefc6a4c557e3d4e2018ee1

Мне надо бежать, потом посмотрю внимательнее.

Ссылка на issue там битая, это https://github.com/nodejs/node-v0.x-archive/issues/6007

всем привет! Ребят, кто сталкивался с такое проблемой: Error: connect ENOENT /var/run/mysqld/mysqld.sock при коннекте через sequelize к mysql?

а пробовал просто создать этот файл?

нетъ

ну так)

он его подхватит?

ошибка ENOENT означает что файл не найден

он его подхватит?

не знаю возможно

должен

у меня до этого была ошибка Error: connect ECONNREFUSED 127.0.0.1:3506

и решением было прописать вконфиге "dialectOptions": { "socketPath": "/var/run/mysqld/mysqld.sock" }

а может у тебя просто демон мускуля не запущен?

но после стала вызываться ошибка, что выше писал

sudo service mysqld status

что пишет?

да, не запущен

ну тогда удали то что писал в конфиге

я только начал работать с нодой и бд

и сделай sudo service mysqld start

ну что, сработало?

нет

нету такого сервиса

Failed to start mysqld.service: Unit mysqld.service not found.

А mysql установлен?

кстати да)

да

/etc/init.d/mysqld start

2.11.1

вот версия

а ну так вот ты запустил