Комментарии 46
Кажется, это одна из библиотек серии «Счастливой отладки, суки!» :-D
Очень неплохо! Правда есть и недостатки, например имена лексических переменных с очепятками никак не перехватываются, да и синтактические ошибки по-прежнему актуальны. Так что нужно сделать babel-плагин, который будет выполнять пред-обработку и учитывать опечатки во всех сущностях.
Вообще, кстати, мне всегда было интересно, почему в 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
Теоретически можно заимплементить плагин для prettier-а, но это решает очень узкую задачу — выявление опечаток в именах подключаемых модулей, заданных в виде строковых констант. А если require(vasya${petya}) ?
Многие остальные вещи становятся известными только в runtime-фазе, так что ни EsLint, ни Flow тут не помощники. Поэтому если уж заморачиваться, то нужна более тяжелая артиллерия.
И еще раз важная заметочка: подобная задача вполне имеет место в динамическом анализе кода и функциональном тестировании. Есть как минимум:
- абстрактная имплементация для произвольного динамического анализа https://www.npmjs.com/package/iroh
- решение для sandbox-инга SPA-приложения и внедрения в него потока use-case-ов функциональных тестов: https://github.com/DevExpress/testcafe-hammerhead
Задачи ооочень нетривиальные в общем случае. К примеру, довольно проблемно перехватить сгенерированный script-блок из DOM-манипуляций, чтобы выполнить предварительную обертку.
const reqyire = require("reqyire");
В Руби есть gem "did_you_mean", который даже идет в стандартной поставке языка. Он тоже детектит опечатки, находит подходящий класс, метод, переменную или модуль, который скорее всего имел в виду автор, и падает с ошибкой, показыая правильное написание. Автор видит, что ошибся, исправляет ошибку, и код остается нормальным. С одной стороны, да, приходится опечатки исправлять, а с другой — все ж лучше получить нормальное сообщение об ошибке, а не "undefined is not a function".
Вам бы такой режим сделать, и саркастическая шутка может стать полезной вещью.
Ну вот, теперь можно писать нормальный код на javascript)
Разница в том что в одном случае упадет рантайме а во втором при компиляции)
Разница в том что оно не упадёт. Оно не скомпилируется. Я не пишу именно на 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();
Хотелось бы в будущем увидеть "истории успеха" о пропихивании этой библиотеки кому-нить в продакшн.
что бы легко было после девелопмента в продакшен переводить.
Стоп! Товарищ автор, а что мешает тебе сделать линтер или какой нить компилятор, который будет ошибки исправлять прямо в коде в процессе написания? Ведь если ты делаешь это в тихую, просто по сути алиасы добавляя, почему бы не сделать это громко? я б не отказался иногда от такого иструмента. Шорткат какой и перепутанные буквы встали на место или проверка при потере фокуса. И тогда твоя шутка реально станет полезной. Да и думаю многие IDE будут не против такого механизма автоисправления кода
Дело в том, что либа работает в рантайме, а для линтера или плагина к IDE требуется статический анализ. Статический анализ JS-кода — это задача не то чтобы совсем уж невозможная, но принципиально отличающаяся от того, что делает reqyire.js.
Нет, я понимаю, что ты делаешь в этой либе. И прекрасно понимаю, что одним AST тут не обойтись. Но на самом деле я как говорил о том, чтобы использовать твой движок нечеткого поиска дабы именно на основе рантайма генерировать правильный код. К тому же ты можешь, как самый простой вариант, сыпать варнингами в консоль о том что ты заменил, где и на что. ввести глобальный реквайр твоей либы, которая бы обернула обычный, и в девелопмент окружении сыпал матюгами на криворукого и слепого разраба за подмены, а в продакшене — ни подмены, ни варнингов. Упало — сам дурак, поднимай девелопмент и смотри в консоль. В общем идей море, главное время и желание. Тогда твоя разработка перейдет из разряда "сжечь еретика" в полезный инструмент разработчика
Ну почти. Подменить, сообщить о подмене, указать где исправить. профит следующий:
1) человек знает где накосячил и может это исправить.
2) при этом он сразу видит результат своего труда, а не ошибок. допустим он реализует или проверяет некий сложный прототип в действии. так он сможет посмотреть верным ли он путем пошел и исправит опечатки на этапе рефакторинга, например.
Мне кажется, что в таком случае у программиста будет выше настроение и больше продуктивность. И вам по фану и людям радость
Мне тоже не нравится «undefined is not a function», но эту ошибку можно увидеть только потому что js и так слишком добрый. Именно от этого его сложно дебажить.
Строго типизированный язык скажет кто не фанкшин и где не фанкшин. И, если ты очепятался, то он тебе об этом скажет, а не попробует отгадать твои мысли через кривые пальцы.
Пятничный JS: reqyire.js и очепятко-ориентированное программирование