Pull to refresh

Comments 29

UFO just landed and posted this here
Ух как интересно стало — что не так с npm? Сначало даже подумал, что пропустил рождение новой звезды — но нет, nodejs все еще использует и поставляется с npm.
Проблема даже не в самом npm, а registry (хранилище пакетов).
# Проверяем путь к хранилищу пакетов
➜ npm get registry
http://registry.npmjs.org/

# Устанавливаем пакет в альтернативное хранилище:
➜ npm install --registry="https://путь к вашему локальному хранилищу"

В таком случае, никаких претензий не будет, поскольку все файлы будет храниться в том месте где вам удобно.
Также есть IPFS...
То что другие используют идиотский подход при разработке пакетов, совершенно не значит что сама идея пакетов плоха, и не нужно их использовать.
Я когда-то давно сделал Panic.js для того же самого, но все никак руки не дойдут написать статью.
Тут ловятся непойманные исключения, парсится коллстек и загружаются исходники, разворачиваемые по клику:
125 кб + зависимости, к большому сожалению.
Это не для использования на продакшене — а для дебага лишняя сотня кб не проблема. Оно еще и вешает хук на все коллбеки EventTarget, поэтому страдает производительность (теоретически). Дело в том, что это не stand-alone инструмент, а часть здорового фреймворка, который оно весь тянет за собой. В будущем я хочу отделить его в самостоятельный проект, с минимумом зависимостей, тогда размер будет маленький. Собственно, это та причина, по которой это нигде особо не публиковалось пока.
В качестве расширения для браузера его сделать не планируете?
и вот https://airbrake.io/
сервер Sentry можно вообще на свою машину установить, это вроде бы единственное open-source решение
Можно, кстати, отказаться от использования Sentry и использовать отдельно реализацию Raven JavaScript, указать свой эндпоинт в настройках, затем ловить то, что будет приходить :)
Вот это можно было бы использовать как солидный парсер stacktrace (там есть всякие нюансы, кросс браузерность и тд) https://github.com/stacktracejs/stacktrace.js В принципе эта либа + простейший UI и библиотека не нужна.
В Safari есть такая проблема, что в onerror не передается объект Error, поэтому вы не сможете получить коллстек в unhandled exception listener'е.

В Panic.js упомянутом выше это обходится с помощью следующего work-around: поскольку практически весь реальный код выполняется внутри какого-либо колбека (setTimeout, addEventListener и т.п.), и таких «точек входа» не так много, то можно их все заврапить в try/catch:

https://github.com/xpl/useless/blob/master/base/uncaught.js
https://github.com/xpl/useless/blob/master/base/uncaughtAsync.js

Дополнительно это дает возможность строить асинхронные колл-стеки. Что забавно, хромовский веб-инспектор именно такие стеки и показывает, но при этом в объект Error передается «обычный» урезанный стек, без асинхронного контекста. Это фейл. Собственно, Panic.js позволяет получать полный стек на любой платформе, вне зависимости от прихотей браузера.

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

Для Node.js там реализован няшный текстовый принтер эксепшенов, тоже со строками кода и табличным форматированием:
А умеет Panic.js отлавливать непойманные режекты в промисах?
Кажется, что пока onunhandledrejection не будет доступно в браузерах, сделать это проблематично.
Неа, мне даже пока это не приходило в голову, но идея хорошая.
Почему бы не добавить пакет в bower, раз инструмент используется в браузерах и на клиентах?
Так гораздо проще будет пользоваться тем, кто настроил клиентский инжект на страницу :)
Хороший модуль. Кстати в дефолтную поставку можно добавить отпарвку ошибки в гугл аналитикс. Это самое простое решение, про него уже несколько раз писали на хабре.
А почему GA, а не Метрику?
Цель у show-js-error лишь одна — выводить приметное сообщение при возникновении js-ошибки.
Only those users with full accounts are able to leave comments. Log in, please.