Knex: Wie konfiguriere ich, um das Standard-ES6-Versprechen zu verwenden?

Neugierig: Sie möchten eine schnellere Bibliothek durch eine langsamere integrierte ersetzen? Auf dem Client wäre es egal, aber die Knotengeschwindigkeit ist ein Faktor. Was ist Ihre Begründung dafür?

@johanneslumpe Es ist ein Faktor in einigen Anwendungen, bei knex bezweifle ich sehr, dass die verwendete Promise -Bibliothek einen signifikanten Einfluss auf die Leistung hat. Es wurde diskutiert, dass wir den gesamten Promise -Code schreiben sollten, um nur A+-APIs zu verwenden, damit bluebird nicht benötigt würde.

Danach sollte es einfach zu überschreiben sein, welche Promise-Bibliothek verwendet wird.

Ich stimme zu, dass es sich in einer Bibliothek wie Knex sinnlos anfühlt. Angesichts der Tatsache, dass die Codebasis von Knex bereits intern ihre eigene Datei „ promise.js “ importiert, wäre sie technisch immer noch sehr einfach zu implementieren, vorausgesetzt, die API ist die gleiche _(was ich nicht sicher bin?)_. In dieser Datei könnte man standardmäßig auf globale Zusagen setzen, andernfalls eine konfigurierte Bibliothek erfordern oder so etwas.

es geht darum, den Benutzern die Wahl zu lassen; Bieten Sie Benutzern von Node V6+ die Möglichkeit, Abhängigkeiten von Drittanbietern so gering wie möglich zu verwalten.

Neugierig: Sie möchten eine schnellere Bibliothek durch eine langsamere integrierte ersetzen?

Was Sie sagen, mag in der Vergangenheit wahr sein, aber wie sieht es jetzt oder 6 Monate später aus? (Ich habe etwas gesucht und kann nur einige Benchmarks von 2015 herausfinden, wenn Sie neuere Vergleiche haben, posten Sie bitte einige Links)
Ich glaube, der springende Punkt, Promise zum ES6-Standard zu machen, ist, dass die Leute Promise einfach verwenden können, sich nicht auf eine Bibliothek eines Drittanbieters verlassen müssen und das Kernteam von Node oder V8 den Leistungsunterschied nicht für immer ignorieren kann, solange Die Open-Source-Lizenzen der beiden Projekte sind kompatibel, sie können sogar Code ausleihen; oder geben Sie ihnen einfach etwas Zeit. Ich glaube, das eingebaute Versprechen kann schneller und besser sein.

siehe AWS-SDK von Amazon: Es verwendet standardmäßig auch das global verfügbare Promise; während Sie dem Benutzer die Möglichkeit geben, auch die bevorzugte Promise-Bibliothek zu konfigurieren

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

Es dreht sich alles um Entscheidungen

Bei näherer Überlegung wird es nicht so einfach sein, wie eine einzelne Datei zu ändern. Knex stützt sich derzeit stark auf Bluebird-Hilfsfunktionen wie .timeout , .tap , .reduce , .map und so weiter, von denen ich annehme und erwarte, dass sie nicht existieren in ES6 verspricht.

Ich bin daran interessiert, die Versprechungen von ES6 zu unterstützen. Idealerweise benötigen wir ein zweites Argument für den Knex -Konstruktor, der einen Promise -Konstruktor akzeptiert. Die Rückkompatibilität würde wie folgt erreicht:

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

Vielleicht könnten wir map , filter usw. bedingt als Alias ​​verwenden, basierend auf ihrer Anwesenheit auf den bereitgestellten Promise.prototype ?

Ich denke, das sollte ziemlich weit unten auf der Prioritätenliste stehen, und es würde eine ganze Menge interner Änderungen erfordern, ganz zu schweigen von der Leistungseinbuße (obwohl ich zugegebenermaßen seit einiger Zeit keine Benchmarks mehr gesehen habe) und der Tatsache, dass sich die Leute darauf verlassen könnten auf der Tatsache, dass das zurückgegebene Versprechen ein Bluebird ist (für bedingte catch usw.).

Ich würde eher warten, bis async/await in einem stabilen Knoten landet, um dies zu beheben.

für Leute, die die minimalen Abhängigkeiten von Drittanbietern wollen, kann das native Promise besser sein,

Wie @google-cloud und vielen anderen Bibliotheken können Sie standardmäßig native Promise verwenden und einen Promise-Parameter akzeptieren, wenn Sie Bibliotheken von Drittanbietern verwenden möchten

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

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

@tgriesser Ich weiß, dass dies ein altes Problem ist, aber wir haben jetzt async / await sowohl in Stable als auch in Carbon.

Da es für async/await bevorzugt wird, mit nativen Versprechungen zu arbeiten ( gemäß der Spezifikation müssen async -Funktionen eine native Versprechung zurückgeben ), hat dies eine höhere Priorität?

Wenn nativer Versprechungssupport etwas ist, das Knex gerne hätte, aber derzeit nicht auf dem Radar ist, wäre eine PR willkommen?

Vielen Dank für Ihre Zeit.

@malexdev async Funktionen geben native Versprechungen zurück, die derzeit nicht viel mit Knex zu tun haben. Das bedeutet nicht, dass await native Versprechungen benötigt, um richtig zu funktionieren. Können Sie klarstellen, in welchem ​​Fall dies ein Problem/Vorteil ist (mit Ausnahme des Wegfalls einer Abhängigkeit)?

Davon abgesehen bin ich nicht dagegen, Bluebird fallen zu lassen, aber es braucht wirklich einige interne Änderungen. Möglicherweise müssen wir einige Methoden implementieren, die derzeit von bluebird für Knex-APIs verfügbar gemacht werden, es sei denn, alte Funktionen sind unter einem Konfigurationsschalter verborgen und standardmäßig würden native Zusagen verwendet. Auf diese Weise wäre die Migration für Leute, die sich darauf verlassen haben, dass Knex bluebird Versprechungen zurückgibt, nicht unmöglich.

@elhigu Der Hauptvorteil für mich persönlich besteht darin, dass ich TypeScript mit einer TSLint-Regel verwende, die die Verwendung nativer Versprechungen für await erzwingt, sodass ich alle Knex-Aufrufe in einem Promise.resolve() verpacken muss. Mir ist jedoch klar, dass dies nichts speziell mit Knex zu tun hat und wahrscheinlich ein Problem ist, das nur für mich gilt.

Abgesehen davon ist es meiner Meinung nach besser, weniger Abhängigkeiten von Drittanbietern zu haben, und wie @c0b erwähnte, sind mehr Optionen nie eine schlechte Sache.

Mir ist klar, dass es eine Menge Arbeit wäre, was einer der Gründe dafür ist, dass ich mehr als glücklich bin, Zeit damit zu verbringen, wenn Knex daran interessiert ist, sich darauf hinzubewegen.

Ja, ich bin wegen eines Typoskript-Problems hier gelandet – ich verwende Knex als SQL-Engine für meine Multi-Storage-Datenspeicherbibliothek, und obwohl ich ambivalent gegenüber nativen vs. Bluebird-Versprechungen bin, kann ich es nicht einfach verwenden typoskript auf knex aus diesem grund. Ich behandle Knex-Thenables so, dass sie der nativen Spezifikation folgen (ich verwende keine der Bluebird-Erweiterungen), aber Typoskript stört mich, wenn ich einen Bluebird zurückgebewenn die Methodendeklaration ein Promise ist.

Dies ist hier eine Art zwei Ebenen tief, da wir uns sowohl mit der Promise-Implementierung als auch mit den Typisierungen für Knex befassen (die von verschiedenen Entwicklern gehandhabt werden), aber ich stecke hier im Grunde fest – ich breche technisch den Typvertrag durch einen Bluebird zurückgeben, wenn ich ein Promise deklariert habe (ich schätze, es gibt Dinge in der Promise-API, die Bluebird nicht unterstützt?), aber ich habe auch wirklich keine Lust, überall einen Haufen return Promise.resolve(bluebirdthing) zu platzieren.

Ich habe im vergangenen Jahr genug Zeit damit verbracht, in Knex-Eingeweiden herumzustöbern und im Allgemeinen mit Versprechen zu arbeiten, dass ich bereit wäre, hier etwas aufzugreifen und an einer PR zu arbeiten, um die Promise-Implementierung zu modularisieren, wenn die Leute wollen - würden Sie offen für PR? Es würde am Ende so etwas wie das sein, was @elhigu erwähnt hat - einige der Hilfsfunktionen neu implementieren, um den Promise-Konstruktor zu verwenden, der bei der Instanziierung übergeben wurde, um Codeumschreibungen zu vermeiden. Bei der Leistung bin ich mir natürlich nicht sicher, aber das kann man messen.

Es wäre auch cool, alles mit async / await fertig zu machen, und ich habe es nicht eilig, dies zu beheben (letztendlich kennzeichne ich für meinen Anwendungsfall nur Dinge als any und kümmere mich darum Codebranches, als wären sie Javascript statt Typoskript).

@ericeslinger Ich verstehe nicht, warum die verwendete echte Promise-Implementierung Probleme mit TypeScript verursachen würde. Ich habe anderthalb Jahre ohne Probleme Bluebird- und native Promises gemischt ...

Ich habe einfach keine Typisierungen verwendet, die Typen für Bluebird einführen würden, ich sage Typoskript-Typisierungen nur, dass es sich um normale Promises handelt, und es wird kein Unterschied festgestellt (es wird sich beschweren, wenn ich versuche, die speziellen Methoden von Bluebird zu verwenden).

Welche Typescript-Version und gibt es ein Beispielprojekt zum Reproduzieren ... zB Github Repo mit npm-Startskript.

Dies ist hier eine Art zwei Ebenen tief, da wir uns sowohl mit der Promise-Implementierung als auch mit den Typisierungen für Knex befassen (die von verschiedenen Entwicklern gehandhabt werden), aber ich stecke hier im Grunde fest – ich breche technisch den Typvertrag durch einen Bluebird zurückzugeben, wenn ich ein Promise deklariert habe (ich schätze, es gibt Dinge in der Promise-API, die Bluebird nicht unterstützt?), aber ich habe wirklich keine Lust, überall einen Haufen Return Promise.resolve(bluebirdthing) zu platzieren.

Sind das Knex-Eingaben von npm? Sind Bluebird-Typisierungen von npm? Welche Pakete? Es fällt mir schwer zu verstehen, warum das passieren würde. Wenn es einen separaten Bluebird-Typ gibt, sollte er vom nativen Promise geerbt werden und von APIs zurückgegeben werden können, die mitteilen, dass sie Promise zurückgeben. Aus der Beschreibung geht hervor, dass das Problem sehr fehlerhafte Typisierungsimplementierungen sind. Und das ist für dieses Problem nicht relevant (Typoskript kümmert sich nicht um echte Typen, daher weiß es nicht, was Knex zurückgibt).

Ich erhalte meine Eingaben aus dem Repo DefinitelyTyped , indem ich @types/knex installiere. Diese Definition zieht @types/bluebird sich, und alle Knex-Methoden werden als Bluebird-Objekte zurückgegeben.

Konkret kann ich das nicht:

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[]>

mit diesen Typisierungen. Dies liegt daran, dass knex.select().then() eingegeben wird, um einen Bluebird im DefinitelyTyped-Repo zurückzugeben, und diese verketten sich, um mehr Bluebirds zu erstellen, und sagen etwas wie return foo as Promise<any>() , wenn foo ein Bluebird istwird fehlschlagen (zumindest in Typoskript 2.4), da Bluebirds keinen Promises zuweisbar sind (ihnen fehlt [Symbol.toStringTag] gemäß this , daher wäre es ein Fehler, wenn auch ein kleiner Fehler, das eine zum anderen zu zwingen).

Stattdessen kann ich zu ändern

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

oder machen Sie andere Tricks, um alle knex-Aufrufe in einen nativen Promise.resolve()-Aufruf zu verpacken. Dies führt dazu, dass Typescript aufhört, sich hinter meinen Bibliotheksfunktionen zu beschweren, während ich weiterhin Knex-Eingaben in meinen Bibliotheksfunktionen verwenden kann.

Vor gestern hatte ich @types/knex überhaupt nicht verwendet – ich habe nur knex als any eingegeben. Der Code funktioniert zur Laufzeit so oder so gut (zumindest für meinen Anwendungsfall), es ist nur

@elhigu : Das Problem sind nicht fehlerhafte Eingabeimplementierungen.
TypeScript legt den Typ für async -Funktionen als Promise<[type]> , was gemäß JS-Spezifikation korrekt ist.
Knex gibt Bluebird<[type]> zurück, was die Eingaben genau widerspiegeln.

Ich habe einfach keine Typisierungen verwendet, die Typen für Bluebird einführen würden, ich sage Typoskript-Typisierungen nur, dass es sich um normale Promises handelt, und es wird kein Unterschied festgestellt

Dies lügt den Compiler an, da Knex-Funktionen tatsächlich Bluebird s zurückgeben. Nicht interessiert.
Sie haben Recht, dass Bluebirds mit Promises kompatibel sind, aber ein Teil des Deals mit TypeScript ist, dass Sie tatsächlich zurückgeben, was Sie sagen, dass Sie zurückgeben.

Bei der Rückgabe von Bluebird von einer Funktion, die so eingegeben wurde, dass sie Promise zurückgibt, beschwert sich TypeScript, weil der Typ Bluebird nicht mit dem Typ Promise identisch ist.
Es gibt verschiedene Tricks, die wir machen können (wie z. B. das, was @ericeslinger über die Verwendung any oder das Einwickeln in Promise.resolve() erwähnt hat), aber am Ende des Tages verlieren wir durch solche Tricks viel davon was TypeScript bietet.

Letztendlich gibt es in Wirklichkeit mindestens zwei Benutzer, die sagen: „Die Verwendung nativer Versprechen ist uns wichtig, und wir sind bereit, die Arbeit zu investieren, um die Versprechungsfunktion allgemeiner zu machen“.

Mir ist klar, dass Sie nur versuchen zu helfen, aber ehrlich gesagt, anstatt zu hören "Sie könnten es so machen", würde ich gerne hören, ob die von mir / @ericeslinger / @c0b vorgeschlagenen Änderungen des Versprechens akzeptabel sind, damit ich entweder anfangen kann auf einer PR oder was.

@malexdev @ericeslinger Danke für die weiteren Infos! Es sieht so aus, als wäre es tatsächlich nicht möglich, Ihre eigene Klasse von Promise zu erben. Dies könnte der Grund sein, warum die Rückgabe von Bluebirds von einer Funktion, die als Promise<> eingegeben wurde, fehlschlägt :(

@ericeslinger Auf jeden Fall ist dies kein Problem, wenn Sie async -Funktionen erstellen, da sie die Ergebnisse automatisch intern in native Versprechungen umschließen. Folgendes entspricht problemlos den Eingaben von @types/bluebird und kompiliert entweder nach ES2015 oder 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);
});

Ausgang:

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

Wenn Sie also vorerst Knex-APIs verwenden, müssen Sie tatsächlich angeben, dass Sie Bluebird zurückgeben, es sei denn, Sie verwenden asynchrone Funktionen / Methoden, die Bluebird automatisch in native Promises umschließen.

@malexdev

Dies lügt den Compiler an, da Knex-Funktionen tatsächlich Bluebirds zurückgeben. Nicht interessiert.
Sie haben Recht, dass Bluebirds mit Promises kompatibel sind, aber ein Teil des Deals mit TypeScript ist, dass Sie tatsächlich zurückgeben, was Sie sagen, dass Sie zurückgeben.

Eigentlich geht es bei Typoskript darum, dass es ausreicht, dass das zurückgegebene Objekt die Schnittstelle korrekt implementiert, zum Beispiel ist dies vollkommen in Ordnung:

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;
}

Es bringt instanceof durcheinander, aber Typoskript hat nicht einmal versprochen, dass Sie die native Promise-Instanz zurückgegeben haben, sondern nur die Schnittstelle.

Wenn ein Bluebird von einer Funktion zurückgegeben wird, die so eingegeben wurde, dass sie Promise zurückgibt, beschwert sich TypeScript, weil der Typ Bluebird nicht mit dem Typ Promise identisch ist.
Es gibt verschiedene Tricks, die wir anwenden können (z. B. das, was @ericeslinger über die Verwendung beliebiger oder das Einschließen von Promise.resolve() erwähnt hat), aber am Ende des Tages verlieren wir durch solche Tricks viel von dem, was TypeScript bietet.

Ich würde es hassen zu sehen, wie Leute diese Art von Tricks machen / JS-Implementierungen ändern müssen, nur um schlechte Eingaben zu befriedigen.

Letztendlich gibt es in Wirklichkeit mindestens zwei Benutzer, die sagen: „Die Verwendung nativer Versprechen ist uns wichtig, und wir sind bereit, die Arbeit zu investieren, um die Versprechungsfunktion allgemeiner zu machen“.

Mir ist klar, dass Sie nur versuchen zu helfen, aber ehrlich gesagt, anstatt zu hören "Sie könnten es so machen", würde ich gerne hören, ob die von mir / @ericeslinger / @c0b vorgeschlagenen Änderungen des Versprechens akzeptabel sind, damit ich entweder anfangen kann auf einer PR oder was.

Danke fürs Verständnis :) Die Änderung von Knex zur Verwendung nativer Versprechungen wurde bereits letztes Jahr begonnen und bis zu einem gewissen Punkt implementiert, dann wurde es von @tgriesser wieder geändert, daher würde ich sagen, dass es vorerst besser ist, diese Änderung nicht zu starten.

Außerdem betrachte ich diese Typoskript-Probleme, die in diesem Thread erwähnt werden, immer noch als Probleme bei der Typing-Deklaration (warum Bluebird Promise nicht korrekt implementiert ... muss ich mich eingehender damit befassen?) Als Probleme bei der Knex-Implementierung.

Abgesehen davon bin ich nicht dagegen, Bluebird in einiger Zeit loszuwerden, wenn ich hier nur zwei getrennte Probleme sehe.

:+1: für native Promises.

@elhigu :

Eigentlich geht es bei Typoskript darum, dass es ausreicht, dass das zurückgegebene Objekt die Schnittstelle korrekt implementiert

Fair genug. Ich bleibe immer noch bei meiner Meinung, dass weniger Abhängigkeiten und mehr Auswahl besser sind, aber ich verstehe jetzt, was Sie mit fehlerhaften Typisierungen gemeint haben.

Also immer noch 👍 für native Promises (bei denen ich immer noch bereit bin zu helfen), aber ich sehe jetzt, dass mein unmittelbares Problem gelöst werden kann, indem Bluebird-Eingaben behoben werden. Danke für die Information.

Also habe ich angefangen, TypeScript ziemlich oft zu verwenden, und ich liebe es und erkenne jetzt, dass die Probleme hier ein echter Schmerzpunkt sind. Da async/await im jüngsten Node-Land immer mehr Fuß fasst, fns das Bluebird-Dienstprogramm fns ( map , reduce , tap , bind , return ) werden weniger nützlich. Ich wäre cool, wenn ich Bluebird weiterhin intern verwenden würde, aber die öffentliche API des Knex-Abfragegenerators offiziell "ablehnen" und alle zusätzlichen Dienstprogrammmethoden zurückgeben würde.

Mit dieser Zusammenführung könnten wir dann die TypeScript-Definitionen aktualisieren, um die Bluebird-Eingaben (mit Ausnahme von toBluebird ) zu löschen und die Bluebird-Eingaben in Promise-Eingaben zu ändern.

Wenn jemand Bandbreite hat, möchte dies angehen, hier ist, was ich für einen Aktionsplan denke:

• [ ] Fügen Sie eine Verfallswarnung für alle Proxy-Methoden von Bluebird hinzu ( tap , map , reduce , bind , return ).
• [ ] Fügen Sie eine .toBluebird() -Methode hinzu, die ein Migrationspfad für diejenigen sein wird, die weiterhin Bluebird verwenden möchten (sie können dies mit einem einfachen Suchen/Ersetzen aller Aufrufe der oben genannten Methoden tun und sie einfach vorher hinzufügen die heißen)
• [ ] Sobald dies zusammengeführt/neuer Release-Schnitt (0.15) ist, können wir die Typescript-Definitionen aktualisieren
• [ ] Irgendwann können wir diese Methoden ganz fallen lassen. Diese einfachere API ebnet den Weg für die Verwendung nativer Promises & async/await, wenn es sinnvoll ist.

Lassen Sie mich wissen, ob dies sinnvoll ist und ob jemand daran interessiert ist, dies zu versuchen.

Wäre auf jeden Fall daran interessiert, dabei zu helfen.

Bedeutet dies, dass Knex anfangen würde, seine eigenen TypeScript-Definitionen zu pflegen? Würde es uns ermöglichen, einige coole Sachen mit Generika zu machen, die automatisch generierte Typisierungen niemals unterstützen werden.

Ich habe diesen Fork als ersten Versuch gestartet, Unterstützung für native Promises hinzuzufügen:
https://github.com/tgriesser/knex/pull/2523/files

Like diesen Kommentar von 2016:

Merkwürdig: Sie möchten eine schnellere Bibliothek durch eine langsamere integrierte ersetzen

Erstaunlich, wie viel sich in 2 Jahren ändern kann.

Wenn ein Bluebird von einer Funktion zurückgegeben wird, die so eingegeben wurde, dass sie Promise zurückgibt, beschwert sich TypeScript, weil der Typ Bluebird nicht mit dem Typ Promise identisch ist.

@malexdev Tatsächlich verwendet Typoskript strukturelle Typisierung (Flow verwendet nominale Typisierung und würde so funktionieren, wie Sie es beschreiben). Solange Ihr Typ also die Promise -Schnittstelle erfüllt, ist er mit Promise kompatibel, ob es explizit extends / implements es oder nicht.

Wie geht das voran? Ich denke, ein guter erster Schritt wäre, Bluebird-spezifische Methodenaufrufe innerhalb von Knex auszuklammern (dh sie noch nicht wirklich zu entfernen). Das Entfernen von Bluebird und das Bereitstellen einer Option für einen benutzerdefinierten Promise-Konstruktor würden folgen (und Leuten, die Bluebird-Methoden verwenden, einen Upgrade-Pfad geben).

Ich beginne nicht mit der Arbeit am ersten Schritt, wenn es keine Einwände gibt. Bestehende Arbeit scheint nachgelassen zu haben.

@qubyte Ich glaube nicht, dass es eine aktive Anstrengung gibt, die Änderung vorzunehmen, hier und da wurden inkrementelle Änderungen vorgenommen, aber das war es auch schon.

OK. In meiner nächsten freien Zeit werde ich ein paar so kleine Änderungen wie möglich vornehmen, um jede Methode zu berücksichtigen.

@tgriesser Irgendwelche Meinungen, wann wir mit dieser fortfahren sollten (wenn überhaupt)? Für mich würde sich der nächste April wie ein angemessener Zeitpunkt dafür anhören, wenn Node 6 LTS das Ende der Zeile erreicht.

Interessante Informationen im Jahr 2018:

promises-native-async-await hat eine bessere Leistung als promises-bluebird in Knoten 10.
Referenz: https://github.com/petkaantonov/bluebird/tree/master/benchmark

Leistung ist also kein Grund mehr, bluebird zu behalten. Wir sollten async/await wählen.

Promises-native-async-await hat eine bessere Leistung

Das ist auch das, woran ich 2016 fest geglaubt habe, dass sich der native Weg viel schneller verbessern würde, nur weil er der Kern der Nodejs-Community ist und mehr Leute sich darum kümmern, mehr als alle Bibliotheken von Drittanbietern

Während das Ticket eingereicht wurde, um eine Auswahl zu treffen, gibt es so viele konkurrierende Promise -Implementierungen, dass es einfach nicht gut ist, für immer auf Bluebird zu setzen

Gibt es hierzu ein Update?

@cfanoulis Dasselbe steht immer noch. Wenn der April kommt, können wir die Unterstützung für Node 6 einstellen und mit dem Entfernen von Bluebird beginnen.

irgendein Update für 2019? /cc an einige zentrale Mitwirkende oder Betreuer oder alle @hier , die sich darum kümmern: @johanneslumpe @tgriesser @wubzz @elhigu von https://github.com/tgriesser/knex/graphs/contributors?type=c&from=2018-01- 01&bis=2019-12-31

Auf der anderen Seite ist die JavaScript-Community eine so dynamische, lebendige und manchmal grausame Welt, alle 3 oder 2 Jahre (oder sogar noch schneller) gibt es Ersatz für etwas, das wir vorher kannten, denken Sie an Grunt, Gulp => Webpack, die Tools, Bibliotheken, Frameworks stehen auf allen Ebenen im vollen Wettbewerb. Wenn Sie also aufhören, Innovationen einzubringen oder die Unterstützung neuer Standards zu verlangsamen (denken Sie an ES2019 async/await iterators ...), werden Sie irgendwann ersetzt

Ich habe nur ein paar einfache Nachforschungen angestellt, es sieht so aus, als gäbe es auf DB-ORM-Ebene auch viele Alternativen, TypeORM könnte eine gute sein ... (ich höre hier auf, um nicht mehr zu sagen ...)
https://bestofjs.org/tags/db
https://bestofjs.org/projects/typeorm

@ c0b keine Notwendigkeit zu cc. Ich bekomme sowieso Mails von allen Kommentaren. @kibertoad hat gerade alles gesagt, was in seinem letzten Kommentar gesagt werden musste ... Dieses Problem hat auch nichts damit zu tun, dass Knex async/await ES2019-Funktionen besser unterstützt, und Knex ist kein ORM, daher bin ich mir nicht sicher, was dieser Kommentar wirklich war Über.

Wenn Sie ein gutes ORM benötigen, kann ich objection.js empfehlen. Es ist auch auf Knex implementiert, hier ist ein ziemlich netter Thread darüber https://github.com/Vincit/objection.js/issues/1069

Irgendwann wird dieser Knex ersetzt, aber nicht durch irgendein ORM. Es könnte durch einen anderen Abfragegenerator ersetzt werden, der über eine sauberere Codebasis und eine konsistentere API verfügt. Wie zum Beispiel Knex 1.0 vielleicht ;)

Auch wenn Knex ersetzt wird, wäre ich damit völlig einverstanden, weniger Arbeit für mich: D

Ich glaube, es gibt WIP dazu: https://github.com/tgriesser/knex-next

Ich wollte nur noch erwähnen, dass die Nichtverwendung von nativen Versprechungen zu https://github.com/nodejs/node/issues/22360 führt, wenn async_hooks verwendet wird, wodurch der aktuelle Kontext verloren geht.

Glaubt mir, wir brauchen keine zusätzlichen Gründe um umzuziehen, wir wollen es genauso machen wie ihr alle :). Wir müssen jedoch noch ein paar weitere Korrekturen für den Node-6-Zweig veröffentlichen, und dann (endlich) werden wir ihn fallen lassen und damit beginnen, Bluebird schrittweise auslaufen zu lassen.

Nachdem #3227 zusammengeführt wurde, können wir endlich loslegen!

Ich weiß, dass Sie vorhin erwähnt haben , dass Sie bei dieser Migration Hilfe gebrauchen könnten. Wenn das immer noch die Richtung ist, in die Sie gehen möchten, könnten wir Ihnen irgendwie helfen?

Ich denke: Erstellen Sie ein Projekt, fügen Sie ein paar Aufgaben hinzu und sehen Sie, ob jemand (vielleicht habe ich Zeit) zugewiesen werden und einige Termine festlegen könnte?

@chaffeqa Wird bald einige detailliertere Aufgaben erstellen, habe #3250 für eine erste Runde einfacher Änderungen bereit. Hauptsächlich müssen wir die Verwendungen von bluebird.tap, bluebird.method und bluebird.try durch etwas natives ersetzen. Wenn Sie bereits etwas Zeit haben, können Sie versuchen, von #3250 abzuzweigen und sich alle verbleibenden „Bluebird“-Anforderungen anzusehen (ich würde empfehlen, mit nicht-dialektspezifischen zu beginnen, damit Sie die noch funktionierende Funktionalität schnell validieren können, indem Sie test:sqlite ohne Docker-Setup).

@qubyte Wenn Sie etwas beitragen möchten, ist jetzt der richtige Zeitpunkt!

@kibertoad kann ich async/await jetzt sicher verwenden?

Du meinst in der Knex-Codebasis? Sicher. In deinem eigenen warst du immer :-D

https://github.com/tgriesser/knex/issues/3253
https://github.com/tgriesser/knex/issues/3254
https://github.com/tgriesser/knex/issues/3255
https://github.com/tgriesser/knex/issues/3256
https://github.com/tgriesser/knex/issues/3257
https://github.com/tgriesser/knex/issues/3268
https://github.com/tgriesser/knex/issues/3286
stehen auf dem Spiel.

Tut mir leid, dass ich letzte Woche MIA war, die Dinge für unser Unternehmen laufen auf Hochtouren, also muss ich mich darauf konzentrieren.

Wollte den Kreis zu einigen der Diskussionen schließen, die wir zu einem der größeren Blöcke des Upgrades hatten: Ersetzen der Verwendung Disposer .

Es ist ein ziemlich tiefes Loch, wenn Sie anfangen, es hinunterzugehen, also brauchen Sie etwas gutes Engineering, um eine gute Kopie / Abstraktion zu liefern. Ich mache mir Sorgen, dass der Perf-Overhead von etwas ziemlich groß sein könnte (viel mehr Objekte werden erstellt, wenn die Promise-Kette wächst).

Ich habe tatsächlich mit ein paar POCs begonnen, und ich denke, dies ist der einfachste von ihnen:

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;
  }
}

Und ein anderer:

      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);
      };

Aber ich hatte noch keine Zeit, sie zu beweisen.

Ich denke, es könnte sich lohnen, andere Optionen zu untersuchen (Bluebird behalten, aber intern so konvertieren, dass native Versprechungen verwendet werden?), da diese Funktion im Repository vorhanden sein muss (es sei denn, Sie können sich bessere Ansätze vorstellen ... asynchrone Iteratoren? Ich würde gerne irgendwelche Gedanken des Bluebird-Teams hören, auch wenn es darum geht, diese Funktionalität zu abstrahieren, obwohl mein Bauchgefühl sagt, dass es ziemlich an die Bluebird-Implementierungshaken gebunden ist.

Ich würde sagen, wenn wir diesen Teil herausfinden können, sind die restlichen Aufgaben ziemlich einfach.

@chaffeqa Np, danke, dass du immer noch die Zeit findest, darauf zurückzukommen!
Ich bezweifle sehr, dass Bluebird-Leute offen für Vorschläge sind, ihre Implementierung ernsthaft zu überarbeiten, sie haben wiederholt den Punkt wiederholt, dass sie an diesem Punkt vor allem an Stabilität interessiert sind, und sie empfehlen den Leuten, tatsächlich native Versprechungen zu verwenden, es sei denn, man braucht wirklich erweiterte Funktionen bereitgestellt von Bluebird.
Angesichts der Tatsache, dass Node 8 derzeit die beliebteste Version von Node.js zu sein scheint (basierend auf den offiziellen Download-Statistiken von Node.js), fürchte ich, dass wir noch nicht zu einem asynchronen Iterator-basierten Ansatz übergehen können.
Welche Nachteile sehen Sie bei der internen Implementierung von DisposablePromise durch Knex? Da es das native Promise erweitert, nehme ich an, dass es keinen der Bluebird-Nachteile mit sich bringt, und nichts im Userspace muss darüber Bescheid wissen?

@ericeslinger FWIW, TS-Eingaben sollten im Master kein Problem mehr sein, wir geben unsere Versprechen jetzt als native ein, um Benutzer davon abzuhalten, sich auf Bluebird-Funktionen zu verlassen. Dies kann später zu Problemen führen, wenn native Promises etwas implementieren, das Bluebird-Promises nicht tun, daher möchten wir dennoch verwendete Promises so weit wie möglich ersetzen. Jeder Beitrag in dieser Richtung wäre sehr willkommen :)

Nüsse hab ich mir schon gedacht 😞
Ich stimme zu, dass es in diesem Fall wahrscheinlich der richtige Weg ist, so etwas wie DisposablePromise zu machen, zumal der wirklich benötigte Gegenstand noch im Angebot ist .

Der Nachteil ist, dass es sehr wichtig sein wird, etwas wie DisposablePromise auf vernünftige Weise zu konstruieren ... und ehrlich gesagt weiß ich nicht einmal, ob meine Implementierung funktioniert 😆 (Ich habe aus irgendeinem Grund so große Probleme damit, asynchron zu denken Ha).

Wenn es noch jemanden in diesem Thread gibt, der sich mit diesem Thema befassen möchte <3 u longtimes!

@chaffeqa Wie kompliziert ist die Bluebird-Implementierung? Vielleicht können wir es einfach extrahieren und dem nativen Versprechen hinzufügen?

@chaffeqa Worst-Case-Szenario - wir können alle anderen Bluebird-Nutzungen entfernen und diese aufgrund ihrer Komplexität beibehalten, wenn wir sie für zu riskant halten. Nicht ideal, aber irgendwann wird using passieren.

leider ziemlich kompliziert ... die implementierung huckepack auf die tatsache, dass bluebird den Promise-Lebenszyklus kontrolliert. Ich denke, der beste Ansatz besteht darin, zu sehen, was es zu tun versucht (was dem Link zu using oben ziemlich nahe kommt) und ein möglichst einfaches und leistungsfähiges Shim dafür zu erstellen.

Das Problem ist, dass die Pipeline ein Versprechen im Bluebird -Stil sein muss , das sich, wenn ich es richtig verstehe, nicht an die Leistung des nativen Versprechens hält (und Sie daher die gesamte Tracing- und native Async-Funktionalität verlieren).

Ich würde viel lieber etwas tun, das unter der Haube native Versprechungen für die asynchronen Teile verwendet, aber die Möglichkeit bietet, den Kontext zu binden und die erforderliche Verwendung wie disposer zu implementieren.

FYI Eine andere Sache in meinem Kopf ist: Es gibt tatsächlich eine minimale Verwendung von usage und .disposer in Knex, also funktioniert der Ansatz vielleicht besser, um das auf eine höhere Ebene zu bringen?

Ein Experiment wert :)

oooo auch eine Option , die ich basierend auf https://github.com/petkaantonov/bluebird/issues/1593 gefunden habe

Wie auch immer, ich denke, ein guter Schritt nach vorne war, was Sie in einem früheren Zweig begonnen haben, wo wir die gesamte Verwendung von Promise isolieren, die eigentlich ein BluebirdPromise ist, so dass wir anfangen können, mit dem Löschen herumzuspielen in Ersetzungen wie DisposablePromise oder BluebirdNativePromise .

@chaffeqa Du meinst den Bluebird.setScheduler(fn => Promise.resolve().then(fn)) Teil?
Die Gesamtumstellung verläuft wirklich reibungslos! Wenn wir Disposers in Bluebird behalten könnten, während wir sie dazu bringen, native Versprechen unter der Haube zu verwenden, könnte das tatsächlich eine gute Lösung sein.

OK, diese müssen also noch beachtet werden:
https://github.com/tgriesser/knex/issues/3257
https://github.com/tgriesser/knex/issues/3286
https://github.com/tgriesser/knex/issues/3256

Hilfe wäre sehr willkommen!

Ich wollte nur noch erwähnen, dass die Nichtverwendung nativer Promises zu nodejs/node#22360 führt , wenn async_hooks verwendet wird, wodurch der aktuelle Kontext verloren geht.

Die Problemumgehung besteht darin, den https://github.com/TimBeyer/cls-bluebird-Patch zu verwenden.

Nur zur Information, LTS für Node v8 endet dieses Jahr.

@Bessonov Kontext? Wie wirkt sich das Erhöhen des Mindestknotens auf 10 auf dieses Problem aus? Beachten Sie, dass wir die Unterstützung für Knoten 6 bereits eingestellt haben.

Ich bin mit der Knex-Codebasis nicht vertraut, aber vielleicht gibt es einige Funktionen, die Ihnen helfen können, Bluebird wegzubekommen. Zum Beispiel hat Knoten 10 eine Unterstützung für Promise.finally .

Aber trotzdem freue ich mich über die Fortschritte bei diesem Thema :+1:

Über das Disposer-Muster - könnten wir einfach einen optionalen Rückruf für Dinge hinzufügen, die das Disposer-Versprechen zurückgeben?
(Wie bei Transaktionen)

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
}

Welches Maß an Versprechensbibliotheksunabhängigkeit brauchen wir?
1) alle verwenden native Promises
2) Internals native Promises, der Benutzer kann seine eigene Promise Lib für die Schnittstelle setzen
3) Der Benutzer kann Promise Lib für Interna und Schnittstelle festlegen

Wie ist der aktuelle Stand zu diesem Thema. Im Allgemeinen arbeitet knex jetzt mit async await, aber Typescript gibt eine Warnung aus, dass wir auf eine Methode warten, die kein natives Versprechen ist.

Um also die ursprüngliche Problemfrage zu beantworten. Die aktuelle Problemumgehung besteht darin, einfach abzuwarten und etwas wie // tslint:disable-next-line: await-promise hinzuzufügen

@maximelkin Ich stimme für Option 1. Langfristig hoffe ich, dass jede Versprechungsbibliothek veraltet ist.

Zweitens sind Polyfills an dieser Stelle selbst für die meisten Browser jenseits der Versprechung

@Bessonov hängt derzeit von Knex-Bibliotheken (und möglicherweise Projekten) ab, für die genau Bluebird erforderlich ist

wir sollten ihnen eine Fallback-Lösung geben

@Bessonov derzeit auf Knex-abhängigen Bibliotheken (und möglicherweise Projekten), die genau Bluebird erfordern, sollten wir eine Fallback-Lösung für sie geben

Es spielt keine Rolle, ob die Benutzer von knex auf bluebird angewiesen sind. Knex kann weiterhin native Versprechen verwenden und sie werden problemlos mit Bluebird-Versprechen zusammenarbeiten. Wir sollten absolut keine Fallbacks geben.

Dieses Problem begann also mit der Anforderung einer Funktion mit der Auswahl der Versprechungsimplementierung.
Aus dem Nichts mutierte es dazu, Bluebird ohne Grund zu entfernen und alle Abhängigen zu brechen. Ohne Vorwarnung, Changelog, Option für Fallback und Major Release.

Aber ich nehme an, dass alle 1.5 Typoskript-Benutzer jetzt glücklich sind.

Dieses Problem begann also mit der Anforderung einer Funktion mit der Auswahl der Versprechungsimplementierung.
Aus dem Nichts mutierte es dazu, Bluebird ohne Grund zu entfernen und alle Abhängigen zu brechen. Ohne Vorwarnung, Changelog, Option für Fallback und Major Release.

Zumindest früher mit knex 0.x-Versionen wurden als Hauptversionen mit potenziell bahnbrechenden Änderungen angesehen, sodass nur die Aktualisierung auf 0.20.x als sicheres Upgrade angesehen werden sollte (semver ist wirklich locker, wenn Versionsnummer < 1).

Das Entfernen von Bluebird liegt schon lange auf dem Tisch, es geht nicht nur um dieses Problem.

Bluebird ohne Grund entfernen

Das Entfernen von Bluebird war nicht ohne Grund. Sie können Bluebird mit Knex Promises weiterhin extern verwenden. Ein wichtiger Grund, Bluebird fallen zu lassen, war, dass async -Funktionen implizit native Versprechungen erstellen, sodass in Zukunft die Verwendung von Bluebird erforderlich gewesen wäre, um ohne Grund zusätzlichen Bluebird-Wrapping-Code in die Knex-API hinzuzufügen.

Ohne Vorwarnung, Änderungsprotokoll,

Einverstanden. Ich habe die neuesten Änderungsprotokolle durchgesehen ... Leider sieht es so aus, als hätten wir es versäumt, wichtige Änderungen zwischen den Versionen aufzulisten. Wir müssen beim Schreiben von Änderungsprotokollen vorsichtiger sein, um wirklich auf die Änderungen hinzuweisen, die die alten APIs beschädigen. Zum Beispiel werden viele der Typisierungsänderungen tatsächlich den alten TS-Code brechen.

Es gab das gleiche Problem beim Ioredis-Projekt https://github.com/luin/ioredis/commit/da60b8b. Sie wollten native Promises unterstützen – und die Jungs haben eine wirklich gute Lösung entwickelt – sie haben eine Option hinzugefügt, um jede benutzerdefinierte Promise-Bibliothek zu unterstützen, und sie verwenden standardmäßig native Promises. Warum nicht? Das Einrichten einer benutzerdefinierten Zusagebibliothek ist schnell und erfordert nicht das Patchen des gesamten Anwendungscodes.

Die weitere Verwendung von Bluebird hätte das Hinzufügen von zusätzlichem Bluebird-Wrapping-Code in der Knex-API ohne Grund erforderlich gemacht.

Jawohl. Aber warum nicht Modulaufrufe in Bluebird (oder eine andere Promise-Bibliothek) einschließen, wenn dies explizit angegeben wurde? Das ist ein einfacher Wrapper, null Overhead, und er würde es Benutzern ermöglichen, jede gewünschte Promise-Bibliothek zu verwenden. Wenn niemand bluebird braucht, würde niemand diese Optionen verwenden, und Sie können es sicher rechtzeitig verwerfen.

Auch sah ich eine Meinung dazu

Langfristig hoffe ich, dass jede Promise-Bibliothek obsolet wird.

Aber IMHO gibt es zwei falsche Annahmen:

• Bluebird wird verwendet, weil es schneller ist.
• Bluebird wird als Pollyfill verwendet.

Ich denke, das ist bei wirklich komplexen Anwendungen nicht der Fall, die über asynchrone Einzeiler hinausgehen.
Bluebird verfügt über viele Funktionen, die für einen komplexen asynchronen Fluss unbedingt erforderlich sind – wie Zeitüberschreitungen, benutzerdefinierte Fehlerbehandlung, Zuordnung mit Parallelität, Abbruch, Reduzierung und so weiter. Alle diese Funktionen können in nativen Versprechen implementiert werden, aber das ist eine Menge nutzloser Boilerplate. Im Jahr 2020 verwenden wir immer noch Bluebird in Node 12, weil wir diese ganzen Boilerplates nicht wollen.

Warum nicht? Das Einrichten einer benutzerdefinierten Zusagebibliothek ist schnell und erfordert nicht das Patchen des gesamten Anwendungscodes.

Alles, was async-await intern verwendet, wird Versprechen zu nativen Versprechungen erzwingen, sodass Sie entweder die Ausgabe jeder Methode in das benutzerdefinierte Versprechen einschließen oder async-await im internen Code verbieten können. Es ist kein so kleines Unterfangen, wie es auf den ersten Blick erscheinen mag.

@qubyte

Es ist kein so kleines Unterfangen, wie es auf den ersten Blick erscheinen mag.

Nein, das ist genauso einfach wie ich schon sagte. Sie erstellen einen Wrapper für exportierte externe Funktionen und das ist alles. Etwa 10 Zeilen Code. Und schreiben Sie den gesamten internen Code so, wie Sie es möchten.

@jehy : Fühlen Sie sich frei, eine PR für diese 10 Codezeilen einzureichen, wenn Sie einen einfachen Weg sehen, sie zu implementieren.

Ich werde auch einige Zeit damit verbringen, heute zu versuchen, mit einer Problemumgehung aufzutauchen.

Für das, was es wert ist, wird ein Großteil der API von Bluebird mit der gleichen oder ähnlichen API dupliziert, wobei native Versprechen von diesen Paketen verwendet werden: https://github.com/sindresorhus/promise-fun

Für das, was es wert ist, wird ein Großteil der API von Bluebird mit der gleichen oder ähnlichen API dupliziert, wobei native Versprechungen dieser Pakete verwendet werden

~50 Pakete statt 1? Ernsthaft?

Ja, obwohl meistens nur wenige erforderlich sind (z. B. p-map). Ihr Kilometerstand kann natürlich variieren. Es wird nur als ein möglicher Weg zu dem angeboten, was Sie wollen.

@jehy : Hier ist etwas, das Sie als vorübergehende Problemumgehung in Ihrem Anwendungscode ausprobieren können:

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();

Dies ist nicht wirklich eine angemessene Lösung für das Gesamtproblem. Es gibt andere temporäre Objekte, die innerhalb knex erstellt wurden und auf ähnliche Weise dekoriert werden müssten.

Außerdem Haftungsausschluss: Die Problemumgehung ☝️ wurde nur sehr wenig getestet. Daher sollten Sie die Tests Ihrer Anwendung erneut ausführen, um sicherzustellen, dass nichts kaputt gegangen ist.

Ich wollte hier nur meine 2 Cent hinzufügen: Ich schätze die ganze Arbeit, die in diese Migration gesteckt wurde, ungeachtet des negativen Feedbacks.

Aus Sicht unserer App war knex die letzte Bibliothek, die uns dazu zwang, Bluebird anzufordern, und die Konformität mit der vollständigen nativen Versprechungsunterstützung bedeutet Folgendes:

1. wir haben keine verschmutzten Stacktraces mehr
2. Wir haben unser SSR-Gewicht um einen anständigen Betrag reduziert
3. Wir haben die Leistung verbessert, da das native asynchrone Warten jetzt leistungsfähiger ist als Bluebird (und immer mehr wächst!)

Es ist so ein großer Gewinn, weiterhin auf den es-Standard hinzuarbeiten ... und ich weiß, dass es für Bibliotheksverwalter nicht einfach ist, also wollte ich euch zurufen und euch dafür danken, dass ihr eine solche Last auf euch genommen habt!

Für diejenigen, die unter der Änderung leiden: Ich würde gerne helfen, da wir davon profitiert haben. Wenden Sie sich also bitte an uns, wenn Sie Hilfe beim Debuggen oder Migrieren benötigen!

@chaffeqa Vielen Dank für dieses Feedback, es bedeutet mir viel!

@jehy : Hatten Sie die Möglichkeit, das vorgeschlagene Problem zu umgehen? Wenn ja, hat es Ihre unmittelbaren Probleme gelöst?