ну конкретно чтобы tsc сам по себе что-то думал про tslint нельзя, но никто не мешает делать tslint && tsc

или там tslint && webpack

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

Ещё можно хук на Git push

ну или встраивать внутрь

или там tslint && webpack

Не

Конфига вебпака достаточно

думаю зависит

может кто-то хочет параллельно гонять

Конфига вебпака достаточно

Ты про этот плагин? https://github.com/wbuchwalter/tslint-loader

Ага

preLoaders: [ { test: /\.ts?$/, loader: 'tslint' } ], tslint: { failOnHint: true }, plugins: [

Сейчас попытаюсь к второму вебпаку прикрутить )

Там же синтаксис описания настроек поменяли, да?

Во втором только немного иначе конфиг надо прописывать) Но суть думаю понятна

ага, спасибо

http://stackoverflow.com/questions/39919793/tslint-loader-with-webpack-2-1-0-beta-25/39997947#39997947

Кстати, есть какие-то способы завести ts c import()?

не

Пользоваться System.import

Ждать пока MS придумают

Эх

Опять суперсет js протёк ?

Ок, хорошо хотя бы так

а import уже js?)

который function-like

почти

я кстати чет даж issue не нахожу

а, нашел https://github.com/Microsoft/TypeScript/issues/12364

Кстати, есть какие-то способы завести ts c import()?

https://github.com/Microsoft/TypeScript/issues/12364#issuecomment-270819757 костылики

еее регекспы

Ура! Все отваливается! )

В смысле, tslint-loader работает )

Ух, сколько сейчас исправить пришлось что б соответствовать правилам ) В общем, tslint-immutable работает, и это вещь!

Не нужно никакого immutable.js! )

Ну кстати immutable.js не поэтому нужен

У меня тс как то странно валился на выражении const immutableAdd = (state, object) => ({ ...state, [object.id]: object })

В итоге чтобы нормально работать, надо было или рамду или immutable.js

Странно

Очень

Ну это уже дело в глюках

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

Ну и понятно что иммутабл нужен еще для динамического контроля иммутабельности. Но я такой потребности пока не имею

У меня тс как то странно валился на выражении const immutableAdd = (state, object) => ({ ...state, [object.id]: object })

ща не сработает, потому что spread не работает с генериками

а вообще any ж просто проставляет и все, не загоняется)

Парни, объясните в чем смысл такой записи: let tom: User = new User(2, "Denis");. Чем это лучше, чем так: let tom = new User(2, 'Denis');

Э, ну ведь User и Something это два разных типа.

new User() и new Something() это воще две разных конструкции.

тут что то с Interface`s связано

Может быть и связано, но пока вопрос непонятно поставлен — вроде как, в данном случае аннотация типа к вопросу не относится.

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

Ну да, я перепутал

Вот сейчас подправил

А.

Ну, тут разницы никакой нету между строчками, имхо.

Просто первая запись для меня как-то очень странно выглядит

Разве что если вдруг в будущем захочется поменять что-нибудь, как то let tom: User = new UserDerivedType();

http://metanit.com/web/typescript/3.2.php ну вот это руководство читаю и там везда объекты так объявляются

Вот смотрите первый пример let bill: Employee = new Employee("Bill"); bill.getInfo(); bill.company = "Microsoft"; bill.work();

И снова вот так: let bill: Employee = new Employee("Bill");

Мб это специально для мануала стиль такой выбран? Чтоб читателю всегда был виден выведенный тип переменной?

Короче, в данном конкретном случае у этого стиля никакого смысла нету. В настоящем коде я не видел, чтобы именно так кто-то писал.

Для полей класса или каких-то ещё случаев это может пригодиться, но для локальной переменной вряд ли.

Ок

Элвис-оператор предлагают https://github.com/Microsoft/TypeScript/issues/16

Элвис-оператор предлагают https://github.com/Microsoft/TypeScript/issues/16

Вряд ли нужен, когда есть strictNullChecks

runtime проверка?

Да, этот issue старый, до strictNullChecks создан был

ERROR: S client not available

Короч все сейчас зависит от прогресса в tc39

Но все равно смысла мало кмк

в ruby есть, в rust есть

теперь в es предлагают.

Да, это понятно, но мне кажется, что скорее вредный оператор

Ну не факт

отличный оператор помоему

упрощающий, но сам подход таких проверок не редкость, хоть и вреден

когда в шарп добавили это было просто щикарно

Если не затыкать им косяки в архитектуре, то вполне нормально

особенно при работе с лямдами на базу

Прост имея strictNull можно явно отделить нулы от не нулов и тогда оператор просто не нужен

Прост имея strictNull можно явно отделить нулы от не нулов и тогда оператор просто не нужен

Если у меня большая многократно вложенная nullable структура, то как по другому с ней ещё обращаться?

можно на примере?

Например протокол телеграма просто не шлёт кучу опциональных полей, если они не нужны, и для многих кейсов достаточно узнать что поля media.user.photo.id просто нет и не важно какого именно поля в пути не было

что значит "если не нужны"?

просто даже в этом варианте: if (hasPhoto(media.user)) { return renderPhoto(media.user.photo); }

У тебя не может быть абсолютно любого объекта в пути

chat.message.media.user.photo.id

Сообщение может быть без медиа, может быть не от юзера, может быть не от юзера с фото и т.д.

так и что? Если ты обрабатываешь весь объект chat в одном месте, то ты уже проиграл

Это не принципиально

а так, ты передал куда-то чисто media

если оно было

там уже проверки только для медиа

и в итоге нет никакой нужды в элвисе

Протокол телеграма — это как GraphQL, только наоборот, лол

а так, ты передал куда-то чисто media

Ну короче в итоге у тебя получится media && media.user && media.user.photo && media.user.photo.id только распиленный по функциям

ну это в общем-то принципиально

что это заставляет меня немного думать о декомпозиции

что это заставляет меня немного думать о декомпозиции

хах ну да лучше, ага hasAttachment(chat.message) -> hasPhoto(message.user) -> ->getPhoto(user.photo)

У меня так есть