да, уличная магия по ходу какая-то

ну вот я целое число даю ему

судя по тому, что написано в ридми это должно работать

но не работает

foo(2) // flow ok, tcomb ok

да, дичь какая-то)

Тслинт

а вот этим не пользуешься? https://github.com/Microsoft/vscode-chrome-debug

это да, непонятен просто сам механизм проверки

да в рантайме проверка идет

а статически нет?

нет, в том и суть

этого плагина

просто он пишет

foo(2) // flow ok, tcomb ok

а флоу не ок как бы

да, это странно

Этот ваш flow — боль.

У него какое-то странное представление о covsrage. Скажите, там всё ок? Есть баги?

В coverage?

flow coverage

просто он пишет

Мне кажется все зависит от $Refinement

Ну, он мне писал, что у меня одно выражение непокрыто.

А там ВСЁ покрыто. Там и покрывать-то нечего.

Скорее если баг и есть, то не в coverage

Ну, с такими аномалиями вообще кто-то сталкивался? А то я не знаю — продолжать плясать с бубном, или искать причину вовне.

Да, такое бывает

Можно попробовать поискать причину

Но если не охота, то просто ограничиваешь распространение проблемы аннотацией

Если кинешь фрагмент кода, то может что еще можно будет сказать

А вообще, хорошая практика — покрывать всё-всё-всё? Или не обязательно? Просто flow сам неплохо всё обсчитывает, и здравый смысл подсказывает, что можно ограничивать только аргументы и return.

Если кинешь фрагмент кода, то может что еще можно будет сказать

Тот фрагмент только завтра смогу.

Лишних аннотаций лучше не добавлять

В локальных функциях и классах они чаще всего вообще не нужны, но тут их можно использовать по вкусу

coverage никак не связан с аннотациями

Вот тут не понял.

coverage - это процент выражений, у которых определен конкретный тип (не any или empty)

Можно иметь 100% coverage без единой аннотации

За счет type inference

Аннотации помогает с coverage в ситуации, когда уже есть выражение с any

То бишь, coverage — процент выражений, которые flow вообще сможет определить?

Процент нетипизированных выражений, грубо говоря

Так. И за 100% coverage гнаться в принципе не стоит, а нужно просто делать check и всё?

Нет, за 100% coverage гнаться стоит, но это не значит что нужно добавлять аннотации без разбору

Нужно смотреть, откуда появляется any и либо решать проблему на корню, либо ставить аннотацию как можно ближе к источнику проблемы

Тогда вот думаю — нормальная практика реджектить коммит без 100% coverage?

Нет, во многих кейсах 100% недостижимо

Типа там, где много нетипизированных зависимостей, аннотирование которых займёт много времени?

Нет, это пример когда можно достичь 100%

Самый простой пример - try catch

Ошибка в catch будет всегда непокрыта

Оу... Почему?

Для нее безопасным типом является только mixed, но для соответсвия реальным практикам js ее сделали any

Аннотация прямо в catch не поддерживается, к сожалению

А, даже так.

Ну, так-то, в теории, я вполне могу описать, что может вернуться.

Аннотация прямо в catch не поддерживается, к сожалению

По сути для такого надо делать у каждой функции кроме ретурн типа ещё и набор возможных эксепшенов

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

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

А например?

Ну ошибка в либе, ошибка в тайпинге и т д

У меня есть практика и свои исключения создавать, перехватывая всё, что можно, на самом нижнем уровне кода.

Ну ошибка в либе, ошибка в тайпинге и т д

Не, ну такое и для ретурна ж справедливо)

Не, ну такое и для ретурна ж справедливо)

Или для параметров функции

Ну, отчасти да

Но например может RefernceError из либы всплыть

Или что то такое

В джаве такое тоже есть, но там catch указывает класс

Но например может RefernceError из либы всплыть

Так все типы ошибок можно в теории согнать в один и подключать его потом.

ERROR: S client not available

Ну это означается что в каждом catch нужно проверять на все такие типы

В джаве такое тоже есть, но там catch указывает класс

Ну это же сахарок над if+instanceof+else throw

Иногда сахарок все меняет

Это было бы логично. Ошибка — это объект. В общем-то, его структура заранее почти всегда известна.

> @bigslycat В общем-то, его структура заранее почти всегда известна. Ну, не с точки зрения строгого статического анализатора

Это было бы логично. Ошибка — это объект. В общем-то, его структура заранее почти всегда известна.

Ага, throw "abc"

Ага, throw "abc"

А вот это неправильно, я считаю.

Я согласен, но так можно

Если делаешь throw, создавай экземпляр ошибки или своего класса, наследованного от ошибки.

Только заранее реши проблему наследования от ошибки ))

Я согласен, но так можно

Но тогда нормальная практика — ввести такое ограничение.

Только заранее реши проблему наследования от ошибки ))

Ачотам?

Ачотам?

http://stackoverflow.com/questions/31089801/extending-error-in-javascript-with-es6-syntax

Но тогда нормальная практика — ввести такое ограничение.

Да, но я просто как пример, что жс не так прост)

Мне кажется это должно работать из коробки

http://stackoverflow.com/questions/31089801/extending-error-in-javascript-with-es6-syntax

Ну... Не так уж и неудобно. =) Можно ведь вообще в промежуточный класс засунуть эту логику.

Да, все работает

Самый простой пример - try catch

вот странно, что try-catch нельзя исключить из coverage в таком случае

Наследование встроенных классов долго было в сломанном состоянии

понятно, что error: any, но можно же дальше обязать делать проверки через coverage

Ну оно либо any либо mixed

Если any, то проверки не нужны

не, для catch-блока, имею ввиду

все равно не понял

try { foo(); } catch (e) { if (typeof e === 'string') { console.log(e); } }

имеем код, чисто теоретически в нем не будет ошибок из-за типов

хочется чтобы coverage в данном случае был 100%

Ну костыль же.

почему костыль?

ну так не может быть логически

потом что e - any

понятно, что e - any