Как стать автором
Обновить

Комментарии 46

Кажется, это одна из библиотек серии «Счастливой отладки, суки!» :-D

Очень неплохо! Правда есть и недостатки, например имена лексических переменных с очепятками никак не перехватываются, да и синтактические ошибки по-прежнему актуальны. Так что нужно сделать babel-плагин, который будет выполнять пред-обработку и учитывать опечатки во всех сущностях.

Когда в следующий раз забуду принять свои таблетки, обязательно напишу такой плагин. Правда, все ошибки перехватить всё равно не удастся — допустим, если функция создаётся через new Function(), а имена переменных и тело функции конструируются в рантайме.

Вообще, кстати, мне всегда было интересно, почему в JS нельзя получить напрямую доступ к контексту выполнения и посмотреть, допустим, список всех переменных в этом контексте.
почему в JS нельзя получить напрямую доступ к контексту выполнения

Раньше можно было даже программно доступ получить через parent, потом убрали видимо из соображений чистого кода и безопасности/sandboxing-а. Можно почитать тут подробнее: http://whereswalden.com/2010/05/07/spidermonkey-change-du-jour-the-special-__parent__-property-has-been-removed/


Сейчас доступ только из отладчика по скрытому свойству [[Scope]]. Подозреваю, что для node.js можно и сейчас получить доступ через V8 natives: https://www.npmjs.com/package/v8-natives, только надо с флажком будет запускать процесс


Правда, все ошибки перехватить всё равно не удастся

Если перехватить сами вызовы, которые могут генерировать новый код динамически тем или иным образом, начиная от new Function и заканчивая манипуляциями с DOM Node и создания новых script-секций, то вполне возможно
Подобная техника, правда не для шутки, а функционального тестирования, применяется в TestCafe: https://github.com/DevExpress/testcafe-hammerhead

Вы просто кладезь полезных букв, спасибо!
Наверное это можно устроить для JavaScript VM доступной для фикса, rhino (Java) или narcissus (javascript). Там можно служебные функции подёргать.

Лучше не babel плагина, а eslint. Вообще есть плагина для eslint который проверяет существование модулей и файлов которые подключаются, но вот если бы был плагин который исправляет ошибки при запуске eslint --fix, было бы куда удобнее.

Теоретически можно заимплементить плагин для prettier-а, но это решает очень узкую задачу — выявление опечаток в именах подключаемых модулей, заданных в виде строковых констант. А если require(vasya${petya}) ?


Многие остальные вещи становятся известными только в runtime-фазе, так что ни EsLint, ни Flow тут не помощники. Поэтому если уж заморачиваться, то нужна более тяжелая артиллерия.


И еще раз важная заметочка: подобная задача вполне имеет место в динамическом анализе кода и функциональном тестировании. Есть как минимум:



Задачи ооочень нетривиальные в общем случае. К примеру, довольно проблемно перехватить сгенерированный script-блок из DOM-манипуляций, чтобы выполнить предварительную обертку.

Главное теперь — не опечататься вот здесь:
const reqyire = require("reqyire");
Одну-то строчку можно запомнить посимвольно…
Зачем запоминать, когда можно просто копировать и вставить? А страницу в закладки.

В Руби есть gem "did_you_mean", который даже идет в стандартной поставке языка. Он тоже детектит опечатки, находит подходящий класс, метод, переменную или модуль, который скорее всего имел в виду автор, и падает с ошибкой, показыая правильное написание. Автор видит, что ошибся, исправляет ошибку, и код остается нормальным. С одной стороны, да, приходится опечатки исправлять, а с другой — все ж лучше получить нормальное сообщение об ошибке, а не "undefined is not a function".


Вам бы такой режим сделать, и саркастическая шутка может стать полезной вещью.

Те, кому не нравятся опечатки, а нравится, как бонус, автокомплит, пользуются typescript. И вывод и проверка типов там везде, а не только в названии внешних модулей.
В graphql тоже такое есть, по крайней мере, в сервере от apollo для nodejs

Ну вот, теперь можно писать нормальный код на javascript)

Будет удобнее, если допилить какой-нибудь *lint плагин, чтобы если пакет не найден показать ошибку с названием возможного пакета. Тогда это будет круче и можно в разработке пользоваться без злых взглядов со стороны.
втор сапсибо бoльшео, а бблитека бдет работат с CofeScript?
Не знаю, попробуйте)
Ну здорово. Но лучше было бы наверное Babel плагин написать, который конвертил бы код с очепятками в код без опечаток
По хорошему такой плагин должен находиться между стулом и монитором компьютера на котором пишеться этот самый код.
«ться»

вообще, подобное может делать и IDE. Что, кстати, IDEA и ее производные делают: спорные места выделяются шрифтом.
Есть гораздо более простое и тривиальное решение. Писать на любом языке со статической строгой типизацией.
НЛО прилетело и опубликовало эту надпись здесь

Разница в том что в одном случае упадет рантайме а во втором при компиляции)

Разница в том что оно не упадёт. Оно не скомпилируется. Я не пишу именно на C++, но во многих языках компилятор просто не допустит ошибок типа undefined is not a function / cannot read property of undefined. То же самое касается и не только полей структур / классов но и использования модулей, которые подгружаются не динамически а во время компиляции

Одно из самых распространенных заблуждений состоит в том, что статическая типазация, или новомодные обертки для ее эмуляции в виде ES-Flow, могут помочь побороть ошибку undefined is not a function, но на деле это невозможно сделать в статическом анализе.


Аналогичный примерчик на C#. В общем-то проблема в Nullable объектах, а не то, что часто принято приводить в качестве аргумента


// One
MyClass obj = null;
obj.someMethod();

// Two
delegate void SomeFunc(int x);
SomeFunc dlg = cond ? obj.someMethod : null
dlg(10);

В TypeScript есть возможность строгой проверки на null, которая такую вот ерунду исключает. Так что я бы осторожнее делал заявления вида "но на деле это невозможно сделать в статическом анализе"

Да, наверное можно получше сформулировать. Форма и значения в том или ином объекте могут стать известны только в runtime-фазе, например, когда прочли request body в HTTP-запросе и инстанцировали из него объект посредством JSON.parse — по сути преобразование из произвольного string в произвольный plain object.


Каждое из полей может быть null, undefined или чем угодно, но эта станет известно только в фазе выполнения. Есть такая штука как tcomb — это да, может помочь.


Опять-таки самая ближайшая аналогия из строго-типизированного языка, C#, это по типу:


dynamic excel = Interop.create("Excel.Workbook");
dynamic book = excel.Workbook[0];
book.Activate();

Хотелось бы в будущем увидеть "истории успеха" о пропихивании этой библиотеки кому-нить в продакшн.

А вот мне не хотелось бы…
НЛО прилетело и опубликовало эту надпись здесь
Когда-то давно слышал о вирусе, который на 1 апреля находит на компе исходники и оставляет там кучу опечаток. Ура, теперь нам и это не страшно!
был бы хороший вариант с экспортом найденных опечаток.
что бы легко было после девелопмента в продакшен переводить.
Тут в комментариях уже несколько раз высказывали идеи обратить мою фантазию в полезное русло) Но честно говоря, я не очень вижу, чем экспорт опечаток мог бы помочь. Если опечатка критична, «голый» джаваскрипт в этом месте упадёт с ошибкой, по тексту которой вполне понятно будет, что произошло. А если ошибки нет — так, может, так оно и было задуман? В JS объекты часто используются как хеш-таблицы, обращение к несуществующему свойству в таком случае — штатная ситуация.
Если опечатка критична, «голый» джаваскрипт в этом месте упадёт с ошибкой

Вопрос в том, когда он упадет в этом месте. Например, через две недели на продакшене.
Ну так моя либа не занимается статическим анализом, и сообщение об опечатке может выдать лишь в тот самый момент, когда всё упало бы без неё.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь

Обратите внимание на список хабов под заголовком поста.

НЛО прилетело и опубликовало эту надпись здесь

Стоп! Товарищ автор, а что мешает тебе сделать линтер или какой нить компилятор, который будет ошибки исправлять прямо в коде в процессе написания? Ведь если ты делаешь это в тихую, просто по сути алиасы добавляя, почему бы не сделать это громко? я б не отказался иногда от такого иструмента. Шорткат какой и перепутанные буквы встали на место или проверка при потере фокуса. И тогда твоя шутка реально станет полезной. Да и думаю многие IDE будут не против такого механизма автоисправления кода

Уже отвечал выше, но мне, в общем-то, нетрудно повторить)

Дело в том, что либа работает в рантайме, а для линтера или плагина к IDE требуется статический анализ. Статический анализ JS-кода — это задача не то чтобы совсем уж невозможная, но принципиально отличающаяся от того, что делает reqyire.js.

Нет, я понимаю, что ты делаешь в этой либе. И прекрасно понимаю, что одним AST тут не обойтись. Но на самом деле я как говорил о том, чтобы использовать твой движок нечеткого поиска дабы именно на основе рантайма генерировать правильный код. К тому же ты можешь, как самый простой вариант, сыпать варнингами в консоль о том что ты заменил, где и на что. ввести глобальный реквайр твоей либы, которая бы обернула обычный, и в девелопмент окружении сыпал матюгами на криворукого и слепого разраба за подмены, а в продакшене — ни подмены, ни варнингов. Упало — сам дурак, поднимай девелопмент и смотри в консоль. В общем идей море, главное время и желание. Тогда твоя разработка перейдет из разряда "сжечь еретика" в полезный инструмент разработчика

То есть вы хотите, чтобы в рантайме вместо «Error: cannot find module X» выдавалось «Error: cannot find module X, did you mean Y?» Это да, это можно организовать. Мне только полезность этого мероприятия представляется сомнительной. Самое сложное в правке опечаток — это найти опечатки. Понять, на что их нужно исправить, обычно тривиально.

Ну почти. Подменить, сообщить о подмене, указать где исправить. профит следующий:
1) человек знает где накосячил и может это исправить.
2) при этом он сразу видит результат своего труда, а не ошибок. допустим он реализует или проверяет некий сложный прототип в действии. так он сможет посмотреть верным ли он путем пошел и исправит опечатки на этапе рефакторинга, например.
Мне кажется, что в таком случае у программиста будет выше настроение и больше продуктивность. И вам по фану и людям радость

Ругливые компиляторы и инерпритаторы от того и придумали, чтоб выполнялся тот код, который программист хочет, а не тот, который какой-то другой код, пытается отгадать.
Мне тоже не нравится «undefined is not a function», но эту ошибку можно увидеть только потому что js и так слишком добрый. Именно от этого его сложно дебажить.
Строго типизированный язык скажет кто не фанкшин и где не фанкшин. И, если ты очепятался, то он тебе об этом скажет, а не попробует отгадать твои мысли через кривые пальцы.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории