не знал, спасибо

пожалуйста ))

резюмирую: class SomeClass1 { constructor() { this.asyncComplete = new Promise((resolve) => { setTimeout(() => { resolve('SomeClass1 async work complete'); }, 1000); }); } } const obj = new SomeClass1(); obj.asyncComplete.then((value) => { console.log(value); });

Можно асинхронный конструктор) `await new World`

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

да, это больше про cancel tokens, try/else, unhandledrejection

они там явно пишут: The discussions here are independent of how the promise gets canceled, whether via a "task" subclass approach (as previously contemplated) or via the "cancel token" approach (as the rest of this repository assumes). The question is more about once a promise gets canceled, how that state is represented and propagates throughout the rest of the program.

вот даже в примерах: A more serious example of this in action is the following, where we assume various Fetch-related APIs have been modified to accept a cancel token as an option:

try { const response = await fetch("https://example.com/lotsojson.json", { cancelToken }); const data = await response.json({ cancelToken }); const text = await fetch(data.otherURL, { cancelToken }); updateUI(text); } else (e) { showUIError(e); } и фетчу везде суют этот токен, типа он сам знает как с ним работать у CancelToken есть requested и promise: The primary use of the .promise property is in adapting old APIs which are not cancel-token friendly. (With cancel-token-friendly APIs, you can simply pass them the cancel token) (как в примере выше с фетчем). и там сразу пример для xhr: function xhrAdapted(url, { cancelToken } = {}) { return new Promise((resolve, reject) => { const xhr = new XMLHttpRequest(); xhr.addEventListener("load", () => resolve(xhr.responseText)); xhr.addEventListener("error", () => reject(new Error("could not XHR"))); if (!cancelToken) return; cancelToken.promise.then(cancelation => { reject(cancelation); xhr.abort(); }); }); }

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

да) кроме try/else и unhandledrejection, хотя try/else весьма странная хрень

https://djcordhose.github.io/flow-vs-typescript/2016_hhjs.html#/

https://djcordhose.github.io/flow-vs-typescript/2016_hhjs.html#/

во втором есть strictnullchecks

там старый тайпскрипт сравнивается https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in-TypeScript

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

во втором есть strictnullchecks

да видел

Всем привет, а кто-нибудь заводил jsdoc с typescript?

для бека на ноде

надо попробовать...

а может быть swagger кто-нибудь использовал?

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

Поищи По этому чату, тут было 100%

пролистал все, что мог, если у кого-то знает как завести typedoc/swagger вообще любые доки на тайпскрипте, пните пожалуйста :)

Было про генерацию доков в ангуляре. Dgeni вроде

Всем привет. Есть проблема, может кто что посоветует. Бывает такая активная фаза разработки когда ты одновременно разрабатываешь какой-то отдельный модуль и приложение которое его использует (оба проекта на TS). Модуль допустим паблишится в npm и подключается в приложении как зависимость. В моем случае приложение на angular2 а модуль содержит в себе разнличные компоненты, например реализацию oauth2 для angular2. Получается что в обоих проектах Angular2 идет в зависимостях. Если подключать пакет через npm install то все нормально, npm резолвит зависимости, @anuglar/* появляется на верхнем уровне node_modules и все ок. Но как я уже сказал в условиях активной разработки это неудобно, поэтому я подключаю свой пакет локально через npm link в проект и тут начинаются конфликты. В node_modules/ появляется my_module/ внутри которого есть свой node_modules/ с @angular/* , получается дублирование зависимости ангуляра и TS начинает ругаться при компиляции в разных ситуациях, т.к при компиляции improt {MyNg2Module} from 'my_module'; внутри my_module import {*} from '@angular/http' лезет в свой вложеный node_modules/my_module/node_modules/@angular/http

получается что код моего приложения при import { Http } from '@angular/http' получает другую копию Http нежели код делающий то же самое внутри 'my_module'

не знаю понятно ли объяснил, в общем дело в том что при npm link в папке node_modules/my_module/ появляется вложеный node_modules

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

в compilerOptions я не нашел опции которая бы запрещала поиск пакетов глубже 1го уровня node_modules

кто сталкивался с такой проблемой? как решали?

Всем привет. Есть проблема, может кто что посоветует. Бывает такая активная фаза разработки когда ты одновременно разрабатываешь какой-то отдельный модуль и приложение которое его использует (оба проекта на TS). Модуль допустим паблишится в npm и подключается в приложении как зависимость. В моем случае приложение на angular2 а модуль содержит в себе разнличные компоненты, например реализацию oauth2 для angular2. Получается что в обоих проектах Angular2 идет в зависимостях. Если подключать пакет через npm install то все нормально, npm резолвит зависимости, @anuglar/* появляется на верхнем уровне node_modules и все ок. Но как я уже сказал в условиях активной разработки это неудобно, поэтому я подключаю свой пакет локально через npm link в проект и тут начинаются конфликты. В node_modules/ появляется my_module/ внутри которого есть свой node_modules/ с @angular/* , получается дублирование зависимости ангуляра и TS начинает ругаться при компиляции в разных ситуациях, т.к при компиляции improt {MyNg2Module} from 'my_module'; внутри my_module import {*} from '@angular/http' лезет в свой вложеный node_modules/my_module/node_modules/@angular/http

peerDependencies

И вместо npm link npm install ../module

Спасибо, попробую.

Но тут есть один момент.

Я просто при разработке использую установку и либу в peer и dev зависимостях.

С npm link наверное было бы удобнее работать, но тогда в любом случае будет конфликт.

Но есть одно решение, которое приходит на ум.

Поставить уровнем ниже папки с библиотекой, которая использует angular сам angular.

Т.к. лоадер модулей ищет по нисходяшей к корню.

Или вообще в global.

Попробовал npm install ../module

работает, но приходится запускать руками каждый раз когда редактируешь исходники ../module

а хочется watch-режим

но без симлинка его видимо не добиться

что возвращает нас к исходной проблеме

Поставить уровнем ниже папки с библиотекой, которая использует angular сам angular.

вот этот вариант не совсем понял

можно поподробнее?

можно поподробнее?

У тебя поиск модуля идет следующим образом: /home/projects/app/node_modules/module-name /home/projects/node_modules/module-name /home/node_modules/module-name /path/to/node/node_modules/module-name

Поэтому ты можешь удалить из module-name твою зависимость, оставить ее в peerDependencies, при этом глобально поставить твою зависимость. В итоге когда ты сделаешь npm link, у тебя твоя зависимость будет браться из node_modules проекта.

А когда ты будешь вести разработку модуля, то зависимость будет из глобала подгружаться.

Но это костыль, конечно.

Я разрабатываю модули через тесты и проблемы раз в день обновить npm install из регистри нет.

Народ, как тулзе typings свои тайпинги подсунуть?

то есть я могу сам в typings папку сам что-то написать? или она read-only предполагается?

а зачем тебе именно typings подсовывать?

положи в src или еще куда и подключи в files в tsconfig или в нужных модулях через директиву

А я вот в typings клал. Ну потому что это тайпинги) совсем не православно?

хм, может я чет не так делаю, но я просто создаю файлик refernces.d.ts в корне src проекта с таким содержанием: /// <reference path='../typings/index.d.ts'/> /// <reference path=‘./vendors.d.ts'/> /// <reference path=‘./globals.d.ts'/>

и потом просто ссылаюсь на него в entry point аппы /// <reference path='./references.d.ts'/>

но мб это какая-то старая херня и я все делаю не так? кто как делает сейчас?

у меня так же, но еще не обновлял, может по-другому будет

хм, может я чет не так делаю, но я просто создаю файлик refernces.d.ts в корне src проекта с таким содержанием: /// <reference path='../typings/index.d.ts'/> /// <reference path=‘./vendors.d.ts'/> /// <reference path=‘./globals.d.ts'/>

также и сделал

а вы typings коммитите?

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

вот у нас на одном typings в гит, а в других ставится на ci. Еще конечно хочется перейти на npm, но там в последний раз когда тестили было совсем негладко

и потом просто ссылаюсь на него в entry point аппы /// <reference path='./references.d.ts'/>

вроде можно еще в tsconfig в files добавить

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

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

да, про расширение уже подумал)

и еще вопросик) Как можно в объявлении функции указать, что она соответствует интерфейсу?

function middleware ({getState, dispatch}) => next => action => { // some code }; export default middleware : Middleware;

типо такого, но так не работает

const a: FunctionInterface = function ...

печально(

ну можно костыли типа const middleware: Middleware = someDeclaredFunction; :)

А через приведение не получится? <Middleware>function middleware() {} или как-то так

получается что код моего приложения при import { Http } from '@angular/http' получает другую копию Http нежели код делающий то же самое внутри 'my_module'

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

а вообще если перенести среду разработки в docker то там проще решается проблема с подставлением зависимостей со среды разработке

ну это уже из пушки по воробьям

спасибо всем за комментарии, как вывод - npm тут сильно проигрывает экосистемам других современных языков где таких проблем нет. Еще @izatop справедливо заметил что можно через тесты разрабатывать, возможно так и поступлю

то есть я могу сам в typings папку сам что-то написать? или она read-only предполагается?

Не нужнло туда ничего добавлять. typings не должна находиться в git и изменения в нее, соответственно, вносить не нужно. Если хотите что-то туда добавить, есть несколько вариантов через установку с github или пакета. В общих случаях достаточно положтить файл деклараций в файлах своего проекта.

хм, может я чет не так делаю, но я просто создаю файлик refernces.d.ts в корне src проекта с таким содержанием: /// <reference path='../typings/index.d.ts'/> /// <reference path=‘./vendors.d.ts'/> /// <reference path=‘./globals.d.ts'/>

Это устаревший с времени TSD подход. Достаточно включить в tsconfig.json в поле files typings/index.d.ts или не исключать в exclude папку typings и все будет хорошо.

Вопрос, vscode не из корня проекта подхватывает как-то tsconfig?

спасибо всем за комментарии, как вывод - npm тут сильно проигрывает экосистемам других современных языков где таких проблем нет. Еще @izatop справедливо заметил что можно через тесты разрабатывать, возможно так и поступлю

Надо сказать, что экосистема npm тут не виновата, а основная проблема в особенностях TS. Три системы управления зависимостями деклараций модулей за два года это вам не там)

Вопрос, vscode не из корня проекта подхватывает как-то tsconfig?

Должен из корня.

Должен это как? ) Это баг или фича?

window.devToolsExtension - как на это заставить перестать ругаться TS? На гитхабе увидел declare const window : any. Но какой-то такой себе вариант

declare global { interface Window { devToolsExtension: any; } }

Должен это как? ) Это баг или фича?

Почему это баг или фича? Это значение по-умолчанию.