И еще можно както указывать контекст вызова. Например при создании классов на прототипах, ts ничего не знает об this

можно подробнее, что ты понимаешь под контекстом вызова

ну и this: YourFunc

ну и this: YourFunc

хотя вроде не сработает

можно подробнее, что ты понимаешь под контекстом вызова

Ну чтоб ts знал о this.

хотя вроде не сработает

ок попробую

а где он не знает?

а где он не знает?

https://www.typescriptlang.org/play/index.html#src=function%20F()%20%7B%0D%0A%0D%0A%7D%0D%0A%0D%0AF.prototype.a%20%3D%20function%20()%20%7B%0D%0A%7D%0D%0A%0D%0AF.prototype.b%20%3D%20function%20()%20%7B%0D%0A%20%20%20%20this.a()%3B%0D%0A%7D

f

Foo.prototype.bar = fubction(){тут}

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

Ну так классы на прототипах) если приспичит

Изначально я думал что это решит мою проблему

не делайте так, короч

В продных классах то всё ок

а он так и делает

В продных классах то всё ок

?

а он так и делает

Делает что?

Сейчас.

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

первое, тайпа делает классы же теми же прототипами

http://www.typescriptlang.org/play/#src=class%20MyClass%20%7B%0D%0A%20%20%20%20prop%3A%20number%20%3D%200%3B%0D%0A%20%20%20%20qq()%20%7B%20%0D%0A%20%20%20%20%20%20%20%20this.prop%3B%0D%0A%20%20%20%20%7D%0D%0A%7D

второе, как можно выкручиваться если ты хочешь чтобы он знал кто там this будет http://www.typescriptlang.org/play/#src=function%20F()%20%7B%0D%0A%7D%0D%0A%0D%0AF.prototype.a%20%3D%20function%20()%20%7B%0D%0A%7D%0D%0A%0D%0AF.prototype.b%20%3D%20function%20()%20%7B%0D%0A%20%20%20%20let%20self%3Atypeof%20F%20%3D%20this%3B%0D%0A%20%20%20%20self.a()%3B%0D%0A%7D

Ок, попробуем

вообще не стоит такое пробовать

А у себя в проектах можно? Я тихонько)

голосом бабушки: "Будешь много в свою приставку играть - кинескоп сядет!"

можно-то можно, но вооще это странно

А что странно, прототипы?

нет, за тебя тайма их и так сделает

не стоит это руками самому писать

http://www.typescriptlang.org/play/#src=class%20MyClass%20%7B%0D%0A%20%20%20%20prop%3A%20number%20%3D%200%3B%0D%0A%20%20%20%20qq()%20%7B%20%0D%0A%20%20%20%20%20%20%20%20this.prop%3B%0D%0A%20%20%20%20%7D%0D%0A%7D

посмотри этот код

там справа то, во что оно скомпилится

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

Да с этим то ясно понятно, но вот когда в классе имеются динамические методы в es6 классах такого не сделать, или это не так..

computed prop?

хотя наверное не стоит

вообще непонятно на самом деле, если у вас что-то динамическое, то это не для статического анализатора типа ts

Не ну если использоват тс то везде

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

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

А то постоянно приходитсч tools.ts создавать

В новых пректах

Всем привет, подскажите, на ноде не могу импортить json

линтер говорит что нет такого модуля

import * as config from ("./config")

А то постоянно приходитсч tools.ts создавать

ну вы что-то делаете не так, наверное

import * as config from ("./config")

а он подключается?

после компиляции содержимое доступно nodejs?

и ты webpack используешь или нет?

а он подключается?

у меня стоит moduleResolution node, я пологаю из за этого у меня компилится в стандартный require

после компиляции доступен

попробуй что то вроде config.json.ts создавать, с пустым импортом или декларацией. А так я хз, эти методы для вебпака предлагались

ну я решил пока просто в ts положить

вроде как require должен сработать

const config = require("./config.json")

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

какую?

ребят кто дружил paths в тс конфиге с вебпаком?

забавная штука https://github.com/Microsoft/TypeScript/issues/13500

ребят кто дружил paths в тс конфиге с вебпаком?

у нас примерно подружено

условно есть фолдер где то глубоко с 10 файлами тс. 1.ts, 2.ts, 3.ts и так далее. я пишу алиас к фолдеру paths: { "files/*": ["path/path2/path3/*"] } после чего я хочу импорты вида import { someVar } from 'files/1'; например Но вебпак будет ругаться на то что не может зарезолвить модуль files/1. Вопрос как прописать алиасы правильно и не ко всем 10 файлам по отдельности, это вообще возможно?

modulesDirectories в вебпаке?

alias: { "files": path.join(__dirname, "path/to/path/path2") }

alias: { "files": path.join(__dirname, "path/to/path/path2") }

спасибо!

Подскажите, зачем нужны .d.ts файлы, пока не вкуриваю

ERROR: S client not available

для типизации ваших js модулей

забавная штука https://github.com/Microsoft/TypeScript/issues/13500

а у вас нет такой же но с надписью типа ВИА Godspeed you! black emperor

а?

Привет! Вчера спрашивал про paths и алиасы. Есть еще вопрос по той же теме

Предположим что у меня 2 папки и я пишу патчс: paths: { "files/*": [ "path/path2/path3/*", "path1/path2/path3/*" ] } ts это прекрасно понимает, а вот как научить вебпак с этим дружить?

alias: { "files": path.join(__dirname, "path/to/path/path2") }

?

так разные пути ведь

https://www.reaktor.com/blog/refactoring-30000-lines-js-types/

https://www.reaktor.com/blog/refactoring-30000-lines-js-types/

Выбрали тс, потому что он меньше ошибок репортил на старте ?

https://t.me/coder_goodies

А кто-нибудь уже типизировал синтаксис запросов к #ElasticSearch для #Flow? Или уже может есть где-то?

Очень нужна прям строгая проверка.

проверки же только на стадии сборки

а не рантайм

Ну так видимо на этапе компиляции передаваемые в эластику параметры

Структуру запроса

Дада. Есть инит-скрипты, которые пихают в базу довольно сложный конфиг разного рода отчётов. Результат особо не потестируешь в автоматическом режиме. А тайпчекинг решил бы вопрос почти полностью.

При этом количество конфигов постоянно растёт.

> @bigslycat Результат особо не потестируешь в автоматическом режиме. эт почему?

> @bigslycat Результат особо не потестируешь в автоматическом режиме. эт почему?

Потому, что результат — это ответ из эластик, и он мокается.

так не мокай

запусти эластик и проверь

Эмм... Так данные...

Там их дофигища. Как проверять результат-то?

Чисто структуру?

Тестовые данные

Они есть. Всё равно, много. Суть в том, что при таком кейсе прогнозировать конечные значения бессмысленно. Мне ведь нужно просто проверить валидность запроса в эластик. А тестирование того, насколько я его составил правильно касаемо конкретной задачи, — это ведь совсем другой таск, по сути, более проблемный и менее приоритетный.

От тайпчекинга я в данном случае хочу получить профит в виде контроля за написанием кода разработчиками именно в реальнов времени (проверка и автокомплит).

Чтобы ещё до запуска тестов разработчик был уверен в валидности синтаксиса запроса.

это понятно, но тесты это не заменяет на 100%

Да, я согласен.

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