wie man Flussanmerkungen, Typen und Schnittstellen von einem npm-publizierten Modul importiert

9

Ich habe durch Tests verifiziert, dass zwei Muster zum Importieren von Flussanmerkungen, Typen und Schnittstellen von einem npm-publizierten Modul möglich sind.

Im Folgenden verwende ich die folgenden Modulnamen:

  • Modul A: definiert die Anmerkungen, Typen und Schnittstellen
  • Modul B: verlässt sich auf Modul A und möchte eine Typ-Überprüfung dagegen durchführen und seine Anmerkungen, Typen und Schnittstellen verwenden.

Muster 1

Modul A

  • Verwenden Sie die export type -Syntax für beide Typen und Schnittstellen:

    %Vor%
  • Kopiere alle *.js Dateien als *.js.flow . Z.B. indem Sie in package.json Folgendes sehen:

    %Vor%
  • Veröffentlichen Sie das Modul

Modul B

  • deklariert einfach die Abhängigkeit mit npm i --S module-A macht die Anmerkungen auch verfügbar wegen der Dateien js.flow im Verzeichnis lib/ des veröffentlichten Moduls.
  • Importieren Sie beide Typen und Schnittstellen mit der folgenden Syntax:

    %Vor%

Muster 2

Modul A

  • Definieren Sie Typen, Interfaces und Module in einer declarations.js -Datei, die im Verzeichnis decl liegt (auf den Sie im Abschnitt [libs] von .flowconfig zeigen):

    %Vor%
  • Sie müssen *.js -Dateien nicht als *.js.flow in das prepublish -Skript

  • kopieren
  • Veröffentlichen Sie das Modul

Modul B

  • deklariere die Abhängigkeit wie zuvor mit npm i --S module-A . Dieses Mal sind jedoch keine Anmerkungen, Typen und Schnittstellen verfügbar, da "Modul-A" keine *.js.flow -Dateien enthält, also ...
  • Erhalte manuell die declarations.js -Datei aus dem "module-A" -Paket und lege sie in das decl -Verzeichnis (gezeigt vom [libs] -Abschnitt von .flowconfig
  • Sie müssen keine Syntax verwenden, um Typen und Schnittstellen zu importieren; Sie werden automatisch verfügbar.

Die obigen zwei Muster sind die einzigen Methoden, die ich entdeckt habe, und haben nachgewiesen, dass sie funktionieren (obwohl ich keine umfassende Beschreibung finden konnte).

Meine Fragen sind:

  1. Welches Muster ist idiomatischer / ratsam?
  2. Gibt es ein anderes Muster?

Zu Frage # 1 kann ich sehen, dass "Muster 2" die einzig mögliche Methode ist, wenn "Modul-A" von einer anderen Organisation / Person veröffentlicht wird. Ansonsten, wenn man beide Module veröffentlicht, denke ich, "Muster 1" ist einfacher.

    
Marcus Junius Brutus 08.09.2016, 08:17
quelle

1 Antwort

9

Sie haben absolut Recht mit Ihren Beobachtungen. Dies sind die beiden Methoden zum Veröffentlichen Ihrer Flowtyp-Definitionen. Es gibt keinen anderen Weg, oder besser: Die offiziellen Migrationspläne gehen irgendwie in beide Richtungen, weil es momentan nicht möglich ist, alle JS-Projekte zu zwingen, den Fluss anzupassen.

Momentan beschreibt "pattern 2", was wir "libdef" -Dateien oder "Deklarationsdateien" nennen. Mit dem Projekt flow-typed versuchen wir, qualitativ hochwertige libdef-Dateien für gängige Knotenmodule von Drittanbietern bereitzustellen.

Beide Muster haben ihre Up- und Downside ... Das größte Problem bei der Weitergabe von *.flow.js -Dateien ist, dass sie eine bestimmte Version von flow annehmen (z. B. peerDependency flow-bin kann Ihre neueste verwendete Syntax nicht verstehen). Auf der anderen Seite ist es eine schlankere Art, die Typen mit der tatsächlichen Codebasis synchronisiert zu halten.

Wie auch immer, beide Wege sind gültig, stellen Sie nur sicher, dass Ihre Kunden nicht gezwungen sind, ihre flow Version nur für Ihr Paket zu ändern.

Einige weitere nützliche Informationen:

[email protected] führt ein experimentelles neues Feature namens flow gen-flow-files ein, mit dem Sie *.flow.js auf effizientere Weise erstellen können, indem Sie nur die Typinformationen anstelle des gesamten Codes kopieren.

Außerdem habe ich ein Problem mit dem Flow-Typ erstellt, das genau die gleiche Diskussion hier startet: Ссылка

Prost

    
ryyppy 12.09.2016, 15:54
quelle

Tags und Links