зачем

ну зачем вы хотите так делать :(

es modules же есть(

по примеру с типами для angular

когда namespace angular определен глобально

import { MyInterface1, MyInterface2 } from "my/types/for/angular";

и он содержит все типы для angular

соотвественно мне не нужно подключасть все типы к каждому файлу

а вы используете все типы в каждом файле?

явное > неявное

ну в каждом файле будет типов по 10-20

следующий шагом будет сделать какой-нибудь глобальный модуль

и там глобальный стейт

доступный неявно ото всюду :|

чем плохо иметь глобальные типы?

мы же не подключаем в каждом файле String или Number ?

глобальностью

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

Благими намерениями вымощена дорога в ад

Сейчас вы строите магистраль

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

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

типы отделены от мест основной работы с ними

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

а если есть преобразования, то вы же их вероятно подключаете?

в мире ecmascript уже есть неймспейсы - модули

что вы имеете ввиду под преобразованиями?

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

ну и еще что namespace из ts не нужен

это позволяет быстро находить нужный тип с помощью автодополнения

мы сейчас переводим огромный проект ng1 на TS

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

Starting with ECMAScript 2015, modules are native part of the language, and should be supported by all compliant engine implementations. Thus, for new projects modules would be the recommended code organization mechanism. это из доки typescript

это позволяет быстро находить нужный тип с помощью автодополнения

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

Сейчас обновил тайпинги реакта, и все посыпалось. При чем, ругань такого типа: Subsequent variable declarations must have the same type. Variable 'a' must be of type 'HTMLProps<HTMLAnchorElement>', but here has type 'HTMLProps<HTMLAnchorElement>'.

Что это вообще значит? Речь ведь об одном и том же формате "HTMLProps<HTMLAnchorElement>"?

Ну я же говорю, у меня особый случай, хочу свой lodash сделать

летом тоже стелал, раньше flyd с ramda использовал, теперь ток ramda и особый случай..

доволен как слон, сделал паттернмачинг как хотел. С каррированием только доконца не разобрался, как слушается "btbox" так не заработатет... ...но я много времни не тратил на то чтоб сделать такие детали.

Спасибо всем неравнодушным, кто откликнулся на вопрос. После нескольких часов бубна с namespace решили писать по нормальному с импортами.

кто-нибудь завел VS Code Crome Debugging для связки TypeScript+WebPack?

Я так работаю

Там всё довольно тривиально

Есть проект на TS. Работаю с ним в vscode. Периодически отваливается дебаг. Чтобы вернуть, надо поменять target в tsconfig. На некоторое время всё возвращается в норму, но потом опять отваливается. На другом компе всё нормально. Кто-нибудь сталкивался? P.S. js нормально дебажит

я добился того, что он брекпоинты считает корректными, но он останавливается на них не всегда, по некоторому неясному пока принципу. Антон, на что меняете target?

С es6 на es5 и обратно. Причем при дебаге показывает путь типа /1001/server.ts (если крэш случается)

Причем это уже на втором проекте. На первом было через tsc, сейчас через gulp.

Я понял, что с моими точками останова. видимое место точки не соответствует реально исполняемому коду (несильно, на 1-5 строк кода), то есть можно остановиться, можно идти пошагово, по Locals я вижу, что происходит, но показываемое место выполнения не соответствует реальности. Получается, webpack не вполне корректные sourcemap генерирует. No ideas?)

Стопроцентное соответствие только с режимом source-map в вебпаке

остальное по идее всегда с определенной погрешностью

vs code недавно ещё переехал на node2 debugger, я не сравнивал, но по идее он так же должен работать лучше и точнее

Какой сейчас tslint конфиг топовый?

Ни у кого не бывало что vsc не сохраняет файлы ?. Тоесть постоянно кружок горит над табом а не крестик ✖

??

Как сфокусироваться на рабочей директории в проводнике vs code, чтобы создать новую папку в корне?

Кнопка 'создать папку' создаёт в активной, после свернуть все фокус на настройках vs code

листать надоело, может, есть способ?

Отбой, разобрался. Чтобы получить фокус на корне, нужно 'обновить' нажать

Есть ли какие-то линтеры, позволяющие контролировать иммутабельность в проекте?

ERROR: S client not available

Попробовал этот, но он не работает https://github.com/jonaskello/tslint-immutable

За ссылку спасибо, очень хороший Readme у проекта :)

Или я неправильно его использовал )

На что должно указывать rulesDirectory в tslint?

Я теперь без тайпскрипта жить не могу

Я теперь без тайпскрипта жить не могу

Воу, какие признания!

Да

Есть ли какие-то линтеры, позволяющие контролировать иммутабельность в проекте?

а что значит контролировать, вы на уровне типа можете прописать все как readonly

Что б это было прописано как обязательное правило. Могу не все проконтролировать )

а что значит контролировать, вы на уровне типа можете прописать все как readonly

Именно это и форсирует данный линтер, судя по документации.

ну и любой мутабельный тип можно привести к немутабельному с mapped types

зачем, если это уже умеет сам компилятор?

Что б это было прописано как обязательное правило. Могу не все проконтролировать )

а, что каждое поле обязано быть объявлено как readonly?

А как обеспечить контроль иммутабельности?

Идея с mapped types хороша. А я даже и не знал про эту фичу.

А где прописать что б тайпскрипт не компилился если tslint ругается на ошибки?

Вообще это возможно?

А как ты его компиляешь?

Ну, вебпак там, нпм-скрипт или что ещё?

Вебпак

А вебпак руками вызываешь?

да

Сходу нагуглилось такое: - https://www.npmjs.com/package/tslint-loader - https://www.npmjs.com/package/tslint-webpack-plugin

Я бы сам, наверное, побоялся tslint на каждом билде делать. Это не так быстро, как хотелось бы.

Спасибо, почитаю

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

Вообще это возможно?

Да

Поэтому я на CI прикрутил tslint, ну и пул-реквесты проверяю им.

Я не вижу вообще разницы в скорости