Definitelytyped: bluebird 3.0: 글로벌 Promise의 오버로드로 사용하는 방법은 무엇입니까?

글쎄요 IMHO의 이전 Bluebird 정의도 좋은 솔루션이 아니었습니다. 왜냐하면 전역 네임스페이스에 많이 누출되었고 중복 작업을 줄이는 것이 좋은 아이디어라고 생각하기 때문입니다.

이전 정의가 작동하는 방식은 declare var Promise: PromiseConstructor; 를 정의하는 반면 PromiseConstructor 는 이전(전역적으로 정의된) Bluebird 인터페이스였습니다.

즉, 로컬 *.d.ts 파일을 만들고 이와 같은 것을 추가하면 작동할 수 있습니까?

import Bluebird = require("bluebird");
declare var Promise: Bluebird<any>;

아마도 작동 할 수 있습니까?

불행하게도. 다음과 같이 작성된 코드가 많기 때문입니다.

declare function doLoadData(): Promise<Data>

보시다시피 함수는 Promise<T> 를 반환합니다. 이는 bluebird가 아닌 표준 Promsie 입니다. var Promise: Bluebird<any> 선언 인터페이스가 아닌 표준 Promise 생성자를 오버로드합니다.

이러한 이유로 2.0 타이핑으로 다시 전환했습니다.

@Strate 아 젠장, 이것에 대해 어떻게 생각하고 무엇을 해야 하는지에 대해 긴 코멘트를 썼습니다. 그런데 제출을 깜빡해서 결국 잃어버렸네요...

많은 사람들이 이 문제를 겪고 있는 것 같습니다.

문제를 보여주는 리포지토리를 만들었습니다. https://github.com/d-ph/typescript-bluebird-as-global-promise

자식 복제 && npm install && npm run tsc

문제:
타사 d.ts 파일은 Promise 에 대해 입력됩니다. 이 Promise 는 typescript의 lib.es6.d.ts ( "target": "es6" 때) 또는 다른 라이브러리(예: core-js , typescript로 es5로 컴파일할 때 매우 인기 있음)에 의해 정의됩니다. . 최신 bluebird.d.ts 는 전역 Promise 로 선언되지 않습니다. bluebird.js가 자신을 전역 Promise 로 노출하더라도.

결과:
개발자는 타사 코드에서 반환된 약속에서 블루버드의 기능을 사용할 수 없습니다(컴파일 실패).

예상 결과:
개발자는 타사 코드에서 반환된 약속에서 블루버드의 기능을 사용할 수 있습니다(컴파일 성공).

누가 블루버드 타이핑의 관리자인지 확실하지 않습니다. @lhecker , 당신은 git blame 에 의해 반환되는 불운한 사람입니다. 위에서 링크한 github 프로젝트가 컴파일되는 방식으로 블루버드 타이핑을 사용하는 이유가 무엇인지 알려주실 수 있습니까?

현재 해결 방법:

1. 가장 더러운. 절대 블루버드를 가져오지 말고 블루버드 타이핑을 사용하지 마십시오. bluebird Promise 함수의 경우 Promise["config"]({}); Promise.resolve("foo")["finally"](() => { console.log("lol"); }) 를 사용하여 컴파일러를 침묵시킵니다. 즉, 배열 액세스 연산자를 사용합니다. [""]
2. 더럽고 짜증나. 애플리케이션의 모든 항목 ts 파일에 다음 두 줄을 추가합니다.

import * as Bluebird from 'bluebird';
declare global { export interface Promise<T> extends Bluebird<T> {} }

Bluebird의 정적 함수의 경우 $#$ Promise.config({}) Bluebird.config({}) 를 사용하십시오.

단점은 IDE가 이 해킹을 올바르게 해석하는 데 어려움을 겪는다는 것입니다.

흠... 여러분 모두가 저와 다른 많은 사람들이 하지 않는 방식으로 Bluebird를 사용하고 있기 때문에 여러분이 이것에 문제를 겪을 것이라는 것은 저에게는 다소 예상치 못한 일이었습니다. 사실 제가 직접 타이핑도 안썼어요! 여기 에서 3.0에 대한 유일한 기존 항목을 복사했습니다. 3.0에 대해 입력하는 것이 없는 것보다 낫기 때문입니다. 그렇죠?

문제는 현재 TypeScript가 향하고 있는 방향이 분명히 modules > globals 라는 점입니다. 이는 제가 정말로 찬성하는 것입니다. 그러나 이것은 또한 모듈이 전역 개체를 수정해서는 안 된다는 것을 의미합니다. 특히 Bluebird 가 모든 경우에 전역 Promise 를 대체 하지 않는다는 것을 고려하는 경우에 그렇습니다! 또는 그렇게 표현하려면:

Promise.noConflict() 를 말 그대로 코드의 아무 곳에서나 호출하면 "유형 안전성"은 어떻게 됩니까? tsc 가 모든 것이 괜찮다고 말하더라도 전역 Promise 유형을 원래 유형으로 되돌리고 코드 충돌을 일으킬 것입니다.

네... @d-ph. 두 번째 해결 방법은 모듈 시스템의 정신에 있기 때문에 항상 수행해야 한다고 생각해야 하는 것입니다. 그러나 이것이 라이브러리에 대한 이상적인 솔루션일 뿐이라는 것을 알고 있습니다. 반면 애플리케이션에는 _할 수 있습니다_. 나는 응용 프로그램 시스템이 최소한 전역 Promise 개체를 대체할 수 있어야 하고 2.0에서 사용할 수 있었던 해당 사용 사례에 대해 일치하는 유형을 가질 수 있어야 한다는 데 동의합니다.

결국 TypeScript의 이데올로기에 비추어 글로벌 Promise 유형을 확장하는 것은 _매우_ 신중하게( noConflict() 문제 등을 기억해야 함), 그럴 경우에만 옵트인해야 한다고 생각합니다.

IMO 앞으로의 방법은 bluebird.d.ts 파일에 있는 동일한 인터페이스 선언을 사용하여 전역 Promise 개체를 확장하는 일종의 bluebird-global.d.ts (또는 이와 유사한) 파일을 작성하는 것입니다. 그리고 그것들을 사용해야 하는 경우 항상 포함하는 대신 명시적으로 가져와야 합니다. 그렇게 하면 대부분의 사용 사례, 특히 라이브러리를 작성할 때 안전한 _및_ 올바른 입력을 할 수 있으며 애플리케이션에서 전역 Promise 를 덮어쓰는 추가 이점에 액세스할 수 있습니다.

이 아이디어가 좋은 아이디어라고 생각하고 여유 시간이 있다면 PR을 작성할 수 있다면 좋을 것입니다. 나는 많은 사람들이 그러한 기여에 대해 정말로 기뻐할 것이라고 확신합니다. 🙂

나는 시간이 부족하고 현재 그런 타이핑이 필요하지 않기 때문에 현재 그런 타이핑을 쓸 수 있는 위치에 있지 않기 때문에 이런 식으로 표현하고 있습니다. 나는 당신이 그것을 이해할 수 있기를 바랍니다.

@lhecker 나는 당신에게 동의 할 수 있다고 생각합니다. 왜냐하면 우리가 블루버드에 대한 Promise의 전역 재정의를 가지고 있다면 우리는 실제 세계가 아닌 typescript 컴파일러만 해킹할 것이기 때문입니다. 예를 들어 Promise 재정의를 사용하면 typescript는 fetch 가 bluebird의 것을 반환한다고 생각합니다.

import `whatwg-fetch`;
let result = fetch("anyurl"); // this is NOT bluebird promise, but typescript think that it is.

fetch 를 bluebird의 Promise.resolve 로 래핑하지 않으면 $#$ result 에 대한 .finally 메소드를 얻을 수 없습니다.

import `whatwg-fetch`;
fetch("anyurl").then().finally() // goes to runtime error with overriden global promise, but should be compile error.

따라서 각 사용에 대해 명시적으로 bluebird 를 가져오는 것이 더 나은 솔루션이라고 생각합니다.

import Promise from "bluebird";
import `whatwg-fetch`;
Promise.resolve(fetch("anyurl")).then().catch() // no compile error, no runtime error

내 코드를 리팩토링할 것입니다.

@lhecker님 , 답변 감사합니다.

나는 당신이 말한 모든 것에 동의합니다. 그리고 저는 @Strate 의 Promise.resolve() 메서드로 타사 코드를 래핑하여 es6 약속을 Bluebird(또는 Bluebird를 Bluebird로 변환하는 것)를 좋아합니다. 왜냐하면 저는 Bluebird의 약속을 런타임에 전역적으로 유지하고 싶기 때문에 그렇게 하지 않습니다. 오류를 올바르게 처리하기 위해 타사 코드에 의존할 필요가 없지만 이는 요점을 벗어납니다.

제대로 하는 방법을 몰랐던 것 같습니다. 다른 사람들이 이 문제를 처리하는 방법에 대한 더 많은 문서가 도움이 될 것이라고 생각하는 것은 브라우저 프로그래밍 세계(nodejs/typescript와 반대)에서 오는 모든 사람들이 다음과 같은 후에 문제를 일으키기 때문입니다.

1. npm install <absolutely everything that uses es6 promise>
2. npm install bluebird @types/bluebird
3. typescript와 함께 타사 코드 사용

또한 나중에 참조할 수 있도록 이 "제3자 코드가 es6 Promise에 대해 입력된 경우 사용 방법" 섹션이 문서화되어 있으면 도움이 됩니다. 즉

import * as Bluebird from 'bluebird';
declare global { export interface Promise<T> extends Bluebird<T> {} }

그리고

import * as Promise from 'bluebird';
import { Observable } from "rxjs";

let observable = Promise.resolve(new Observable<number>().toPromise());

readme 또는 bluebird.d.ts 파일 상단의 문서 블록에서.

어떻게 생각해?

Promise 의 전역 재정의에서 bluebird 것으로 이동하는 작업을 완료했으며 타사 라이브러리가 bluebird의 것으로 간주되었던 ES6 Promise를 반환하는 몇 가지 문제를 발견했습니다. 그래서 그 움직임으로 내 코드베이스도 정리되었습니다. Promise 의 글로벌 오버로딩에서 벗어나는 것이 좋습니다. 건배 :)

나는 modules > globals 를 이해하지만 논쟁(및/또는 현실)을 위해 내가 대형 브라우저 SPA에서 작업하고 있으며 Bluebird를 Promise 폴리필로 사용하는 임무를 받았다고 가정해 보겠습니다.

@d-ph의 내용으로 @lhecker 가 제안한 bluebird-global.d.ts 수정을 시도하고 있습니다.

import * as Bluebird from 'bluebird';
declare global { export interface Promise<T> extends Bluebird<T> {} }

$ typings/modules/bluebird-global/index.d.ts typings 를 통해 설치했습니다.

// Generated by typings
// Source: src/bluebird-global.d.ts
declare module 'bluebird-global' {
// via https://github.com/DefinitelyTyped/DefinitelyTyped/issues/10801
import * as Bluebird from 'bluebird';
global { export interface Promise<T> extends Bluebird<T> {} }
}

그러나 모든 것을 빌드하려고 하면 TypeScript(v1.8.2)가 다음과 같이 불평합니다.

ERROR in /path/to/typings/modules/bluebird-global/index.d.ts
(6,27): error TS2665: Module augmentation cannot introduce new names in the top level scope.

ERROR in /path/to/src/bluebird-global.d.ts
(2,35): error TS2665: Module augmentation cannot introduce new names in the top level scope.

global-modifying-module.ts 에 대한 MS 예제를 살펴보았습니다.
https://www.typescriptlang.org/docs/handbook/declaration-files/templates/global-modifying-module-d-ts.html

그리고 이 오류 메시지와 관련된 TS 문제
https://github.com/Microsoft/TypeScript/issues/6722

그러나 나는 내가 해야 할 일을 잃어버렸습니다. 누구든지 도울 수 있습니까?

안녕.

문제와 해결책을 보여주는 내 repo를 확인해 주시겠습니까? 링크 . 제 3자의 모든 약속을 bluebird의 Promise 생성자로 래핑하기로 결정할 때까지 저는 그것에 매우 만족했습니다. 이것이 제가 지금 하는 일입니다. 추가 정보의 단계를 수행한 후에는 컴파일할 수 없지만 주석 처리를 제거한 후에는 확인하시겠습니까?

// declare global {
//     export interface Promise<T> extends Bluebird<T> {}
// }

그것은 컴파일?

내 repo는 TS 2(지금은 안정적임)를 사용하고 당신은 1.8.2를 사용하고 있다고 말했습니다. TS를 2로 업그레이드하면 어떤 일이 일어나는지 확인하십시오.

마지막으로 내 솔루션을 전역 d.ts 파일에 넣는 데 몇 가지 문제가 있었습니다. 나는 그것을 내 webpack 컴파일의 모든 진입점에 추가하여 결국 문제를 해결했습니다. 나는 당신의 js 설정을 모르지만 컴파일 중에 실패하는 모든 파일(또는 그 중 적어도 하나)에 내 수정 사항을 넣고 도움이되는지 확인할 수 있습니까?

또한 Bluebird의 Promise 구현을 전역 Promise 로 "등록"할 수 있기를 원합니다. 이 스레드 전체를 읽었지만 한 부분을 따르지 않습니다. 타사 라이브러리가 여전히 기본(예: Bluebird가 아닌) Promise 구현을 반환할 것임을 제안하는 부분입니다. 제3자 코드가 전역 수준에서 Bluebird 구현으로 대체된 Promise 생성자( new Promise(...) )를 호출하는 경우 어떻게 될까요?

<script src="//.../bluebird.min.js"></script>
<script>
    var promise = fetch("some url");

   promise.finally(...); 
</script>

기본 Promise 구현을 대체한 Bluebird를 포함했기 때문에 이것이 제대로 작동해야 하지 않습니까?

마지막으로, 런타임에 이 전체 전역 교체를 수행하는 경우 TypeScript에 이를 알려 컴파일 시간에 모든 Promise도 Bluebird로 교체되도록 할 수 있어야 합니다.

내가 무엇을 놓치고 있습니까?

만약 당신이 dist 버전의 bluebird를 사용한다면(당신이 하는 것입니다), 글로벌 Promise는 이제 Bluebird이기 때문에 제3자 라이브러리는 Bluebird를 사용할 것입니다. 이 부분이 맞습니다. 사람들은 Bluebird의 node.js 사용법에 대해 이야기하기 때문에 다르게 언급합니다.

이 전체 스레드는 ts를 그 가정(글로벌 Promise는 Bluebird임)으로 컴파일하는 그다지 명확하지 않은 방법에 관한 것입니다. (예를 들어 declare global {} 를 통해) 그것을 할 수 있었다면, 당신은 끝난 것입니다.

@d-ph 하지만 제 결론은 한 번이 아니라 모든 *.ts 파일에서 수행해야 한다는 것입니다. 맞나요? 아마도 이 문제에 대한 최종 "해결책"에 대한 요약이 좋을 것입니다. :)

예, 여기에는 간단한 just copy&paste this line to your X file and everyone and their dog are happy now 종류의 솔루션이 없습니다. 아니면 적어도 나는 그것을 알지 못합니다.

내가 마지막으로 당신을 확인했을 때:

1. import * as Bluebird from 'bluebird'; declare global { export interface Promise<T> extends Bluebird<T> {} } 행을 모든 진입점 *.ts 파일에 복사하여 붙여넣거나
2. Bluebird의 생성자 함수에서 타사 코드에서 반환된 모든 Promise를 래핑합니다. 런타임에는 아무 것도 하지 않으며(불필요한 런타임 오버헤드 제외) 컴파일 시간에는 TS를 만족스럽게 만듭니다.

다시, 솔루션 1. 모든 파일이 아니라 진입점 파일에만 해당 코드를 넣어야 합니다. 적어도 이것은 나를 위해 일한 것입니다 (webpack + Awesome-typescript-loader).

말 그대로 개발자가 한 파일에 한 줄만 넣어야 하는 다른 솔루션을 찾으면 커뮤니티와 공유하십시오 ;p

@d-ph 감사합니다 -- "모든 진입점 *.ts 파일"이 의미하는 바를 확인할 수 있습니까?

응. "진입점" .ts 파일은 <script> 태그를 통해 html에 로드하는 .ts 파일입니다. 즉, 컴파일이 시작되는 파일입니다.

지금 빠른 인터넷 검색 끝에 이것을 찾았 습니다 (읽는 것을 귀찮게 하지 마십시오). 결론은 bluebird.d.ts에 global { export interface Promise<T> extends Bluebird<T> {} } 를 수동으로 추가하면 다른 곳에서 다시 언급할 필요가 없다는 것입니다. 지금은 테스트할 시간이 없지만 제가 만든 테스트 github repo로 테스트를 해보니 잘 되는 것 같습니다.

즉, bluebird.d.ts를 다운로드하고 다음을 변경합니다.

// Generated by typings
// Source: bluebird.d.ts
declare module 'bluebird' {
// Type definitions for Bluebird v3.x.x
// Project: http://bluebirdjs.com

class Bluebird<R> implements Bluebird.Thenable<R>, Bluebird.Inspection<R> {

이에:

// Generated by typings
// Source: bluebird.d.ts
declare module 'bluebird' {
// Type definitions for Bluebird v3.x.x
// Project: http://bluebirdjs.com

global { export interface Promise<T> extends Bluebird<T> {} }

class Bluebird<R> implements Bluebird.Thenable<R>, Bluebird.Inspection<R> {

분명히 이것은 이상적이지 않습니다. 특히 @types/bluebird (사용자 정의 해킹된 bluebird.d.ts를 사용하기 때문에 지금 제거해야 함)를 사용하는 경우에는 적합하지 않지만...

그래서 이미 _stubs.d.ts 파일에 다음을 추가했고 훨씬 더 가깝습니다. finally not exist on Promise 에 대한 불만은 더 이상 없지만 어떤 이유로 delay not Existing on Promise 에 대한 오류가 계속 발생합니다. bluebird.d.ts 를 수정할 필요가 없었습니다. 조사하겠지만 이것은 훌륭한 해결책이 될 수 있습니다!

declare module "bluebird-global" {
    import * as Bluebird from "bluebird";

    global { export interface Promise<T> extends Bluebird<T> { } }
}

편집: delay Promise.delay(2000) 같이 정적으로 호출했기 때문입니다.

위에 게시한 솔루션을 사용하면 내 함수가 Promise<T> 를 반환할 때 이 오류가 발생합니다.

오류 TS2322: '블루버드' 입력'은(는) '약속' 유형에 할당할 수 없습니다.'.

Promise 를 Bluebird 로 바꿨기 때문에 then 등을 사용할 때마다 반환 값이 대신 Bluebird<T> 이기 때문인 것 같습니다. Promise<T> 중 .

여기 이 해킹의 최종 버전이 있습니다. 나는 이것을 하는 것을 좋아하지 않지만 다른 옵션보다 더 좋아합니다. 기본적으로 인터페이스에서 사용 중인 것을 다시 반복해야 하며 반환 유형을 $#$ Bluebird Promise 로 변경해야 합니다. 이것은 다른 Bluebird 정의 파일에서 직접 복사하여 붙여넣은 것입니다.

_stubs.d.ts

declare module "bluebird-global" {
    import * as Bluebird from "bluebird";

    global {
        export interface Promise<T> extends Bluebird<T> {
            then<U1, U2>(onFulfill: (value: T) => U1 | Bluebird.Thenable<U1>, onReject: (error: any) => U2 | Bluebird.Thenable<U2>): Promise<U1 | U2>;
            then<U>(onFulfill: (value: T) => U | Bluebird.Thenable<U>, onReject: (error: any) => U | Bluebird.Thenable<U>): Promise<U>;
            then<U>(onFulfill: (value: T) => U | Bluebird.Thenable<U>): Promise<U>;
            then(): Promise<T>;

            finally<U>(handler: () => U | Bluebird.Thenable<U>): Promise<T>;
        }
    }
}

기존 정의와 매우 유사하지만 Bluebird 대신 Promise 를 사용하는 공식 bluebird-global 또는 bluebird-override 정의가 있으면 좋을 것입니다.

해결책을 찾으셨다니 다행입니다.

완전성을 위해: @ProTip 이 말했듯이 bluebird-2.0.d.ts JustWorksTM를 사용합니다. npm install @types/[email protected] 로 설치하고 tsconfig.json의 compilerOptions.types 에 추가하기만 하면 됩니다.

{
    "compilerOptions": {
//     (...)
        "types": [
          "bluebird"
        ]
    },
    "include": [
        "src/**/*.ts"
    ]
}

해당 .d.ts와 현재 Bluebird 버전(즉, 3.x) 간의 차이점은 수동으로 해킹하는 것이 좋습니다.

JustWorksTM의 의미는 다음과 같습니다.

a) es5 대상
b) es6 대상
c) core-js 라이브러리가 있는 es5 대상

누군가가 빌드 설정(webpack + Awesome-typescript-loader)을 사용하는지 여부에 관계없이. 또한 PhpStorm IDE는 전혀 혼동되지 않습니다.

오늘 시간을 할애하여 이 문제를 살펴보고 실제로 Microsoft/TypeScript에서 해당 두 티켓을 생성/업데이트했습니다. https://github.com/Microsoft/TypeScript/issues/10178 및 https://github.com/Microsoft/TypeScript /이슈/12382 . 내 생각은 당신이 말했듯이 (그리고 당신보다 먼저) bluebird-global.d.ts 파일이 필요하다는 것입니다. 중복 코드를 피하기 위해 다음과 같이 작동한다는 것을 알았습니다.

// bluebird-global.d.ts

import * as Bluebird from "bluebird";

export as namespace Promise;
export = Bluebird;

앞서 언급한 두 티켓이 해결되거나 해결 방법을 찾은 경우에 한합니다. 그 동안 브라우저용으로 코딩할 때 bluebird-2.0.d.ts를 사용하는 것이 좋습니다.

@JoshMcCullough

제3자 코드가 전역 수준에서 Bliebird 구현으로 대체된 Promise 생성자(new Promise(...))를 호출할 때 어떻게 될까요?

꽤 쉽습니다. 브라우저의 콘솔에서 시도하십시오(Chrome 선호):

var NativePromise = Promise;
window.Promise = function() {}; // try to overload NativePromise
NativePromise === Promise; // false. Seems it is overloaded!
// And now, let check with some native code, which return Promise, for example fetch
Object.getPrototypeOf(fetch("")) === Promise.prototype; // false, Whoops!
Object.getPrototypeOf(fetch("")) === NativePromise.prototype; // true! Double whoops!

안녕. 나는 이것을 하고 있고 꽤 부드럽다. 우선 도서관 프로젝트를 블루버드에 의존하지 마세요. 응용 프로그램 프로젝트의 경우 타이핑이 아닌 bluebird를 가져옵니다. 애플리케이션의 진입점에서 다음을 수행하십시오.

global['약속'] = require('블루버드')

이것은 응용 프로그램과 포함된 모든 라이브러리에 대한 전역 약속 개체를 대체합니다.

안녕하세요 여러분,

@types/bluebird-global 을(를) 사용할 수 있습니다. 이러한 타이핑은 보닛 아래에 @types/bluebird@^3.0 를 사용하고 글로벌 Promise 에서 블루버드의 방법을 사용할 수 있도록 합니다(즉, ts 컴파일이 실패하지 않음).

사용 방법을 보려면 이것을 읽으십시오.

굉장합니다, 감사합니다 @d-ph!

@d-ph @types/bluebird-global 주셔서 감사합니다. Bluebird를 글로벌 Promise의 대체품으로 사용하려면 프로젝트에서 어떤 종류의 가져오기 및 재할당을 수행해야 합니까?

npm install --save-dev @types/bluebird-global 를 입력한 다음 입력: 링크 (2017-04-02 업데이트된 링크)에 포함된 지침을 따르세요. 이것만으로도 트릭을 수행해야 합니다(즉, 수동 가져오기/재할당이 필요하지 않아야 함).

참고로 $#$2 @types/bluebird 에서 package.json::devDependencies 를 더 이상 언급할 필요가 없습니다. 이는 자동으로 암시되기 때문입니다.

이전 댓글의 링크로 업데이트: 링크

@MichaelTontchev @d-ph bluebird-global 에 Promise.Inspection 인터페이스를 추가할 수 있는 기회가 있습니까?

안녕하세요 @ksnyde입니다.

저와 이야기해 주세요. 나는 유지 보수입니다.

이 약속을 말씀하시는지 확인해 주시겠어요.검사 좀 해주시겠습니까?

해당 인터페이스의 모든 메소드는 bluebird-global 를 통해 노출됩니다. 즉 다음이 컴파일됩니다.

let promiseInspectionTest = new Promise<void>((resolve) => {});
promiseInspectionTest.value();

그래서 bluebird-global Promise.Inspection 로 노출되도록 요청 하는 것 같습니다.

다음을 대신 사용하는 것이 큰 문제인지 알려주실 수 있습니까?

import * as Bluebird from "bluebird";

class Foo<T> implements Bluebird.Inspection<T> {

}

bluebird-global 를 사용하고 있기 때문에 명시적인 devDependencies 없이 원래 bluebird 타이핑을 가져올 수도 있습니다.

나는 $# lib.d.ts 의 표준 Promise 타이핑과 함께 작동하도록 하는 것이 미묘한 기술이기 때문에 확실한 이유 없이 전역 Promise 을 더 이상 확장하지 않을 것입니다. bluebird 타이핑에서 직접 이 인터페이스에 액세스하는 것이 좋습니다. 왜냐하면 언젠가 JavaScript 전문가가 Promise.Inspection 를 표준에 추가하여 bluebird-global 타이핑을 깨뜨릴 수 있기 때문입니다. 최종 사용자에게 불필요한 문제를 야기합니다.

또한 인터페이스를 추가하더라도 master 에 병합되기까지 지정되지 않은 시간을 기다려야 합니다. 요즘 DT의 메인테이너들이 PR로 바쁘기 때문입니다.

건배.

나는 실제로 귀하가 논의한 접근 방식을 당분간 사용해 왔으며 적절한 해결 방법입니다. 또는 "해결책"이 잘못된 명명법일 수도 있습니다.

내 이해/인식은 bluebird-global 뒤에 있는 아이디어는 bluebird가 제공하는 Promise 기능의 상위 집합을 노출하는 것이었으며 이 경우 사용자로서 Bluebird.Inspection 가 Promise.Inspection 에 노출될 것으로 _기대합니다. 그러나 의도가 Promises의 공식 API 표면이 Bluebird를 사용하도록 하는 것이라면 이 "해결 방법"이 실제로 적절한 장기 솔루션이라고 생각합니다.

내 해석을 선호하지만 필요한 경우 여기에 제공된 솔루션을 사용하는 것이 좋습니다.

나는 당신이 당신의 기대와 함께 어디에서 왔는지 확실히 알지만, 내가 bluebird-global 를 만든 주된 이유는 TypeScript에 알리기 위함이었습니다. 즉, 타사 코드에서 생성되고 반환된 Promise는 실제로 Bluebird Promise의 인스턴스입니다. 다른 _성가시지 않은_ 대안은 없었지만 Bluebird의 모든 인스턴스와 정적 메서드를 전역 Promise 기호에 노출했습니다. 이전에 언급했듯이 수행 방식은 단순한 class Promise<T> extends Bluebird<T> {} 가 아니라(원래는 있었지만) 신중하게 패치된 전역 Promise 기호입니다. 그리고 내가 언급했듯이, 나는 문자 그대로 당신이 머리를 뽑게 만들지 않는 알려진 대안이 있는 것을 유지해야 하는 것을 피하고 싶습니다.

이것에 대해 "아니오"라고 말해서 죄송합니다. 이 특정 기능을 요청하는 사람이 더 많다면 추가하는 것을 재고하겠습니다. 여기에서 권위적으로 들리고 싶지 않습니다. 이것은 오픈 소스 프로젝트이며 누구나 이 기능을 도입할 수 있습니다. 여기서 제가 말하고자 하는 요점은 제 생각에는 이 기능을 사용하면 얻을 수 있는 이점이 있다는 것입니다. 유지 비용을 초과하지 않습니다.

건배.

말이된다. 접근 방식에 대한 생각에 감사드립니다.

@d-ph는 다음과 같은 작업을 수행합니다. ... "reflect"가 아래 코드의 함수가 아니라는 오류가 표시됩니다.

편집기의 인텔리센스에서는 매핑 함수의 p 속성이 Bluebird Promise이고 Bluebird에서만 볼 수 있는 확장 API 표면(Promise 대비)이 있음을 올바르게 식별하고 있습니다.

나는 그것에서 머리나 꼬리를 만들 수 없습니다. 지도의 반복자 변수의 _type_을 검사하면 다음과 같이 표시됩니다.

이것이 궁극적으로 bluebird-global 로 정의된 제한된 API 표면을 얻는 이유라고 생각했지만 올바르게 해결되지 않는 이유를 모르겠습니다.

안녕.

재현할 수 없습니다./ 해당 코드 조각은 내 설정에서 작동합니다.

가장 먼저. allSettled() 함수에서 bluebird-global 를 사용하지 않습니다. Bluebird 를 사용하여 직접 입력합니다. 이것은 문제가 아니지만 아마도 당신이 그것을 인식하지 못했을 것입니다. 다음 스니펫은 bluebird-global 를 사용합니다.

function allSettled<T>(promises: Array<Promise<T>>) {
    const reflections = Promise.all<T>(promises.map((promise => {
        return promise.reflect();
    })));

    return reflections;
}

즉, 해당 스니펫은 전역 Promise ( bluebird-global.d.ts 의 Bluebird 메서드로 패치됨)에 유형을 지정합니다. 내가 말했듯이: 이것은 귀하의 정보를 위한 것입니다. 귀하와 제 스니펫이 모두 동일하게 작동하기 때문에 귀하가 알지 못하는 경우에 대비합니다.

Bluebird의 방법이 누락된 문제로 돌아가십시오. 내 생각에: 런타임에 전역 Promise 을 Bluebird로 바꾸지 않고 Bluebird 대신 전역 Promise를 사용하여 구성된 Promises로 allSettled() 를 실행합니다.

제 코드와 스크린샷을 보여드리겠습니다.

function allSettled<T>(promises: Array<Promise<T>>) {
    const reflections = Promise.all<T>(promises.map((promise => {
        return promise.reflect();
    })));

    return reflections;
}

let promises = [
    Promise.resolve(),
    Promise.reject(new Error("rejected test")),
    new Promise<void>(() => {}),
];

let reflections = allSettled(promises);

console.log(reflections);

// this is part of my entry point

/*
 * Promise
 */
import * as Promise from 'bluebird';
import 'expose-loader?Promise!bluebird';

_그림 1: Array.map()의 약속은 Bluebird입니다( _bitField 와 같은 밑줄 속성의 존재로 알 수 있습니다)_

_그림 2: Promise.reflect는 실제로 루프에 정의되어 있습니다_

Chrome Dev Tools에서 저와 같은 js 중단점을 설정하고 .map promise 가 무엇인지 확인할 수 있습니까? 더 나은 방법: 콘솔에 Promise 를 입력하고 다음 출력을 얻을 수 있는지 확인할 수 있습니다.

다음 출력이 표시되면 런타임에 전역 Promise를 Bluebird로 바꾸지 않은 것입니다.

어떤 경우에는 해야 합니다. 귀하의 항목 파일에 나와 같은 예.

마지막으로 약간의 개발자 피드백: 개인적으로 Array<Promise<T>> Promise<T>[] 를 사용합니다. 그러나 이것은 물론 개발자의 취향에 달려 있습니다. 저는 템플릿이 없고 개발자가 배열 액세스 연산자를 사용하여 유형을 정의하는 C 배경에서 왔습니다.

건배.

이렇게 자세한 설명 감사합니다. 내가 확신하지 못한 한 가지는 다음이 가리키는 내용이었습니다.

import '노출 로더?약속!블루버드';

@d-ph ahhh, 위의 하나의 라이너가 내가 누락된 것입니다. 당신의 도움이 없었다면 결코 거기에 도달하지 못했을 것입니다! 저만 그럴 수도 있지만 README 텍스트에 Expose Loader 사용에 대한 참조가 있으면 도움이 될 것이라고 생각합니다.

공정하기는 하지만 웹팩을 사용해야 하는 경우에는 여전히 100%가 아닙니다. 내 목표는 브라우저가 아니라 노드 기능일 뿐입니다.

실제로 파일을 실행하려고 할 때 다음 오류가 발생하므로 완전히 작동하지 않는 것처럼 보입니다(런타임 전에 편집기에 오류 없음).

오류: 'expose-loader?Promise!bluebird' 모듈을 찾을 수 없습니다.

맞아요. expose-loader 는 웹팩(웹팩 로더)입니다. 따라서 webpack이 해당 import 문을 처리하도록 하지 않으면 실행되지 않습니다(즉, "Cannot find module" 오류가 표시됨).

webpack을 사용할 수 없거나 사용하지 않는 경우 런타임에 전역 Promise를 Bluebird로 만드는 다른 방법을 찾아야 합니다. 노드에 대한 경험이 많지 않지만 지금 바로 https://github.com/petkaantonov/bluebird/issues/1026(노드에서 Promise 재정의)을 찾았습니다.

최신 노드 7에서 async/await를 사용하는 방법을 찾는 것이 좋습니다. 개발자가 사용할 수 있는 시대에 살고 있는 것은 행운입니다.

README에서 expose-loader 사용에 대해 언급하는 것과 관련하여: d.ts 파일의 맨 위에 이미 명시되어 있습니다. 이것은 런타임에 Promise를 Bluebird로 바꾸는 개발자의 작업입니다: link . 하는 방법이 너무 많기 때문에 실제로 그 중 아무 것도 언급하지 않았습니다. expose-loader 는 window.Promise = Bluebird 를 실행하는 것과 같습니다. 글쎄, 구글이 내 답장을 색인으로 만들어 사람들이 더 이상 가능한 옵션을 너무 오랫동안 찾지 않기를 바란다.

@d-ph는 기본 async-await를 기대하지만 이러한 모든 기능은 AWS Lambda에 있으므로 지금은 노드 6.10.x에 고정되어 있습니다. 이러한 기능의 향후 단계에서는 어쨌든 async-await로 전환하고 Typescript가 이를 ES2015로 변환하도록 할 것이지만 아직 이것을 도입하고 싶지는 않습니다.

어쨌든 @d-ph 링크에 감사드립니다. 그 접근 방식을 시도해 보겠습니다. 아 그리고 누군가가 이 함수의 최종 버전에 관심이 있는 경우를 대비하여(약속 영역에서 매우 편리함):

export function allSettled<T>(promises: Array<Promise<T>>) {
  const reflections = Promise.all<Promise.Inspection<T>>( promises.map((p => p.reflect())) );
  return reflections as Promise<Array<Promise.Inspection<T>>>;
}

export function settleProps<T>(promiseHash: IDictionary<Promise<T>>) {

  const reflections: IDictionary<Promise<Promise.Inspection<T>>> = Object.keys(promiseHash)
    .reduce((newObject: IDictionary<any>, key: string) => {
      newObject[key] = promiseHash[key].reflect();
      return newObject;
    }, {} as IDictionary<Promise<Promise.Inspection<T>>>);

  return Promise.props(reflections) as Promise<IDictionary<Promise.Inspection<T>>>;
}

전체 intelisync/유형 정보를 사용할 수 있어 매우 좋습니다.

@d-ph 바라건대 관련 질문으로 이것을 되살리면 괜찮습니다 ...

bluebird-global을 사용하려고 하면 then 및 catch 모두에서 정의 차이가 조금씩 발생하는 것 같습니다. 나는 그것들이 bluebird-global에서 특별히 처리된다는 것을 알지만, bluebird를 얻는 대신 표준 Promise API로 나를 제한하는 것 같습니다. 예를 들어:

Promise.resolve(true).catch(Error, () => false)

catch 는 1개의 인수만 예상하므로 실패합니다.

그리고 또 다른 문제:

Promise.resolve([3]).map((n: number) => true)

실패:

│TS2345: Argument of type '(n: number) => boolean' is not assignable to parameter of type 'IterateFunction<{}, boolean>'.           │
│  Types of parameters 'n' and 'item' are incompatible.                                                                             │
│    Type '{}' is not assignable to type 'number'.                                                                                  │

그것들이 작동해야합니까 아니면 내가 뭔가를 잘못하고 있습니까? 그들은 런타임에 작동하며 유형 검사를 하지 않습니다.

감사 해요!

안녕,

.catch(Error, function) 에 대해 .then , .catch (및 그 이상)은 나머지 Bluebird 기능과 다르게 처리된다는 말이 옳습니다. 그러나 특정 .catch(Error, function) 재정의 는 bluebird-global 에 포함되어 있습니다. 나는 두 번 확인하고 컴파일 할 수 있습니다.

Promise.resolve(true).catch(Error, () => false)

TS 3.0.1 및 2.9.2로 확인했습니다. 왜 여기서 문제가 발생하는지 모르겠습니다. bluebird-global 이후의 전역 Promise를 재정의하는 TS 프로젝트에 특정한 것이 있을 수 있습니다. 모르겠어요. 아주 기본적인 TS 프로젝트에서 시작한 다음 현재 프로젝트에서 더 많은 종속성을 추가하여 문제를 일으키는 원인을 좁히고 어느 지점에서 중단되는지 확인하십시오.

다른 문제에 대해: 왜 작동하지 않는지 모르겠습니다. 예, 작동해야 합니다. 그것에 대한 github 문제를 생성하십시오. 거기서부터 진행하겠습니다. 다음은 문제에 대한 몇 가지 사실입니다.

1. bluebird-global 가 .map() 와 함께 하는 모든 것은 bluebird.d.ts 의 .map() 유형 정의를 재사용하는 것입니다. 즉, bluebird-global 타이핑에서 결함이 발생해서는 안됩니다.
2. 언급한 줄은 Promise.map() 에서 실패하지만 Bluebird.map() 에서는 작동합니다.

import Bluebird = require('bluebird');

Bluebird.resolve([3]).map((n: number) => true); // works

Promise.resolve([3]).map((n: number) => true); // fails

1. typescript의 문제를 해독하는 데 시간을 보낸 후(본질적으로: TS가 n {} 한다고 결론짓는 이유), 저는 bluebird.d.ts 도 작동하지 않아야 한다고 결론지었습니다. 그러나 그것은 나에게 알려지지 않은 이유로 작동합니다. 간단히 말해서 다음은 모든 추상화 계층을 제거한 후 .map() 에 입력되는 내용입니다.

map<U>(
    mapper: (
        item: U,
        index: number,
        arrayLength: number
    ) => U | PromiseLike<U>,
    options?: Bluebird.ConcurrencyOption
): Bluebird<T extends Iterable<any> ? U[] : never>;

mapper item 의 유형과 동일해야 합니다(또는 동일한 약속). 귀하의 예에서 항목 유형은 number 이고 반환 유형은 boolean 입니다. Bluebird 를 직접 사용할 때 이것이 컴파일되는 이유를 이해할 수 없지만 전역 Promise를 사용할 때는 그렇지 않습니다. 그건 그렇고, 귀하의 예제에서 반환 유형을 숫자로 변경하면 여전히 작동하지 않습니다. 그러나 item 유형이 any 수 있다고 말하면 작동합니다. bluebird.d.ts 의 type IterableItem<R> 및 이 컨텍스트에서의 사용법에 문제가 있습니다.

@d-ph

편집하다:

map() 의 "unlayered" 형식을 다시 확인했는데 mapper 함수가 item 유형과 동일한 반환 유형을 가지도록 입력되지 않았습니다. 였다). 내 잘못이야.

.map()으로 모든 bluebird-global은 bluebird.d.ts의 .map() 유형 정의를 재사용합니다.

제네릭 클래스 Bluebird<R> 에서 유형을 복사할 때 부모로부터 유추할 수 없기 때문에 R $에 대해 기본적으로 {} 가 되는 문제입니까?

map: typeof Bluebird<T>.prototype.map 가 작동하는지 궁금합니다. (나는 이것을 아직 시도하지 않았다)

중요한:
@types/bluebird-global 를 사용하는 경우 @d-ph가 말한 대로 종속성 @types/bluebird $에서 삭제하십시오.

npm install --save-dev @types/bluebird-global 를 입력한 다음 입력: 링크 (2017-04-02 업데이트 링크)에 포함된 지침을 따르세요. 이것만으로도 트릭을 수행해야 합니다(즉, 수동 가져오기/재할당이 필요하지 않아야 함).

참고로 package.json::devDependencies @types/bluebird #$를 더 이상 언급할 필요가 없습니다. 이는 자동으로 암시되기 때문입니다.

둘 다 있으면 @types/bluebird 와 내 전역 약속( @types/bluebird-global )에 의해 반환되는 유형 간에 일치하지 않는 문제가 발생했습니다.