Knex: 표준 ES6 Promise를 사용하도록 구성하는 방법은 무엇입니까?

호기심: 더 빠른 라이브러리를 더 느린 내장 라이브러리로 교체하고 싶습니까? 클라이언트에서는 중요하지 않지만 노드 속도에서는 요소입니다. 이에 대한 이유는 무엇입니까?

@johanneslumpe knex 와 함께 일부 응용 프로그램의 요인입니다. Promise 라이브러리를 사용하는 것이 성능에 큰 영향을 미치는지 의심스럽습니다. bluebird 가 필요하지 않도록 A+ API만 사용하도록 모든 Promise 코드를 작성해야 한다고 논의되었습니다.

그 후에는 어떤 Promise 라이브러리가 사용되는지 재정의하기 쉬워야 합니다.

knex와 같은 라이브러리에서 무의미하게 느껴진다는 데 동의합니다. knex의 코드베이스는 이미 자체 promise.js 파일을 내부적으로 가져오기 때문에 API가 동일하다면 기술적으로 여전히 구현하기가 매우 쉽습니다. 이 파일에서 전역 약속을 기본값으로 할 수 있고, 그렇지 않으면 구성된 라이브러리 또는 이와 유사한 것을 요구할 수 있습니다.

사용자에게 선택권을 주는 것이 전부입니다. Node V6+ 사용자의 경우 가능한 한 최소한으로 타사 종속성을 관리할 수 있는 선택권을 제공합니다.

호기심: 더 빠른 라이브러리를 더 느린 내장 라이브러리로 교체하고 싶습니까?

당신이 말하는 것이 과거에는 사실일 수도 있지만 지금이나 6개월 후에는 어떻습니까? (나는 약간의 검색을했고 일부 2015 벤치 마크 만 찾을 수 있습니다. 더 최근 비교가 있으면 링크를 게시하십시오)
Promise ES6 표준을 만드는 요점은 타사 라이브러리에 의존하지 않고 사람들이 쉽게 Promise를 사용할 수 있도록 하는 것이며 Node 또는 V8의 핵심 팀은 성능 차이를 영원히 무시할 수 없습니다. 두 프로젝트의 오픈 소스 라이선스는 호환되며 일부 코드를 빌릴 수도 있습니다. 또는 내장된 Promise가 더 빠르고 더 좋을 수 있다고 생각하는 시간을 주십시오.

Amazon의 AWS-SDK를 참조하십시오. 또한 기본적으로 전 세계적으로 사용 가능한 모든 Promise를 사용합니다. 사용자에게 즐겨찾는 Promise 라이브러리도 구성할 수 있는 선택권을 제공합니다.

http://docs.aws.amazon.com/AWSJavaScriptSDK/guide/node-making-requests.html#Support_for_Promises

그것은 모두 선택 에 관한 것입니다

다시 생각해보면 파일 하나를 바꾸는 것만큼 쉽지는 않을 것입니다. Knex는 현재 .timeout , .tap , .reduce , .map 등과 같은 Bluebird 유틸리티 기능에 많이 의존합니다. ES6 약속에서.

ES6 약속을 지원하는 데 관심이 있습니다. 이상적으로는 $ Promise $ 생성자를 사용하는 Knex 생성자에 대한 두 번째 인수가 필요합니다. 이전 버전과의 호환성은 다음과 같이 달성됩니다.

const Promise = require('bluebird');
const knex = Knex(myKnexConfig, Promise);

제공된 Promise.prototype 의 존재를 기반으로 map , filter 등의 조건부 별칭을 지정할 수 있습니까?

나는 이것이 우선 순위 목록에서 상당히 낮아야 한다고 생각하며, 성능 저하(물론 한동안 벤치마크를 보지는 못했지만)와 사람들이 반환된 약속이 블루버드라는 사실에 기반합니다(조건부 catch 등).

이 문제를 해결하기 위해 async/await가 안정적인 노드에 도달할 때까지 기다리는 경향이 있습니다.

사람들이 최소한의 타사 종속성을 원하는 경우 기본 Promise가 더 좋을 수 있습니다.

@google-cloud 및 기타 많은 라이브러리와 같이 기본 Promise를 사용하도록 기본 설정하고 타사 라이브러리를 사용하려는 사람을 위한 Promise 매개변수를 수락할 수 있습니다.

https://googlecloudplatform.github.io/google-cloud-node/#/docs/google -cloud/

var gcloud = require('google-cloud')({
  promise: require('bluebird')
});

@tgriesser 나는 이것이 오래된 문제라는 것을 알고 있지만, 우리는 이제 stable과 Carbon 모두에서 async / await 를 얻었습니다.

async/await가 기본 프라미스( 사양에 따라 async 함수는 기본 프라미스를 반환해야 함)와 함께 작동하는 것이 선호된다는 점을 감안할 때 이것이 더 높은 우선순위입니까?

네이티브 프라미스 지원이 Knex가 원하지만 현재 레이더에 없는 경우 PR을 환영할까요?

시간 내 줘서 고마워.

@malexdev async 함수는 현재 knex와 별로 관련이 없는 기본 프라미스를 반환합니다. await 가 제대로 작동하기 위해 기본 프라미스가 필요하다는 의미는 아닙니다. 어떤 경우에 이것이 문제/혜택인지 명확히 해주실 수 있습니까(하나의 종속성 삭제 제외)?

즉, 나는 bluebird를 삭제하는 것에 반대하지 않지만 실제로 내부 변경이 꽤 필요합니다. 일부 구성 스위치 아래에 이전 기능이 숨겨져 있고 기본적으로 기본 약속이 사용되지 않는 한 현재 bluebird 에서 knex API로 노출되는 일부 메서드를 구현해야 할 수도 있습니다. knex가 bluebird 약속을 반환한다는 사실을 중계해 온 사람들에게 이 방법으로 마이그레이션이 불가능하지 않을 것입니다.

@elhigu 개인적으로 가장 큰 이점은 await 에 사용되는 기본 약속을 시행하는 TSLint 규칙과 함께 TypeScript를 사용하고 있으므로 모든 Knex 호출을 Promise.resolve() 안에 래핑해야 한다는 것입니다. 나는 이것이 특별히 Knex와 관련이 없다는 것을 알고 있으며 저에게만 발생하는 문제일 가능성이 높습니다.

그 외에는 제 3자 종속성이 적은 것이 더 좋으며 @c0b 가 언급했듯이 더 많은 옵션이 결코 나쁜 것은 아닙니다.

나는 그것이 Knex가 나아가는 데 관심이 있는 것이라면 많은 일이 될 것이라는 것을 깨달았습니다. 이것이 제가 이 일에 시간을 할애하게 된 것을 기쁘게 생각하는 이유 중 하나입니다.

예, 저는 typescript 문제로 인해 여기에 착륙했습니다. 저는 Knex를 다중 스토리지 데이터 저장소 라이브러리용 SQL 엔진으로 사용하고 있으며 네이티브 대 블루버드 약속에 대해 양면성을 가지고 있지만 쉽게 사용할 수 없습니다. 이러한 이유로 knex의 typescript. 나는 knex thenables를 기본 사양을 따르는 것으로 취급하지만(나는 bluebird 확장을 사용하지 않습니다), typescript는 Bluebird 반환에 대해 나에게 버그를 줍니다.메서드 선언이 Promise인 경우.

이것은 우리가 약속 구현과 knex에 대한 입력(다른 개발자에 의해 처리됨)을 모두 다루고 있기 때문에 여기에서 일종의 두 가지 수준입니다. 하지만 기본적으로 여기에서 멈춥니다. Promise를 선언했을 때 Bluebird를 반환합니다(Promise API에 Bluebird가 지원하지 않는 항목이 있는 것 같습니까?). 그러나 return Promise.resolve(bluebirdthing) 무리를 어디에나 두는 것 같지 않습니다.

나는 지난 1년 동안 knex 배짱을 파헤치는 데 충분한 시간을 할애했으며 사람들이 원하면 여기에서 무언가를 선택하고 Promise 구현을 모듈화하기 위해 PR 작업을 하겠다고 일반적으로 약속하는 데 시간을 보냈습니다. PR에 열려 있습니까? @elhigu 가 언급한 것과 같은 것으로 끝날 것입니다. 코드 재작성 필요를 피하기 위해 인스턴스화 시 전달된 Promise 생성자를 사용하기 위해 일부 유틸리티 함수를 다시 구현합니다. 물론 성능에 대해서는 확실하지 않지만 벤치마킹할 수 있는 것입니다.

async / await로 모든 것을 멋지게 끝내는 것도 멋진 일이며, 나는 이것을 고치기 위해 서두르지 않습니다 any typescript 대신 javascript인 것처럼 코드 분기).

@ericeslinger 사용 중인 실제 Promise 구현이 TypeScript에 문제를 일으키는 이유를 모르겠습니다. 저는 문제 없이 1년 반 동안 블루버드와 기본 약속을 혼합해 왔습니다...

나는 단지 bluebird에 대한 유형을 소개하는 어떤 타이핑도 사용하지 않았으며, 그냥 typescript 타이핑이 정상적인 Promise이고 아무런 차이도 보이지 않는다고 말했습니다.

어떤 typescript 버전이 있으며 재현할 예제 프로젝트가 있습니까? 예를 들어 npm 시작 스크립트가 있는 github repo.

이것은 우리가 약속 구현과 knex에 대한 입력(다른 개발자에 의해 처리됨)을 모두 다루고 있기 때문에 여기에서 일종의 두 가지 수준입니다. 하지만 기본적으로 여기에서 멈춥니다. Promise를 선언했을 때 Bluebird를 반환합니다. (Promise API에 Bluebird가 지원하지 않는 항목이 있는 것 같은데요?) 하지만 어느 곳에나 반환 Promise.resolve(bluebirdthing)를 잔뜩 넣고 싶지는 않습니다.

npm의 knex 타이핑인가요? 블루버드 타이핑은 npm에서 합니까? 어떤 패키지? 왜 그런 일이 일어나는지 이해하기 어렵습니다. 별도의 Bluebird 유형이 있는 경우 기본 Promise에서 상속되어야 하며 Promise를 반환한다는 API에서 반환하는 것이 좋습니다. 설명에서 문제는 매우 깨진 타이핑 구현인 것 같습니다. 그리고 그것은 이 문제와 관련이 없습니다(typescript는 실제 유형에 대해 신경 쓰지 않으므로 knex가 반환하는 내용을 알지 못합니다).

@types/knex 설치를 통해 ExistingTyped 리포지토리에서 내 타이핑을 받고 있습니다. 그 정의는 @types/bluebird 가져오고 모든 knex 메서드는 Bluebird 개체를 반환하는 형식으로 지정됩니다.

구체적으로 나는 이것을 할 수 없습니다.

function mungeData(v: any): DataItem {} 
function foo(): Promise<DataItem[]> {
  return knex('data').select()
  .then((rows) => rows.map(row => mungeData(row)))
} // error, cannot return Bluebird<DataItem[]> as Promise<DataItem[]>

이러한 타이핑을 사용합니다. 이는 knex.select().then()이 DefinedTyped 리포지토리에서 Bluebird를 반환하도록 입력되고 이러한 연결이 더 많은 Bluebirds를 만들기 위해 함께 연결되고 foo가 Bluebird일 때 return foo as Promise<any>() 와 같은 것을 말하기 때문입니다.Bluebirds는 Promises에 할당할 수 없기 때문에 실패할 것입니다(적어도 typescript 2.4에서는 실패함). ( 여기 에 따르면 [Symbol.toStringTag]가 없기 때문에 하나를 다른 것으로 강제하는 것은 비록 작은 오류지만 오류가 발생합니다).

대신 내가 변경할 수 있습니다

function bar(): Promise<DataItem[]> {
  return Promise.resolve<DataItem[]>(foo())
}

또는 네이티브 Promise.resolve() 호출 내에서 knex에 대한 모든 호출을 래핑하는 다른 트릭을 수행합니다. 이렇게 하면 typescript가 내 라이브러리 함수의 다운스트림에 대한 불평을 중지하는 동시에 여전히 내 라이브러리 함수 내에서 knex 타이핑을 사용할 수 있습니다.

어제 이전에는 @types/knex 를 전혀 사용하지 않았습니다. knex를 any 로 입력했을 뿐입니다. 코드는 런타임에 어느 쪽이든 잘 작동합니다(적어도 제 사용 사례의 경우).

@elhigu : 문제는 잘못된 입력 구현이 아닙니다.
TypeScript는 async Promise<[type]> 로 설정합니다. 이는 JS 사양에 따라 정확합니다.
Knex는 입력이 정확하게 반영된 Bluebird<[type]> 를 반환합니다.

나는 단지 블루버드에 대한 유형을 도입할 어떤 타이핑도 사용하지 않았으며, 그냥 타이핑 스크립트에 그것들이 정상적인 프라미스이고 아무런 차이가 없다고 말했을 뿐입니다.

Knex 함수가 실제로 Bluebird s를 반환하기 때문에 이것은 컴파일러에 거짓말입니다. 관심이 없다.
Bluebirds가 Promise와 호환된다는 것은 맞습니다. 그러나 TypeScript와의 거래 중 일부는 반환한다고 말한 것을 실제로 반환한다는 것입니다.

Promise 를 반환하도록 입력된 함수에서 Bluebird 를 반환할 때 TypeScript는 Bluebird 유형이 Promise 유형과 같지 않기 때문에 불평합니다.
우리가 할 수 있는 다양한 트릭이 있습니다(예: @ericeslinger 가 any 사용 또는 Promise.resolve() 로 래핑하는 것에 대해 언급한 것). 그러나 결국 그런 트릭은 많은 것을 잃게 만듭니다. TypeScript가 제공하는 것.

결국 현실은 "네이티브 프라미스를 사용하는 것이 우리에게 중요하며 우리는 프라미스 기능을 보다 일반적으로 만들기 위해 기꺼이 노력할 것"이라고 말하는 사용자가 두 명 이상 있다는 것입니다.

나는 당신이 단지 도우려고 한다는 것을 알고 있지만 솔직히 "당신은 이렇게 할 수 있습니다"라는 말을 듣는 대신 나 자신이 제안한 약속 변경 사항을 듣고 싶습니다 / @ericeslinger / @c0b 내가 시작할 수 있도록 허용할 수 있습니다 PR이나 무엇에.

@malexdev @ericeslinger 자세한 정보 감사합니다! 실제로 Promise 에서 자신의 클래스를 상속할 수 없는 것 같으므로 이것이 Promise<>로 입력된 함수에서 Bluebirds를 반환하는 데 실패하는 이유일 수 있습니다.

@ericeslinger 어쨌든 이것은 async 함수를 생성할 때 문제가 되지 않습니다. 왜냐하면 내부적으로 결과를 자동으로 기본 프라미스로 래핑하기 때문입니다. 다음은 @types/bluebird에서 입력하고 ES2015 또는 ESNEXT로 컴파일하여 문제 없이 준수합니다.

import * as Bluebird from 'bluebird';

// declaring function async converts bluebird implicitly to native Promise
async function asyncReturningPromise(): Promise<string> {
    const blueBirdPromise = new Bluebird<string>((resolve, reject) => { 
        resolve('yay asyncReturningPromise');    
    });
    return blueBirdPromise;
}

// main func to run the code using async / await
Bluebird.resolve().then(async () => {
    console.log("await function returning promise (bluebird)", await asyncReturningPromise());

    const blueBird = new Bluebird((resolve, reject) => { resolve(); });
    const returnedFromAsync = asyncReturningPromise();

    console.log("Bluebird instanceof Promise:", blueBird instanceof Promise);
    console.log("async retval instanceof Promise:", returnedFromAsync instanceof Promise);
});

산출:

await function returning promise (bluebird) yay asyncReturningPromise
Bluebird instanceof Promise: false
async retval instanceof Promise: true

따라서 지금 당장은 knex API를 사용할 때 기본 Promises에 자동으로 블루버드를 래핑하는 비동기 함수/메소드를 사용하지 않는 한 Bluebird를 반환한다는 사실을 알려야 합니다.

@malexdev

Knex 함수가 실제로 Bluebirds를 반환하기 때문에 이것은 컴파일러에 거짓말입니다. 관심이 없다.
Bluebirds가 Promise와 호환된다는 것은 맞습니다. 그러나 TypeScript와의 거래 중 일부는 반환한다고 말한 것을 실제로 반환한다는 것입니다.

실제로 typescript를 다루는 것은 반환된 객체가 인터페이스를 올바르게 구현하는 것으로 충분하다는 것입니다. 예를 들어 다음은 완벽합니다.

class FakePromise<T> implements Promise<T>  {
    [Symbol.toStringTag]: "Promise";
    then<TResult1, TResult2>(onfulfilled?: (value: T) => TResult1 | PromiseLike<TResult1> | null | undefined, onrejected?: (reason: any) => TResult2 | PromiseLike<TResult2> | null | undefined): Promise<TResult1 | TResult2> {
        return new Promise((resolve, reject) => { resolve('Im totally broken and fake!); });
    }
    catch<TResult>(onrejected?: (reason: any) => TResult | PromiseLike<TResult> | null | undefined): Promise<T | TResult> {
        throw new Error("Method not implemented.");
    }
}

// this works and  fake promise instance has nothing to do with native promise
function returningPromiseInterface(): Promise<string> {
    const fakePromise = new FakePromise<string>();
    return fakePromise;
}

// compiling this fails, because looks like Bluebird actually doesn't implement Promise interface correctly
function asyncReturningPromise(): Promise<string> {
    const blueBirdPromise = new Bluebird<string>((resolve, reject) => { 
        resolve('yay asyncReturningPromise');    
    });
    return blueBirdPromise;
}

instanceof를 엉망으로 만들지만 typescript는 실제로 인터페이스만 기본 Promise 인스턴스를 반환한다고 약속하지도 않았습니다.

Promise를 반환하도록 입력된 함수에서 Bluebird를 반환할 때 TypeScript는 Bluebird 유형이 Promise 유형과 동일하지 않기 때문에 불평합니다.
우리가 할 수 있는 다양한 트릭이 있습니다(예: @ericeslinger 가 any 사용 또는 Promise.resolve()로 래핑하는 것에 대해 언급한 것). 그러나 결국 그런 트릭은 TypeScript가 제공하는 많은 것을 놓치게 만듭니다.

나는 사람들이 나쁜 타이핑을 만족시키기 위해 그런 종류의 트릭을 수행하거나 JS 구현을 변경해야 하는 것을 보고 싶지 않습니다.

결국 현실은 "네이티브 프라미스를 사용하는 것이 우리에게 중요하며 우리는 프라미스 기능을 보다 일반적으로 만들기 위해 기꺼이 노력할 것"이라고 말하는 사용자가 두 명 이상 있다는 것입니다.

나는 당신이 단지 도우려고 한다는 것을 알고 있지만 솔직히 "당신은 이렇게 할 수 있습니다"라는 말을 듣는 대신 나 자신이 제안한 약속 변경 사항을 듣고 싶습니다 / @ericeslinger / @c0b 내가 시작할 수 있도록 허용할 수 있습니다 PR이나 무엇에.

이해해주셔서 감사합니다 :) 네이티브 프라미스를 사용하도록 knex를 변경하는 것은 이미 시작되어 작년에 어느 시점까지 구현되었으며 @tgriesser 에 의해 다시 변경되었으므로 지금은 이 변경을 시작하지 않는 것이 좋습니다.

또한 나는 여전히 이 스레드에서 언급된 이러한 typescript 문제를 knex 구현의 문제보다 타이핑 선언의 문제(bluebird가 Promise를 올바르게 구현하지 않는 이유... 더 깊이 파고들 필요가 있습니까?)로 생각합니다.

즉, 나는 여기에서 두 가지 별개의 문제를 보는 것만으로도 일정 기간 동안 블루버드를 제거하는 것에 반대하지 않습니다.

:+1: 네이티브 Promise의 경우.

@elhigu :

실제로 typescript를 다루는 것은 반환된 객체가 인터페이스를 올바르게 구현하는 것으로 충분하다는 것입니다.

그럴 수 있지. 나는 여전히 더 적은 의존성과 더 많은 선택이 더 낫다는 내 의견을 지지하지만, 이제 깨진 타이핑에 대해 당신이 의미하는 바를 알았습니다.

네이티브 Promises의 경우 여전히 👍(아직도 기꺼이 도와드릴 의향이 있습니다). 그러나 이제 내 즉각적인 문제는 Bluebird 타이핑을 수정하여 해결할 수 있습니다. 정보 주셔서 감사합니다.

그래서 저는 TypeScript를 꽤 많이 사용하기 시작했고 둘 다 그것을 좋아하며 이제 여기의 문제가 진정한 골칫거리라는 것을 깨달았습니다. async/await가 최근 노드에서 더 많은 기반을 확보함에 따라 Bluebird 유틸리티 fns( map , reduce , tap , bind , return ) 덜 유용합니다. Bluebird를 내부적으로 계속 사용하고 싶지만 공식적으로는 모든 추가 유틸리티 메서드를 반환하는 knex 쿼리 빌더의 공개 API를 "비추천"합니다.

이를 병합하면 TypeScript 정의를 업그레이드하여 Bluebird 타이핑( toBluebird 제외)을 삭제하고 Bluebird 타이핑을 Promise 타이핑으로 변경할 수 있습니다.

대역폭이 있는 사람이 이 문제를 해결하고 싶다면 다음과 같이 행동 계획을 세워야 합니다.

• [ ] 모든 Bluebird 프록시 메서드( tap , map , reduce , bind , return )에 대한 사용 중단 경고를 추가합니다.
• [ ] Bluebird를 계속 사용하려는 사람들을 위한 마이그레이션 경로가 될 .toBluebird() 메소드 추가(위 메소드의 모든 호출에 대한 간단한 찾기/바꾸기로 수행할 수 있으며 이전에 추가하기만 하면 됩니다. 그들은 호출됩니다)
• [ ] 병합/새 릴리스 컷(0.15)이 되면 Typescript 정의를 업데이트할 수 있습니다.
• [ ] 결국 우리는 이러한 방법을 완전히 삭제할 수 있습니다. 이 더 간단한 API는 결국 기본 Promises & async/await를 합리적으로 사용할 수 있는 길을 열어줍니다.

이것이 의미가 있고 누군가가 이것을 시도하는 데 관심이 있다면 알려주십시오.

확실히 도움이 될 것입니다.

이것은 Knex가 자체 TypeScript 정의를 유지하기 시작할 것임을 의미합니까? 자동 생성 타이핑이 지원하지 않는 제네릭으로 멋진 작업을 수행할 수 있습니다.

네이티브 Promise에 대한 지원을 추가하기 위한 첫 번째 시도로 이 포크를 시작했습니다.
https://github.com/tgrisser/knex/pull/2523/files

2016년 이 댓글 좋아요:

호기심: 더 빠른 라이브러리를 더 느린 내장 라이브러리로 교체하고 싶습니다.

2년 만에 이렇게 변할 수 있다는 게 놀랍다.

Promise를 반환하도록 입력된 함수에서 Bluebird를 반환할 때 TypeScript는 Bluebird 유형이 Promise 유형과 동일하지 않기 때문에 불평합니다.

@malexdev 실제로 typescript는 구조적 유형을 사용하므로(흐름은 명목 유형을 사용하고 설명하는 방식으로 작동함) 유형이 Promise 인터페이스를 충족하는 한 명시적으로 extends 인지 여부에 관계없이 Promise 와 호환됩니다. extends / implements 여부.

어떻게 진행되고 있습니까? 좋은 첫 번째 단계는 knex 내에서 Bluebird 특정 메서드 호출을 제외하는 것입니다(즉, 아직 실제로 제거하지 않음). 블루버드를 제거하고 사용자 정의 Promise 생성자에 대한 옵션을 제공하는 것이 뒤따를 것입니다(그리고 Bluebird 메소드를 사용하는 사람들에게 업그레이드 경로를 제공함).

나는 이의가 없으면 첫걸음부터 일을 시작하지 않는다. 기존 작업이 중단된 것으로 보입니다.

@qubyte 적극적으로 변경하려는 노력은 없는 것 같고, 여기저기서 점진적인 변경이 이루어지긴 했지만 그게 전부입니다.

확인. 다음 자유 시간에는 가능한 한 작은 변경을 통해 각 방법을 고려하겠습니다.

@tgrisser 언제 이 문제를 진행해야 하는지 의견이 있으십니까(만약 있다면)? Node 6 LTS가 라인의 끝에 도달하면 내년 4월이 적당한 시기처럼 들릴 것입니다.

2018년 흥미로운 정보:

promises-native-async-await 는 노드 10에서 promises-bluebird 보다 성능이 좋습니다.
참조: https://github.com/petkaantonov/bluebird/tree/master/benchmark

따라서 성능은 더 이상 블루버드를 유지하는 이유가 아닙니다. 우리는 async/await로 가야 합니다.

promise-native-async-wait의 성능이 더 좋습니다.

그것은 또한 2016년에 기본 방식이 훨씬 더 빨리 개선될 것이라고 굳게 믿었던 것입니다. Nodejs 커뮤니티의 핵심이고 타사 라이브러리보다 더 많은 사람들이 그것에 관심을 갖고 있기 때문입니다.

선택을 요구하는 티켓이 제출되었지만 경쟁하는 Promise 구현이 너무 많지만 블루버드에 영원히 베팅하는 것은 좋지 않습니다.

이에 대한 업데이트가 있습니까?

@cfanoulis 여전히 동일합니다. 4월이 되면 노드 6에 대한 지원을 중단하고 블루버드 제거를 시작할 수 있습니다.

2019 업데이트가 있습니까? /cc는 일부 핵심 기여자 또는 유지 관리자 또는 @here 에 관심이 있는 모든 사람에게: @johanneslumpe @tgriesser @wubzz @elhigu from https://github.com/tgriesser/knex/graphs/contributors?type=c&from=2018-01- 01&to=2019-12-31

반면에 JavaScript 커뮤니티는 역동적이고 활기차고 때로는 잔인한 세상입니다. 3~2년마다(또는 그보다 더 빠르게) 이전에 익숙했던 것을 대체하는 도구가 있습니다. Grunt, Gulp => Webpack, 도구, 라이브러리, 프레임워크는 모든 수준에서 완전히 경쟁합니다. 따라서 혁신 도입을 중단하거나 새로운 표준 지원 속도를 늦추는 경우(ES2019 async/await iterator에 대해 생각해 보세요...) 결국 이전 라이브러리로 대체됩니다.

방금 몇 가지 간단한 연구를 수행했습니다. DB ORM 수준에서도 많은 대안이 있는 것 같습니다. TypeORM이 좋은 것일 수 있습니다... (더 말하지 않기 위해 여기서 멈춥니다...)
https://bestofjs.org/tags/db
https://bestofjs.org/projects/typeorm

@c0b 참조 할 필요가 없습니다. 어쨌든 모든 댓글에서 메일을 받습니다. @kibertoad 는 방금 그의 마지막 댓글에서 말해야 했던 모든 것을 말했습니다... 이 문제는 또한 async/await ES2019 기능을 더 잘 지원하는 knex와 관련이 없으며 knex는 ORM이 아니므로 그 댓글이 실제로 무엇인지 잘 모르겠습니다. 에 대한.

좋은 ORM이 필요하다면 objection.js를 추천할 수 있습니다. 그것은 knex 위에도 구현되어 있습니다. 여기에 이에 대한 꽤 좋은 스레드가 있습니다. https://github.com/Vincit/objection.js/issues/1069

어느 시점에서 이 knex는 대체되지만 ORM으로 대체되지는 않습니다. 보다 깔끔한 코드 기반과 보다 일관된 API를 제공하는 다른 쿼리 빌더로 대체될 수 있습니다. 예를 들어 knex 1.0과 같이 아마도 ;)

또한 knex가 교체된다면 나는 그것으로 완전히 괜찮을 것이고, 덜 일할 것입니다 :D

내가 믿는 WIP가 있습니다: https://github.com/tgrisser/knex-next

네이티브 프라미스를 사용하지 않으면 async_hooks 를 사용할 때 https://github.com/nodejs/node/issues/22360 이 발생하여 현재 컨텍스트가 손실된다는 점도 언급하고 싶었습니다.

저를 믿으세요. 저희는 이사를 가는데 추가 이유가 필요하지 않습니다. 저희는 여러분 모두가 그러하듯이 그렇게 하고 싶습니다. :) 그러나 우리는 여전히 노드 6 분기에 대한 몇 가지 수정 사항을 더 릴리스해야 하며 (마지막으로) 이를 삭제하고 점차적으로 블루버드를 단계적으로 제거할 것입니다.

#3227이 병합되면 마침내 시작할 수 있습니다!

이전에 이 마이그레이션에 도움을 사용할 수 있다고 언급한 것으로 알고 있습니다. 그래도 원하는 방향이라면 어떤 식으로든 도움을 드릴 수 있습니까?

나는 생각하고 있다: 프로젝트를 만들고, 몇 가지 작업을 추가하고, 누군가(시간이 있을 수 있음) 할당되고 날짜를 설정할 수 있는지 확인하십시오.

@chaffeqa 곧 좀 더 세분화된 작업을 만들 예정이며 #3250에서 첫 번째 쉬운 변경 작업을 수행할 수 있습니다. 주로 bluebird.tap, bluebird.method 및 bluebird.try 사용법을 기본 기반으로 교체해야 합니다. 시간이 이미 있다면 #3250에서 분기하여 나머지 'bluebird' 요구 사항을 살펴볼 수 있습니다 test:sqlite Docker 설정 없이

@qubyte 기여하고 싶다면 지금이 적기입니다!

@kibertoad 지금 async/await를 사용해도 안전합니까?

knex 코드베이스를 의미합니까? 확신하는. 당신만의 공간에서 당신은 언제나 그랬습니다 :-D

https://github.com/tgrisser/knex/issues/3253
https://github.com/tgrisser/knex/issues/3254
https://github.com/tgrisser/knex/issues/3255
https://github.com/tgrisser/knex/issues/3256
https://github.com/tgriesser/knex/issues/3257
https://github.com/tgrisser/knex/issues/3268
https://github.com/tgrisser/knex/issues/3286
손에 넣을 수 있습니다.

지난 주에 MIA가 된 것에 대해 죄송합니다. 우리 회사의 일이 점점 늘어나고 있으므로 거기에 집중해야 합니다.

업그레이드에 대한 더 큰 블록 중 하나인 Disposer 사용 교체에 대한 논의 에서 루프를 닫고 싶었습니다.

당신이 그것을 시작하면 꽤 깊은 골칫거리, 그래서 좋은 카피/추상화를 제공하기 위해 약간의 좋은 엔지니어링이 필요할 것입니다. 나는 뭔가의 성능 오버헤드가 꽤 클 수 있다고 걱정합니다(프라미스 체인이 커짐에 따라 더 많은 객체가 생성됨).

나는 실제로 몇 가지 POC에서 시작했으며 이것이 그 중 가장 간단하다고 생각합니다.

class DisposablePromise extends Promise {

  disposerFunc = null;
  originalResource = null;

  then(onFulfilled, onRejected) {
    const $onFulfilled = this.wrap(onFulfilled);
    return super.then($onFulfilled, onRejected).copyContext(this);
  }

  copyContext(promise) {
    this.disposerFunc = promise.disposerFunc;
    this.originalResource = promise.originalResource;
    return this;
  }

  disposer(disposerFunc) {
    this.disposerFunc = disposerFunc
  }

  isDisposable() {
    return !!this.disposerFunc
  }

  wrap(onFulfilled: any) {
    const $onFulfilled = (result: any) => {
      if (this.disposerFunc && !this.originalResource) {
        this.originalResource = result
      }
      if (result instanceof Promise) {
        return onFulfilled(result);
      } else {
        const res = onFulfilled(result)
        if (this.disposerFunc) {
          this.disposerFunc(this.originalResource)
        }
        return res
      }
    };

    return $onFulfilled;
  }
}

그리고 또 다른:

      var DisposablePromise = function DisposablePromise() {
          var self = DisposablePromise.convert(Promise.resolve());
          return self;
      };
      DisposablePromise.convert = function convert(promise, props) {
          promise.__proto__ = DisposablePromise.prototype;
          return props ? Object.assign(promise, props) : promise;
      };
      DisposablePromise.prototype = Object.create(Promise.prototype);
      DisposablePromise.prototype.constructor = DisposablePromise;
      DisposablePromise.prototype.then = function then(resolve, reject) {
          var returnVal = Promise.prototype.then.call(this, resolve, reject);
          return DisposablePromise.convert(returnVal);
      };
      DisposablePromise.prototype.catch = function _catch(err) {
          var returnVal = Promise.prototype.catch.call(this, err);
          return DisposablePromise.convert(returnVal);
      };
      DisposablePromise.prototype.finally = function finall(obj) {
          var returnVal = Promise.prototype.finally.call(this, obj);
          return DisposablePromise.convert(returnVal);
      };
      DisposablePromise.prototype.disposer = function disposer(disposerFunc) {
        var returnVal = Promise.prototype.finally.call(this, obj);
        return DisposablePromise.convert(returnVal);
      };

그러나 그것을 증명할 시간이 없었습니다.

이 기능이 저장소에 있어야 하기 때문에(더 나은 접근 방식을 생각할 수 없다면... 비동기 반복자? 내 직감은 블루버드 구현 후크와 꽤 관련이 있다고 말하지만 그 기능을 추상화하는 것에 대해서도 블루버드 팀의 의견을 듣고 싶습니다.

이 부분을 알아낼 수 있다면 나머지 작업은 매우 간단합니다.

@chaffeqa Np, 아직 시간을 내주셔서 감사합니다!
나는 블루버드 사람들이 구현을 진지하게 재설계하기 위한 제안을 받아들일지 매우 의심스럽습니다. 그들은 이 시점에서 모든 것보다 안정성에 관심이 있다는 점을 반복해서 반복했습니다. 그들은 사람들에게 실제로 고급 기능이 필요하지 않는 한 기본 약속을 실제로 사용하도록 권장합니다. 블루버드 제공.
Node 8이 현재 가장 인기 있는 Node.js 버전인 것을 고려하면(공식 Node.js 다운로드 통계 기준) 아직 비동기 반복자 기반 접근 방식으로 이동할 수 없습니다.
내부적으로 DisposablePromise를 구현하는 Knex의 단점은 무엇입니까? 기본 Promise를 확장하기 때문에 Bluebird의 단점이 전혀 없으며 사용자 공간에서 이에 대해 알 필요가 없다고 가정합니다.

@ericeslinger FWIW, TS 타이핑은 더 이상 마스터에서 문제가 되지 않아야 합니다. 이제 사용자가 Bluebird 기능에 의존하지 않도록 약속을 기본 약속으로 타이핑하고 있습니다. 이로 인해 기본 Promise가 Bluebird Promise가 수행하지 않는 것을 구현할 때 문제가 발생할 수 있으므로 가능한 한 많이 사용되는 Promise를 교체하려고 합니다. 이 라인에 대한 모든 기여는 크게 감사하겠습니다 :)

내가 생각한 견과류 😞
나는 DisposablePromise 와 같은 것을 하는 것이 아마도 이 경우에 가는 방법일 것이라는 데 동의합니다. 특히 정말로 필요한 항목이 여전히 제안에 있기 때문입니다.

단점은 DisposablePromise 와 같은 것을 현명한 방식으로 엔지니어링하는 것이 매우 중요하다는 것입니다... 솔직히 제 구현이 작동하는지조차 모르겠습니다 😆 (어떤 이유로 비동기식으로 생각하는 데 너무 어려움을 겪고 있습니다. 하아).

이 스레드에 <3 u longtimes!

@chaffeqa Bluebird 구현은 얼마나 복잡합니까? 어쩌면 우리는 그것을 추출하고 기본 약속 위에 추가할 수 있습니까?

@chaffeqa 최악의 시나리오 - 만지기에 너무 위험하다고 판단되는 경우 다른 모든 Bluebird 사용법을 제거하고 복잡성으로 인해 이것을 유지할 수 있습니다. 이상적이지는 않지만 결국 using 가 발생합니다.

불행히도 꽤 복잡 합니다 ... 블루버드가 약속 수명 주기를 제어한다는 사실에 구현을 피기백합니다. 가장 좋은 방법은 무엇을 하려는지 확인하고(위의 using 링크에 매우 가깝습니다) 가능한 한 간단하고 성능이 뛰어난 심을 만드는 것입니다.

문제는 파이프라인이 Bluebird 스타일 프라미스 여야 하며, 올바르게 이해하면 기본 프라미스의 성능을 준수하지 않습니다(따라서 모든 추적 + 기본 비동기 기능을 잃게 됨).

나는 후드 아래에서 비동기 부분에 대한 기본 약속을 사용하지만 컨텍스트를 바인딩하고 disposer 와 같은 필요한 사용법을 구현하는 기능을 제공하는 것을 훨씬 더 선호합니다.

참고로 제 생각에는 실제로 knex에서 usage 및 .disposer 를 최소한으로 사용하므로 접근 방식이 더 높은 수준으로 이동하는 것이 더 나을까요?

실험할만한 가치가 있습니다 :)

oo 또한 https://github.com/petkaantonov/bluebird/issues/1593 을 기반으로 찾은 옵션 입니다.

어느 쪽이든, 좋은 단계는 이전 분기에서 시작한 것입니다. 여기에서 실제로 BluebirdPromise 인 모든 Promise 사용을 분리하여 삭제를 시작할 수 있습니다. DisposablePromise 또는 BluebirdNativePromise 와 같은 대체품에서.

@chaffeqa Bluebird.setScheduler(fn => Promise.resolve().then(fn)) 부분을 말씀하시는 건가요?
전체적인 전환이 정말 순조롭게 진행되고 있습니다! Disposer를 Bluebird에 유지하면서 내부적으로 기본 약속을 사용하도록 할 수 있다면 실제로 좋은 솔루션이 될 수 있습니다.

좋습니다. 따라서 다음 항목은 여전히 ​​주의가 필요합니다.
https://github.com/tgriesser/knex/issues/3257
https://github.com/tgrisser/knex/issues/3286
https://github.com/tgrisser/knex/issues/3256

도움을 주시면 감사하겠습니다!

네이티브 프라미스를 사용하지 않으면 async_hooks 를 사용할 때 nodejs/node#22360 이 발생하여 현재 컨텍스트가 손실된다는 점도 언급하고 싶었습니다.

해결 방법은 https://github.com/TimBeyer/cls-bluebird 패치를 사용하는 것입니다.

참고로 Node v8용 LTS는 올해 종료됩니다.

@Bessonov 컨텍스트? 최소 노드를 10으로 범핑하면 이 문제에 어떤 영향을 줍니까? 노드 6 지원은 이미 중단되었습니다.

나는 knex 코드 베이스에 익숙하지 않지만 블루버드를 제거하는 데 도움이 될 수 있는 몇 가지 기능이 있을 수 있습니다. 예를 들어, 노드 10은 Promise.finally 를 지원합니다.

하지만 어쨌든 이 주제에 대한 진행 상황을 보게 되어 기쁩니다 :+1:

disposer 패턴에 대해 - 일회용 약속을 반환하는 선택적 콜백을 추가할 수 있습니까?
(트랜잭션과 마찬가지로)

getDisposableConnection(config, cb) {
    const connection = await getConnection(config)

   // user want autodisposable connection
    if (cb) 
      Promise.resolve(cb(connection)).then(() => connection.dispose())
   // user will dispose by himself
   return connection
}

어떤 수준의 Promise 라이브러리 독립성이 필요합니까?
1) 모두 기본 약속을 사용합니다.
2) 내부 기본 약속, 사용자는 인터페이스에 대한 자신의 약속 라이브러리를 설정할 수 있습니다.
3) 사용자는 내부 및 인터페이스에 대한 promise lib를 설정할 수 있습니다.

이 문제의 현재 상태는 무엇입니까? 일반적으로 knex는 async await와 함께 작동하지만 typescript는 기본 promise가 아닌 메서드를 기다리고 있다는 경고를 보고합니다.

그래서 원래 문제 질문에 대답합니다. 현재 해결 방법은 // tslint:disable-next-line: await-promise 와 같은 것을 기다리고 추가하는 것입니다.

@maximelkin 나는 옵션 1에 투표합니다. 장기적으로 나는 모든 promise 라이브러리가 더 이상 사용되지 않기를 바랍니다.

id 두 번째, 이 시점에서 우리는 대부분의 브라우저에 대해서도 약속한 폴리필을 넘어섰습니다.

@Bessonov는 현재 knex에 의존하며 정확히 블루버드가 필요한 라이브러리(및 아마도 프로젝트)에 의존합니다.

우리는 그들에게 몇 가지 대체 솔루션을 제공해야합니다

@Bessonov는 현재 knex에 의존하는 라이브러리(및 아마도 프로젝트)에 따라 정확히 블루버드가 필요하며 이에 대한 대체 솔루션을 제공해야 합니다.

knex의 사용자가 블루버드에 의존하는지 여부는 중요하지 않습니다. Knex는 여전히 기본 프라미스를 사용할 수 있으며 블루버드 프라미스와 잘 상호 운용됩니다. 우리는 어떠한 대체도 하지 말아야 합니다.

그래서 이 문제는 Promise 구현을 선택하는 기능에 대한 요청으로 시작되었습니다.
갑자기 돌연변이를 일으켜 이유 없이 블루버드를 제거하고 모든 부양가족을 파괴했습니다. 경고, 변경 로그, 대체 및 주요 릴리스 옵션이 없습니다.

하지만 지금은 모든 1.5 타이프스크립트 사용자들이 만족하고 있다고 생각합니다.

그래서 이 문제는 Promise 구현을 선택하는 기능에 대한 요청으로 시작되었습니다.
갑자기 돌연변이를 일으켜 이유 없이 블루버드를 제거하고 모든 부양가족을 파괴했습니다. 경고, 변경 로그, 대체 및 주요 릴리스 옵션이 없습니다.

최소한 knex 0.x 버전의 이전 버전은 잠재적인 변경 사항이 있는 주요 릴리스로 간주되었으므로 0.20.x로 업데이트하는 것만 안전한 업그레이드로 간주되어야 합니다(버전 번호 < 1일 때 semver는 실제로 느슨합니다).

블루버드 제거는 오랫동안 논의되어 왔지만 이 문제만 있는 것은 아닙니다.

이유없이 블루버드 제거

블루버드를 제거한 이유가 없습니다. knex 약속과 함께 여전히 외부에서 블루버드를 사용할 수 있습니다. bluebird를 삭제하는 큰 이유 중 하나는 async 함수가 암시적으로 기본 약속을 생성하므로 앞으로 Bluebird를 계속 사용하려면 이유 없이 knex API에 추가 블루버드 래핑 코드가 추가되어야 한다는 것입니다.

경고 없이 변경 로그,

동의. 나는 최신 변경 로그를 조사했습니다... 슬프게도 버전 간의 주요 변경 사항을 나열하지 못한 것 같습니다. 변경 사항을 실제로 지적하기 위해 변경 로그를 작성할 때 더 주의해야 하며, 이는 이전 API를 손상시킵니다. 예를 들어 많은 타이핑 변경 사항은 실제로 오래된 TS 코드를 손상시킵니다.

ioredis 프로젝트 https://github.com/luin/ioredis/commit/da60b8b에서도 동일한 문제가 있었습니다. 그들은 네이티브 프라미스를 지원하기를 원했고 사람들은 정말 좋은 솔루션을 만들었습니다. 그들은 모든 커스텀 프라미스 라이브러리를 지원하는 옵션을 추가했고 기본적으로 네이티브 프라미스를 사용합니다. 왜 안 돼? 사용자 지정 약속 라이브러리 설정은 빠르고 모든 애플리케이션 코드를 패치할 필요가 없습니다.

Bluebird를 계속 사용하려면 아무런 이유 없이 knex API에 추가 bluebird 래핑 코드가 필요했을 것입니다.

예. 그러나 명시적으로 지정된 경우 블루버드(또는 다른 Promise 라이브러리)에서 모듈 호출을 래핑하지 않는 이유는 무엇입니까? 이것은 하나의 간단한 래퍼이고 오버헤드가 없으며 사용자가 원하는 모든 promise 라이브러리를 사용할 수 있도록 합니다. 아무도 블루버드가 필요하지 않다면 아무도 이 옵션을 사용하지 않을 것이며 제때에 안전하게 폐기할 수 있습니다.

또한, 나는 다음과 같은 의견을 보았습니다.

장기적으로 모든 promise 라이브러리가 쓸모없게 되기를 바랍니다.

그러나 IMHO에는 두 가지 잘못된 가정이 있습니다.

• Bluebird가 더 빠르기 때문에 사용됩니다.
• Bluebird는 폴리필로 사용됩니다.

async-await 하나의 라이너를 넘어서는 정말 복잡한 응용 프로그램의 경우는 그렇지 않다고 생각합니다.
Bluebird에는 타임아웃, 사용자 정의 오류 처리, 동시성 매핑, 취소, 축소 등과 같이 복잡한 비동기 흐름에 절대적으로 필요한 많은 기능이 있습니다. 이러한 모든 기능은 기본 프라미스로 구현될 수 있지만 이는 쓸모없는 상용구입니다. 2020년에도 우리는 이 모든 상용구를 원하지 않기 때문에 노드 12에서 여전히 블루버드를 사용하고 있습니다.

왜 안 돼? 사용자 지정 약속 라이브러리 설정은 빠르고 모든 애플리케이션 코드를 패치할 필요가 없습니다.

내부적으로 async-await를 사용하는 모든 것은 약속을 기본 약속으로 강제 변환하므로 옵션은 사용자 지정 약속에서 각 메서드의 출력을 래핑하거나 내부 코드에서 async-await를 금지하게 됩니다. 그것은 첫 번째 검사에서 보일 수 있는 것처럼 작은 사업이 아닙니다.

@큐바이트

그것은 첫 번째 검사에서 보일 수 있는 것처럼 작은 사업이 아닙니다.

아니요, 이미 말했듯이 간단합니다. 내보낸 외부 기능에 대한 래퍼를 만들고 그게 전부입니다. 약 10줄의 코드. 그리고 원하는 방식으로 모든 내부 코드를 작성하십시오.

@jehy : 10줄의 코드를 구현하는 간단한 방법이 보이면 자유롭게 PR을 제출하세요.

나는 또한 해결 방법을 찾기 위해 오늘 시간을 할애할 것입니다.

그만한 가치가 있기 때문에 bluebird API의 대부분은 다음 패키지의 기본 약속을 사용하여 동일하거나 가까운 API로 복제됩니다. https://github.com/sindresorhus/promise-fun

그만한 가치가 있기 때문에 bluebird API의 대부분은 이러한 패키지의 기본 약속을 사용하여 동일하거나 가까운 API로 복제됩니다.

1 대신 ~50 패키지? 진지하게?

예, 대부분의 경우 몇 가지만 필요합니다(예: p-map). 물론 마일리지는 다를 수 있습니다. 그것은 당신이 원하는 것에 대한 하나의 잠재적인 경로로만 제공됩니다.

@jehy : 다음은 애플리케이션 코드 내에서 임시 해결 방법으로 시도할 수 있는 것입니다.

const Bluebird = require('bluebird');


const prototypesNeedingDecoration = [
  require('knex/lib/query/builder').prototype,
  require('knex/lib/schema/builder').prototype,
  require('knex/lib/transaction').prototype,
  require('knex/lib/raw').prototype,
];

const corePromiseMethods = ["then", "catch", "finally"];


function decoratePromiseMethods(target) {
  for(const m of corePromiseMethods) {
    const original = target[m];

    target[m] = function(...args) {
      return Bluebird.resolve(original.apply(this, args))
    }
  }  
}

function hackBluebird() {
  for(const target of prototypesNeedingDecoration) {
    decoratePromiseMethods(target);
  }
}


hackBluebird();

이것은 전체 문제에 대한 적절한 해결책이 아닙니다. 비슷한 방식으로 장식해야 하는 knex 내에 생성된 다른 임시 개체가 있습니다.

또한 면책 조항: 해결 방법 ☝️은 테스트가 거의 없었습니다. 따라서 애플리케이션의 테스트를 다시 실행하여 문제가 없는지 확인해야 합니다.

여기에 2센트를 추가하고 싶었습니다. 부정적인 피드백에 관계없이 이 마이그레이션에 투입된 모든 작업에 정말 감사드립니다.

우리 앱의 관점에서 knex는 Bluebird를 요구하는 마지막 라이브러리였으며 완전한 기본 약속 지원을 준수한다는 것은 다음을 의미합니다.

1. 더 이상 지저분한 스택 추적이 없습니다.
2. SSR 무게를 적당히 줄였습니다.
3. 네이티브 비동기 대기가 이제 블루버드보다 더 성능이 좋기 때문에 성능이 향상되었습니다(점점 더 커지고 있습니다!).

es 표준을 향해 계속 달려가는 것은 대단한 승리입니다... 그리고 라이브러리 관리자에게 그게 쉬운 일이 아니라는 것을 알고 있기 때문에 여러분에게 소리치고 싶었고 그런 부담을 맡아주셔서 감사합니다!

변경으로 고통받는 사람들을 위해: 도움이 되었으면 하는 바램입니다. 디버깅이나 마이그레이션에 도움이 필요하시면 연락주세요!

@chaffeqa 이 피드백에 감사드립니다. 큰 의미가 있습니다!

@jehy : 제안된 해결 방법을 시도할 기회가 있었습니까? 그렇다면 즉각적인 문제가 해결되었습니까?