ну в дефинишинах в идеале export default function

но зависит

можете еще добавить allowSyntheticDefaultImports

а у вас только ts компилит или ts+babel?

ошибка эта от ts

от того, что вы используете зависит можете ли пользоваться allowSyntheticDefaultImports или нет

а что он пишет-то на * as Name?

Module '".../node_modules/@types/is-promise/index"' resolves to a non-module entity and cannot be imported using this construct.

в данном случае нет бабаеля

хохо, а версия ts какая?

https://github.com/Microsoft/TypeScript/issues/5073

все понятно

ну короче тайпинги битые)

короче фикс в тайпингах простой надо еще сделать namespace с именем isPromise

вот почему в тайпингах такой странный синтаксис юзают)

да ты прав

у flow с vscode норм интеграция?

хуже, чем с атомом, но в целом ок

https://github.com/codemix/flow-runtime

вот кусок работы с внешним миром может и имеет смысл так перегнать, но все равно чет как-то

продолжение tcomb и babel-plugin-typecheck

What about TypeScript? Despite the name, it's absolutely possible to use flow-runtime with TypeScript. Unfortunately it's not yet possible to leverage the TypeScript annotations themselves, but all of the library methods should match the relevent TypeScript semantics as Flow and TypeScript are both "just JavaScript".

так babel-plugin-typecheck это от тех же чуваков

ты про то, что из тайпскрипта не сделать рантайм валидацию?

кто-ть кстати юзал flow-runtime? оно юзабельно? как-то звезд маловато. Хотя там дженерики поддерживаются в отличии от tcomb

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

ну хотя видимо только на уровне совпадений с синтаксисом flow

да, в доке заявлено только для флоу фул сапорт

это где?

`Flow Runtime Build Status A runtime type system for JavaScript with full Flow compatibility.`

https://codemix.github.io/flow-runtime/#/

я про ts оттуда скопировал

короче ненадежно

до первой несовместимости

я думаю, что это достаточно бесполезно вообще

вот прям вообще в принципе)

рантайм?

да

то, что можно делать в compile time, лучше делать в compile time

ну по всему коду возможно да. но я просто наприме щас пишу либу, в которой будет возможно описывать HTTP API в типах и тут валидация (возможно только в роутах) будет очень кстати

вот кусок работы с внешним миром может и имеет смысл так перегнать, но все равно чет как-то

.

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

ну ты там руками должен прогонять валидатором, аля json-schema, тогда это стоило бы позиционировать как его аналог, требующий особого синтаксиса в js и этапа компиляции :)

но звучит как-то не очень, да?)

особого синтаксиса для валидации? почему? tcomb и flow-runtime работают с обычными типами

json schema перегоняется один в один в типы

обратно уже нет

https://github.com/codemix/flow-runtime/tree/master/packages/babel-plugin-flow-runtime ну я про этот этап

а flow можно прогнать чисто как чекер?

ну так это ж бабель плагин

"plugins": [ "syntax-flow", "tcomb", "transform-flow-strip-types" ]

вот в такой последовательности и ничего не надо делать

а flow можно прогнать чисто как чекер?

ну тут уже на вкус и цвет

просто этой штуке нужен синтаксис нетронутый

мне например достаточно поддержки в IDE

но сама она чеки не прогонит

ну по-хорошему это должно быть в билде

как один из этапов типа тестов

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

A second more important difference is that type aliases cannot be extended or implemented from (nor can they extend/implement other types). Because an ideal property of software is being open to extension, you should always use an interface over a type alias if possible. вот че это за фигня в документации к ts?

я тоже это читал, да)

они там на солид ссылку дают ещё

интерпретируют этот бедный солид как могут

бррр https://github.com/Microsoft/TypeScript/wiki/FAQ#can-i-make-a-type-alias-nominal

ERROR: S client not available

надо понакидывать там что ли https://github.com/Microsoft/TypeScript-Handbook/issues/476

у них каникулы походу(

А что есть замена энамам?

literal types

никаких вам стремных runtime штук, никаких проблем с присваиванием им чего угодно

Только строковые литералы - не айс

почему?

Хоть и проверяются

можете числа юзать

так чем строковые литералы хуже енамов?

проверяются статически, не эмитят ничего лишнего в райнтайм - это плюсы, а минусы?

Ну вот я глянул сейчас, на самом деле плюсов больше, ты прав. Но мне не нравятся строки, и их объявление через |. А так в целом, да.

Ну вот я глянул сейчас, на самом деле плюсов больше, ты прав. Но мне не нравятся строки, и их объявление через |. А так в целом, да.

непривычно видимо)

Да, не привычно, от строк просто веет поздним связыванием, которое раньше до рантайма нигде не проверялось. Тут все ок )

енамы еще в херово-оптимизируемый код транспилились

и транспилятся

поставь падабайку https://github.com/Microsoft/TypeScript-Handbook/issues/476

готово

у них каникулы походу(

не, работают

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

@mkusher а ты где-то еще кроме Вовиной репки видел, чтобы они упоминали, что енумы легаси?

нет, вот хочу чтобы официально чето и было)

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

возможно bassarat чето в своей книжке про это писал

нет, вроде нету ничего

зачем люди используют такую схему TS -> ES6 -> Babel -> ES5, если можно сразу в ES5?

у ts есть проблемы

1. модули(ваще никакая совместимость с commonjs) 2. до недавнего времени async-await 3. генераторы 4. for of через Symbol.iterator

у бабеля тоже проблема с модулями если что

ну вообще да

с модулями вообще ничего непонятно(