имхо во flow лучше все самому

ага

я именно так и делаю

у тебя много людей в команду?

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

в команде*

2

да, тогда это может взлететь

да вроде масштабируется)

будет сложно на большой команде людей с разным уровнем и разным бекграундом

Ну не сложнее чем писать код

Тебе нужен метод - добавляешь в декларацию

как вы обновляете версии? нет боли?

пока не было

но - мы страемся не использовать зависимости по возможности

поэтому их очень мало

мало — сколько?

2-3 сторонних зависимости

а, ну тогда все просто, да

но скорее всего и их в будущем заменим на свои обертки

но - мы страемся не использовать зависимости по возможности

у меня на hello world уже будет штук пять - как справляетесь

так как target es5 не дает пользоваться новыми api

кстати, нашел как это настроить target: es5 lib: [es5, es2015, es2016]

у меня на hello world уже будет штук пять - как справляетесь

на сервере это проще

А на клиенте то для чего зависимости? реакт и вперед

не компоненты же готовые брать

роутер, формы, валидатор, редаксы всякие да и компоненты есть готовые

разное мелкое говно

i18n

etc, etc

ну на бэкэнде тоже всякое нужно

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

Я с годами перестал исповедовать этот принцип ? и стал брать гонвно с npm и править их код если мне надо

вот например i18n - в чем ценность либ?

просто мэпы, остальное сахар

стандартизация

пришел новый чел дал читать чужие красивые доки

а не потратил пару дней чтобы он вкурил что мы там накалякали

ну доки то нужны в любом случае

у нас это декларируется что и доки и тесты нужны - но времени на их написание не выделяется ?

ну доки = комменты в коде

если этого недостаточно, то что то пошло не так с api

i18n далеко не просто мэпы

plural, разные даты, разные цены, динамические компоненты посреди перевода

Ну все равно же магически все не работает

это да, но писать все самому не вариант

Нужно задать все сообщения, знать специфику каждого языка

надо делать продект

ну вот какую вы либу используете?

https://github.com/yahoo/react-intl

которая поверх http://formatjs.io/

которая поверх ECMA-402

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

<FormattedPlural value={10} one='message' other='messages' />

да

Hello, {name}, you have {itemCount, plural, =0 {no items} one {# item} other {# items} }.

а где падежи?

я не вдуплил твой вопрос вечером скорее всего нет

а где падежи?

http://userguide.icu-project.org/formatparse/messages Здесь

Formatjs по нему работает

ну то есть это просто тупая шаблонизация?

http://userguide.icu-project.org/formatparse/messages Здесь

там уже первый пример доставляет femail male other - что то изменилось - появился новый пол

у них так, да

оно пригласило на вечеринку

ts можно заставить проверять js?

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

во флоу есть на комментах

—allowJs

allowJs просто компилирует

но не проверяет типы

он вроде ж выводит что может

https://flowtype.org/blog/2015/02/20/Flow-Comments.html

не, ваще пишу что хочу и кушает

https://flowtype.org/blog/2015/02/20/Flow-Comments.html

это стремно, лучше test.js.flow

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

https://egghead.io/lessons/javascript-catching-javascript-mistakes-with-typescript

так проверять не будет

Примеры того, что можно делать

так проверять не будет

как? через test.js.flow?

ага

хм, вроде работает

он только .flow и будет смотреть

сейчас потестю

https://egghead.io/lessons/javascript-catching-javascript-mistakes-with-typescript

allowJS такое не делает :(

allowJS такое не делает :(

Входной файл js?

да

он только .flow и будет смотреть

да, именно так :(

было бы так удобно

все гавно

да не, аннотации то в коде нужны. как ты их отдельно положишь

только для публичных api

то есть для экспортов

ну теоретически возможно, но не всегда

этого достаточно для 80% кейсов

проблема в том, что если флоу потребует аннотацию внутри, то ничего нельзя будет сделать

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

тогда уж лучше вседа комменты

хм

@vkurchatkin можно заставить flow ругаться на any? или на отсутствие module definition?

нет

есть flow coverage