Oh, habe gerade https://github.com/feathersjs/feathers/issues/64 gesehen... Aber vielleicht das offen lassen? Also werden einige Leute Hilfe anbieten?

Der beste Weg, dies voranzutreiben, wäre, ein Repository mit einigen grundlegenden Typescript-Definitionen zu starten (in #64 habe ich einige Hinweise darauf gepostet, wo man anfangen soll) und fortzufahren
Diskussion dort.

Ich kann diese Ausgabe noch ein oder zwei Monate offen lassen, aber die andere Ausgabe war fast ein Jahr lang offen, und niemand hat sie aufgegriffen. Wie dort erwähnt, verwendet das aktuelle Kernteam weder Typescript noch Angular, daher ist es nicht wirklich auf unserem Radar (und wir ziehen es vor, Probleme nur offen zu halten, wenn die Möglichkeit besteht, dass sie in absehbarer Zeit behoben werden).

Ich denke, @harangue hat an einigen grundlegenden Definitionen gearbeitet. Vielleicht können wir die Diskussion, die wir auf Slack darüber hatten, wo sie hier leben würden, verschieben?

sicher! Wenn Sie dieses Problem schließen müssen, fahren Sie einfach fort.

Es wäre wirklich schön, wenn Typoskript unterstützt werden kann. Wie kann ich helfen?

@rollymaduk Ich habe bei den Definitionen für Feathers einige anständige Fortschritte gemacht, aber wir müssen noch den besten Weg finden, sie zu verteilen (und die Dinge sind ein wenig vorübergehend, da TypeScript 2 kurz vor der Veröffentlichung steht). Wenn Sie bis dahin noch etwas zu bearbeiten haben möchten , können

@harangue wirklich schöne Arbeit, in der Tat sieht es ziemlich fertig aus.. Ich denke, einige Bereiche, die möglicherweise etwas Aufmerksamkeit erfordern, würden einige grundlegende Plugins wie Authentifizierung, Anbieter (rest,socke.io,primus) und einige der DB-Adapter integrieren, oder? bitte was meinst du mit wie man sie am besten verteilt?

Ich bin mir nicht sicher, ob wir das schon besprochen haben, aber ich denke, es ist in Ordnung, wenn wir die Typescript-Definitionen im Haupt-Repository verteilen, solange es jemanden gibt, der sie pflegt und auf dem neuesten Stand hält. Sobald sie fertig sind, können wir sie also in eine Feathers 2.1-Version aufnehmen (die meiner Meinung nach auch mit einigen Warnungen ausgeliefert werden könnte, dass zB Callbacks in Diensten in v3 veraltet sind).

Gibt es eine Abzweigung von generator-feathers für TypeScript? Haben Sie Interesse an einer TS-Gabel des Generators zu arbeiten?

Bearbeiten: Ich habe den Generator gegabelt und einen ersten Commit gedrückt.

@harangue hat also einen großen Satz der Feathers Typescript-Definitionen bereits in https://gist.github.com/harangue/9d4ed79118e2656f5e3d2d699296ed36 implementiert.

Ich werde diesen Teil der Auk-Veröffentlichung machen, die vor Ende des Jahres erscheinen wird. Wenn sich bis dahin niemand einmischt, wird dieses Thema endgültig geschlossen und es wird keine offizielle TypeScript-Unterstützung oder weitere Diskussion darüber geben, außer einem Pull-Request für das Ganze.

Bei guter Qualität sollten Sie die Definitionen mit Federn bündeln. Ich denke, viele Leute würden die Verwendung eines sekundären Paketmanagers so weit wie möglich vermeiden wollen.

Sie wären über npm i @types/feathers installierbar. Du brauchst keine Sachen wie typings mehr.

Ich dachte, Sie fügen sie einfach zu https://github.com/DefinitelyTyped/DefinitelyTyped hinzu. Wie auch immer dies der normale Weg ist. Wenn wir sie zum Core-Repository hinzufügen, müssen wahrscheinlich die anderen Plugin-Repositorys entsprechend hinzugefügt werden.

Aus der DefinitelyTyped-FAQ:

Der Typen-2.0-Zweig wird dank Typen-Publisher automatisch im @types- Bereich auf NPM veröffentlicht. Dies geschieht normalerweise innerhalb einer Stunde nach dem Zusammenführen der Änderungen.

Wusste das nicht. Es würde also ausreichen, sie zu DefinitelyTyped hinzuzufügen.

Ach, JS. Du bist ein oder zwei Monate weg und das Ökosystem entwickelt sich weiter :smile:

Tut mir leid, dass es bei mir so lange Funkstille gegeben hat. Ich habe heute gerade eine weitere Überarbeitung des Kerns

Die Definition, wie sie im Wesentlichen vorhanden ist, kann an Definitely Typed gesendet werden, mit Ausnahme von 1) Typisierungstests (man muss nur einige Beispiele aus den Feathers-Dokumenten ziehen) und 2) JS-Doc-Anmerkungen (was für Intellisense schön wäre, aber sind nicht essenziell).

Technisch sollten die Hakentypisierungen auch zu Federhaken extrahiert werden. Das Erweitern von Typisierungen hier wird jedoch ein wenig chaotisch, da uberproto einige Mischmuster aufweist, die mit statischen Typen etwas schwierig zu replizieren sind.

Schön, dass du wieder da bist @harangue. Ich denke, wir können die Hook-Typisierungen hier belassen, da wir planen, Hooks zu einem Teil des Kerns zu machen (siehe #408). Außerdem müssen die Eingaben möglicherweise mit der neuen Methode .hooks aktualisiert werden, wie in https://blog.feathersjs.com/feathers-application-and-error-hooks-7a5982e70024 beschrieben (noch nicht dokumentiert, in Arbeit :).

@harangue, wann denkst du, dass du deine Typen an definitiv typisiert

Hallo zusammen, wirklich cool zu sehen, dass TypeScript-Defs auftauchen. @harangue , was ist Ihre Empfehlung für den Import von Federn in Verbindung mit den Defs in Ihrem Kern? Sie exportieren keine Namespaces, die den feathers Bibliotheken entsprechen, daher gibt import ... from 'feathers' einen Fehler aus.

Hey @subvertallchris , du kannst verwenden

import * as feathers from 'feathers';`

oder

import feathers = require('feathers');

sie sind gleichwertig. :) Gerade als ich dachte, ich hätte mal wieder Zeit für Feathers, war ich in andere Dinge verwickelt, aber ich hoffe, dass diese Definitionen bis zum neuen Jahr vollständig konkretisiert werden.

@j2L4e Ihre TS-Generatorgabel scheint 404'ing zu sein? Gibt es Neuigkeiten zu diesem Thema? Außerdem @harangue, wie geht es dir? Ich bin wirklich sehr daran interessiert, dieses Land zu sehen, und helfe gerne bei der Implementierung von TS-Definitionsdateien, einem Fork mit einem feathers generate --ts Flag, damit die CLI gut mit Typoskript oder Docs spielen kann. Gib mir Bescheid.

Es war schwer zu warten, funktionierte nur für MySQL und lokale Authentifizierung und Generator-Federn werden sowieso bald veraltet sein. Also habe ich es verschrottet.

Warte sehnsüchtig auf die Veröffentlichung des neuen cli

Am 19. Dezember 2016 14:41:42 MEZ, schrieb georgeedwards [email protected] :

@j2L4e Ihre TS-Generatorgabel scheint 404'ing zu sein? Gibt es Neuigkeiten zu diesem Thema?
Außerdem @harangue, wie geht es dir? Ich freue mich sehr, das zu sehen
landen und helfe gerne bei der Implementierung von TS-Definitionsdateien, a
Fork mit einem feathers generate --ts Flag, damit die Cli spielen kann
Typoskript schön oder docs. Gib mir Bescheid.

--
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an:
https://github.com/feathersjs/feathers/issues/381#issuecomment -267966376

Arbeitet noch jemand an diesem Thema? Ich würde dieses Projekt sehr gerne mit Typescript verwenden

Hallo an alle

Ich freue mich sagen zu können: _Es ist fast fertig._ 😄
Ich habe viele Forks in FeatherjsOrg erstellt und schreibe Definitionen per Repo. Und Sie können diese Beispiele mit den besten Typoskript-Definitionen sehen

Federn+Nodejs+Typescript
FedernClient+Aurelia+Typescript

[ja, es unterstützt ESNext, Commonjs, AMD und globale Module für Client-Chunks]

Das aurelia-Beispiel gibt Ihnen Hinweise zur Arbeit mit angle2. Diese Repositories enthalten viele Details, wie Typoskript nützlich sein kann, um eine Live-Dokumentation zu erstellen

Ich werde bald PRs machen, aber Sie können sehen, Fragen stellen und mir Feedback geben. ?

Gabel mit Definitionen:

• Federhaken
• Federn-Primus
• Federsocketio
• Federn-Ruhe
• Federn-Authentifizierung-Client
• Federn-Kunde
• Gefieder

Ich hatte ein bisschen Arbeit, aber ich liebe Federn und Typoskript

das sind alles relative links

Ich habe die Links korrigiert.

@AbraaoAlves Das sieht toll aus, danke! Ich wollte gerade einen mürrischen Kommentar schreiben und das Thema schließen und freue mich, dass Sie zuerst kommentiert haben 😉 Ich freue mich auf die Pull-Requests!

Guter Mann @AbraaoAlves !

@AbraaoAlves Ich wollte mich nur so sehr

@AbraaoAlves Ich habe Probleme, eine Ihrer Definitionen tatsächlich zu verwenden. Wenn ich die Pakete in der package.json installiere, wie z

"feathers-errors": "^2.5.0",

"feathers-authentication": "^0.7.12",

"feathers-configuration": "^0.3.3",

"feathers": "https://[email protected]/AbraaoAlves/feathers.git#definition",

"feathers-hooks": "git://github.com/AbraaoAlves/feathers-hooks.git#definition",

"feathers-mongoose": "^3.6.2",

"feathers-rest": "git://github.com/AbraaoAlves/feathers-rest.git#definition",

"feathers-socketio": "git://github.com/AbraaoAlves/feathers-socketio.git#definition"`

Wenn ich also versuche, es in einer TypeScript-Datei zu verwenden, wie:

import * as feathers from "feathers"

es besteht die Kompilierung, läuft aber nicht richtig.

Sie installieren nur die Typdefinitionen und nicht die Quelle. Es scheint auch, dass Federn-Rest keine Funktion für die Typoskripterkennung exportiert
rest()' as a valid command for app.use(rest());

Ein weiteres Problem ist, dass app.use anscheinend keine Argumente mehr akzeptiert, wie z
this.app.use(bodyParser.json());

und muss verwendet werden als

this.app.use(bodyParser.json() as any);

@Chrisdf Ich

Mehr Details dazu: Problem

@AbraaoAlves gibt es einen Grund, warum Sie die Definitionen nicht auf DefinitelyTyped setzen? Auf diese Weise wären sie über den @types- Namespace von NPM verfügbar, und das

@AbraaoAlves Warum wurden die Definitionen übrigens nicht festgeschrieben, sondern als Tarball-Release veröffentlicht? Sie wären typings diese Weise für

Ich habe die Typisierungen basierend auf der Arbeit von @AbraaoAlves und @harangue neu geschrieben. Ich werde diese Eingaben in Kürze an DefinitelyTyped senden.

Cool. Was können/sollten wir dafür tun? Ansonsten gehe ich davon aus, dass wir dieses Problem schließen können, sobald die Dinge in DefinitelyTyped aufgenommen wurden?

sollte in diesem Repository und der package.json enthalten sein
(zumindest wäre das der beste Fall)

Beispiel: package.json enthaltene Datei

Hallo zusammen o/
Danke für Geduld und Rückmeldungen.

@stevehipwell und @daffl : Ich glaube, Typoskript-Definitionsdateien sind wie eine Dokumentation, eine Live-Dokumentation. Aber eine Dokumentation, die nicht am Code ausgerichtet ist, ist schlimmer als keine Dokumentation!

Ich kenne die Initiative @types und DefinitlyTyped, und das ist wichtig für die Typoskript-Community, dass sich Javascript-Leute nicht um Definitionen kümmern.

Wenn wir heute die Möglichkeit haben, beides an einem einzigen Ort unter einer einzigen Veröffentlichung zu verwalten, werden Kommunikationsfehler viel seltener auftreten und wir werden offizielle Definitionen nach Veröffentlichung haben!

Beispiele für Javascript-Projekte pflegen Ihre eigenen Definitionen: Aurelia , Preact , ...

Wenn alle zustimmen, hier die PullRequest-Links:

• Gefieder
• Federn-Authentifizierung-Client
• Federhaken
• Federn-Primus
• Federn-Ruhe
• Federsocketio
• Feder-Authentifizierung
• Federn-Client (Ich werde senden, nachdem diese anderen gelöst sind)

Es gibt noch viel mehr Arbeit, wie getippte Tests, Automatisierung, ... aber das fängt erst an.

Typoskript S2 FeathersJS!

Hallo zusammen,

Ich stimme @AbraaoAlves zu, dass die ideale Lösung darin besteht, die TypeScript-Definitionsdateien direkt in die Pakete

Um sicherzustellen, dass die Definitionen mit den Projektversionen synchron bleiben, müsste das Federn-Team mehr Transparenz geben. Während ich meine eigenen Definitionen schreibe, bin ich mir bisher nicht sicher, wie der aktuelle Stand der Veröffentlichung ist; der blog wird nicht aktuell gehalten und es gibt etliche codenamen (v3, auk, bussard??), die nichts sagen.

@AbraaoAlves - Ihre Definitionen sehen gut aus, aber hooks() Methoden. Wären Sie daran interessiert, diese hinzuzufügen?

Hallo @stevehipwell ,

Danke für die Rückmeldung. Und hier meine Antworten zu:

Im schlimmsten Fall sind jedoch Definitionsdateien enthalten, die am Ende veraltet sind ...
Um sicherzustellen, dass die Definitionen mit den Projektversionen synchron bleiben, müsste das Federn-Team mehr Transparenz geben

Ja, das Synchronisierungsproblem ist ein echtes Problem, kann aber durch Tests behoben werden.
Ich schlage vor, Tests in Maschinenschrift zu machen: #508

Wenn Sie mit dieser Lösung einverstanden sind oder nicht, nehmen Sie Ihre Meinung dort auf.

Ich bin wirklich sehr motiviert, feathersjs typoskriptfreundlich zu machen, natürlich ohne störende Änderungen.
Wir haben noch viel mehr zu tun, wie zum Beispiel hooks() Methoden, aber jetzt können wir dies gemeinsam erstellen.

Wenn Sie einen Fehler sehen oder eine Definition verpassen, machen Sie ein Problem.

@AbraaoAlves es hört sich so an, als ob der Wunsch besteht, die Definitionen auf dem neuesten Stand zu halten, und ich helfe gerne weiter. Ich gehe davon aus, dass Sie Fehler in den Haupt-Repositorys für fehlende Definitionen beheben möchten, sobald Ihre Zusammenführungsanforderungen abgeschlossen sind?

@stevehipwell Ja, darauf kommt es an.

Was ist das Problem mit dem Veröffentlichungsplan und was können wir tun, um ihn zu verbessern? Die Meilensteine hier

• Die nächste Version ist Auk , ein Code, der vollständig ist, wobei der Generator fertiggestellt und die Dokumente aktualisiert werden. Die Breaking Changes sind in der Feder-Authentifizierung v1.0.0
• Die Veröffentlichung danach ist Buzzard, die die folgenden grundlegenden Änderungen beinhalten wird (die ich tatsächlich manchmal als v3 bezeichne - und wahrscheinlich nicht sollte 😉):
  
  
  
  • Framework-Unabhängigkeit (https://github.com/feathersjs/feathers/milestone/9) (und damit eine einheitliche Struktur für den Kunden )
  
  
  • Hooks im Kern (https://github.com/feathersjs/feathers/issues/408)
  
  
  • Kanalbasierte Ereignisfilterung (https://github.com/feathersjs/feathers/issues/388#issuecomment-239564856)
  
  

Wie sollte der Prozess sein, um die Definitionen zu aktualisieren, nachdem diese Funktionen gelandet sind?

Typoskriptdefinitionen sind wie .h (Header) in C++. Wenn Sie einen Header haben, der nicht auf Ihr Modul reagiert, können zur Laufzeit Probleme auftreten, z. B. eine Dokumentation, die nicht mit der Version des verwendeten Codes übereinstimmt.

Daher glaube ich, dass Definitionen in jedem Meilenstein enthalten sein sollten, der eine Änderung in der API erfordert, z. B.: Methode in ein anderes Repository verschieben oder einen neuen Parameter zu einer Methode hinzufügen, …

Ich werde die Definition der Federn-Authentifizierung ändern und Hooks für bestimmte Projekte entfernen, um sie an v1 auszurichten.
Die Frage ist nun: Sollen Definitionen in diese aktuelle Version von FeathersJS aufgenommen werden?

@AbraaoAlves Ich denke schon. Ich kann eine Nebenversion für alle Ihre PRs erstellen und wir können von dort aus iterieren. Das einzige, worüber ich mich noch wundere, ist #508, aber ich werde es kommentieren.

Ich habe zwei Probleme mit den obigen Eingaben.

socketio will nicht funktionieren.

node_modules/feathers-socketio/index"' resolves to a non-module entity and cannot be imported using this construct.

Und der Rest erfordert einen Handler, obwohl Ihre Federn-Cli ohne Argumente ausgibt.

.configure(rest()) // Fehler hier Funktion deklarieren rest(handler:Function): Function;
.configure(socketio())

Knoten -v
v6.6.0

npm -v
3.10.5

tsc -v
2.1.6

Es wäre auch interessant zu zeigen, wie man "feathers()" als Modul verwendet, da dies der Einstiegspunkt ist.
Ich kann alle anderen generierten Dienste/Middleware konvertieren, aber es muss einen schöneren Weg geben, als Federn () in einem Konstruktor () {} zu kapseln. (Ich bin neu in Sachen Federn, vielleicht mache ich es auch falsch...)

Können wir die Definitionen als Patch-Release herausgeben? Dieser Änderungsgrad würde perfekt zu einer Patch-Version passen; keine Breaking Changes und keine neue Funktionalität. Auch unvollständige oder falsche Eingaben sind besser als keine Eingaben.

Sobald wir eine Veröffentlichung haben, haben wir einen funktionierenden Ausgangspunkt, den wir verwenden können, um die Typisierungen zu verbessern.

Wenn dies weiterhin stagniert, muss ich für meine Definitionen den Weg DefinitelyTyped beschreiten. Das möchte ich nicht und helfe gerne bei Definitionen in den Repos.

Ich hatte eine Frage an @AbraaoAlves in #508, habe aber noch keine Antwort erhalten. Wenn wir die Releases veröffentlichen, brauchen wir jemanden, der schnell alle auftretenden Probleme beheben kann (insbesondere, da im schlimmsten Fall vorhandene Apps, die TypeScript verwenden, beschädigt werden könnten). Können wir uns auf Slack für eine gute Zeit koordinieren, um die Veröffentlichung zu erstellen und zu überprüfen (wir können mit einem minor.pre beginnen)?

Veröffentlicht in Nebenversionen für jedes Modul über

• https://github.com/feathersjs/feathers/pull/507
• https://github.com/feathersjs/feathers-authentication-client/pull/25
• https://github.com/feathersjs/feathers-hooks/pull/135
• https://github.com/feathersjs/feathers-primus/pull/43
• https://github.com/feathersjs/feathers-rest/pull/101
• https://github.com/feathersjs/feathers-socketio/pull/60
• https://github.com/feathersjs/feathers-authentication/pull/412

Zunächst einmal vielen Dank an alle, die an dieser Diskussion teilgenommen haben und insbesondere an diejenigen, die dazu beigetragen haben. Wir haben kleinere Versionen mit den TypeScript-Definitionen für viele Feathers-Repositorys veröffentlicht, aber es hat eine Reihe von Problemen verursacht – und ungeplante Veröffentlichungen für ansonsten ziemlich stabile Module, die Benutzer dazu bringen, zu aktualisieren, die sogar TypeScript überhaupt nicht verwenden – ohne Möglichkeit für den Kern team (wo niemand TypeScript verwendet), um sie zuverlässig zu beheben.

Meine wichtigste Erkenntnis aus der ganzen Feathers + TypeScript-Diskussion ist, dass es sehr schwierig zu sein scheint, Typisierungen für ein bestehendes JavaScript-Projekt zu erstellen und zu pflegen (für mich sprach das nicht sehr gut für die Interoperabilitätsansprüche von TypeScript). Da das Kernteam TypeScript nicht verwendet, besteht unsere einzige Möglichkeit bei der Veröffentlichung bahnbrechender API-Änderungen darin, veraltete TypeScript-Definitionen zu entfernen.

Es wäre großartig, aktuelle TypeScript-Definitionen für die Feathers-Module im DefinitelyTyped- Repository zu haben, und wir werden alles tun, um dies zu ermöglichen, aber mit der begrenzten Zeit, die wir zur Verfügung haben, können wir den Overhead von . nicht hinzufügen Unterstützung und Wartung von etwas, das wir nicht persönlich in unseren eigenen Repositories verwenden.

Für mich sprach das nicht sehr gut für die Interoperabilitätsansprüche von TypeScript

Feathers ist ohne spezielle Eingaben perfekt verwendbar, es ist einfach nur JS, dann ohne Intellisense und Typen. Besonders das Plugin-System von Federn mit seiner starken Verwendung von Mixins macht das Erstellen von Typisierungen schwierig, da dies eine sehr nicht typografische Art ist, Dinge zu tun. Ich bin ein regelmäßiger Typoskript-Benutzer (und ein Fan davon), bin aber vorerst zu ES6 zurückgekehrt, um serverseitige Federn zu machen.
Die separate Pflege von Typen scheint hier der besser geeignete Weg zu sein, da niemand im Kernteam tatsächlich Typoskript verwendet.

Feathers wäre das bevorzugte serverseitige Framework für Angular, wenn es gut mit TypeScript zusammenspielen würde. Ich sag bloß' :-). Ich ziehe vorerst weiter.

@j2L4e Ich denke, das wird für die nächste Version einfacher, wenn die meisten Dinge, die jetzt von Plugins gemischt werden, Teil des Kerns sind. Ich bin mir jedoch nicht sicher, ob es das allgemeine Problem lösen wird, zuverlässig Hilfe zu bekommen.

@rjsteinert Was im Moment da ist, sollte meistens funktionieren, aber ja, wie bei jedem Open-Source-Projekt haben Sie die Möglichkeit, entweder auszuprobieren und zu helfen oder weiterzumachen.

Sie haben die Möglichkeit, entweder auszuprobieren und zu helfen oder weiterzumachen.

Ich bin einer dieser Leute, die neu bei Angular sind, langjähriger JS-Programmierer, der realisiert, wie sehr TS das Leben großartig macht und dass das Team, wenn wir es auf der Serverseite nicht mitmachen, darüber verflucht und davon träumt, es neu zu schreiben es jeden Tag für die nächsten paar Jahre. Wir können doch mangels Möglichkeiten auf Federn setzen und dann auf jeden Fall dabei helfen, Typings aktuell zu halten. Wir sagen nur, dass, wenn wir vorbeikommen und sehen, dass "unsere einzige Wahl bei der Veröffentlichung von bahnbrechenden API-Änderungen darin besteht, veraltete TypeScript-Definitionen zu entfernen", wir uns woanders umsehen. Nehmt es nicht als eine Demütigung, ich verstehe die Notwendigkeit, bestehende Projekte zu unterstützen, ihr habt nicht das Glück (ich könnte zum Scheitern verurteilt sein), in meiner Situation zu sein, in der wir eine Neufassung machen.

@rjsteinert Was bietet TypeScript, das es für Sie so wertvoll macht? (ehrliche Frage) Nachdem meine aktuellen Arbeiten an Feathers abgeschlossen sind, ist meine Neugier fast genug geweckt, um selbst einen Blick auf TypeScript zu werfen. Ich weiß, dass es bei Autocomplete/CodeSense hilft, aber die Feathers-API ist so klein, dass ich mir nicht vorstellen kann, dass sie SO nützlich ist. Bitte entschuldigen Sie meine Unwissenheit. ;)

autocomplete/CodeSense ist ein nettes Nebenprodukt, aber ich bin normalerweise in Vim, also bekomme ich die Leckereien nicht. Die große Veränderung, die ich bisher sehe, ist die Standardisierung, wie Sie die Verwendung einiger beigesteuerter Funktionen oder Objekte offensichtlich machen. Beim Durchsehen von Bibliotheken in NPM finde ich viele Bibliotheken, die ihre eigenen hausgemachten und kreativen Lösungen verwenden, um offensichtlich und nutzbar zu machen, was eine dynamisch typisierte Sprache Ihnen nicht sagt. TS spart eine Menge Boiler-Plate-Typen, die Dinge selbst überprüfen, wenn Sie Code schreiben, und macht es einfacher, schnell zu verstehen, wie man den Code anderer Leute verwendet. Heutzutage neige ich dazu, zu denken, dass ich es satt habe, Boiler Plate JS zu schreiben, das ist mein eigener Stil, und ich möchte wirklich nicht jedes Mal, wenn ich eine externe Bibliothek verwende, die README von jemandem lesen.

Ich stimme @rjsteinert zu , ich arbeite seit über 15 Jahren mit JavaScript und bin ein großer Fan davon, sich an alle APIs zu erinnern. Ich habe sogar mit Notepad ohne Farbe codiert. Ich habe früher in einem Team bei Microsoft gearbeitet, wo die gesamte Site nur mit JavaScript geschrieben wurde. Ich kann Ihnen sagen, sobald Ihre Site mehr als 50 Programmierer erreicht, wird alles durcheinander. Sie müssen nicht nur mehr Konventionen befolgen, Ihre Site stürzt auch nur zur Laufzeit ab.

Wenn Sie an diesem GitHub-Post schreiben und FeatherJS verwenden, sind Sie wahrscheinlich ein begeisterter JavaScript-Entwickler. Wenn Sie einer der FeatherJS-Entwickler sind, werden Sie keinen Sinn darin sehen, TypeScript für sich selbst zu verwenden. Sie benötigen keine speziellen Tools oder TypeScript-Hilfe. Du bist ein JavaScript-Einhorn.
Ich war extrem gegen TypeScript (insbesondere, dass wir mit der Version Alpha 1.1 gezwungen waren, es zu verwenden), aber im Laufe der Jahre habe ich es zu schätzen gelernt und kann ohne es nicht leben. Die Kollegen, mit denen Sie zusammenarbeiten werden, sind in JavaScript nicht so versiert wie Sie. Sie kommen aus den unterschiedlichsten Bereichen und werden verfluchen, dass JavaScript ein Miststück ist.

Seitdem ist die TypeScript-Sprache durch das Feedback der Community so stark gewachsen.
Sie können keine riesige Website ohne Tools und ein großes Team erstellen. Wie @rjsteinert sagt, wird das Team anfangen, TypeScript für die Client-Seite zu verwenden, dann wird es nach einer Weile extrem unglücklich sein, die Server-Seite zu verwenden. Es werden Anstrengungen unternommen, um die Infrastruktur an die Unternehmensanforderungen anzupassen, und dann werden Featherjs beiseite geschoben.

Sehen Sie sich die gängigsten Sprachen an, die im Web verwendet werden: PHP, NodeJS, Ruby, C#, Java... Einige von ihnen sind typisiert, andere nicht. Ich habe mit all diesen Sprachen gearbeitet und kann Ihnen sagen, dass ich nach all den Jahren nicht zu einer Sprache zurückkehren möchte, die nur Fehler zur Laufzeit entdeckt. Sie alle haben ihren Reiz, ihre Vor- und Nachteile. In einem großen Team würde ich immer vorschlagen, etwas Stärkeres und Typisches zu verwenden.

Jüngstes Beispiel von jemandem, der ein von mir geschriebenes PHP-SDK verwendet. Wenn Sie eine Methode haben, die eine "große Zahl" mit 100 Ziffern akzeptiert, behandeln Sie is tatsächlich als Zeichenfolge. Der Anfänger-Entwickler öffnet einen Fehler, der fragt, warum der Aufruf von setValue(123456789123...) nicht funktioniert, es scheint ziemlich tief in NodeJS oder in einer substr Methode abzustürzen. Jetzt wird der Zwischenentwickler Ihre Dokumentation überprüfen und feststellen, dass es sich um eine Zeichenfolge hätte handeln sollen. Stellen Sie sich vor, beim Tippen erzwingen Sie die Eingabe einer Zeichenfolge, während Sie tippen oder kompilieren. Dann muss der Entwickler weder die spezifische Dokumentation lesen noch einen Fehler öffnen.

Ich habe ein bisschen recherchiert, welches Framework ich für mein neues Angular2 + NodeJS-Projekt verwenden sollte, und FeatherJS schien genau das zu sein, was ich brauchte. Wenn heute jedoch ein anderes Serverprojekt herauskommt und sagt: "Ich unterstütze offiziell TypeScript out of the box", werde ich sofort umsteigen.

Vielen Dank für alle Beiträge zu diesem Thema. Es gab einige sehr gute Diskussionen, aber ich habe das Gefühl, dass sie sich den Vorzügen des Typoskripts zuwenden, und darum geht es in dieser Ausgabe nicht wirklich. Das Kernteam hat besprochen und wir werden Typescript-Definitionen nicht unterstützen, da sie für die Arbeit mit Feathers nicht unbedingt erforderlich sind und die Geschwindigkeit reduzieren werden, mit der wir den Kern von Feathers weiterentwickeln können. Wir haben bereits viele Dinge zu aktualisieren, wenn wir eine Veröffentlichung durchführen. Wir versuchen, Abhängigkeiten zu reduzieren, um Releases früher herauszubringen, während das Hinzufügen von Typescript-Definitionen mehr Arbeit bedeuten würde. Da keiner im Kernteam von Feathers Typescript verwendet, haben wir:

1. nicht über das ausreichende Wissen verfügen, um Definitionen richtig zu pflegen
2. können keine Zeit damit verbringen, an Definitionen zu arbeiten, wenn ein kleiner Prozentsatz unserer Benutzerbasis sie „benötigt“. Wir müssen an vielen anderen Dingen arbeiten, die mehr Menschen beeinflussen.

Für diejenigen, die offizielle Definitionen erstellen/pflegen möchten, verlinken wir sie gerne im Ökosystem-Abschnitt der neuen Dokumentation, aber da sie nicht selbst verwenden und TS-Definitionen bei der Verwendung von Federn nicht erforderlich sind und eher eine persönliche Präferenz sind wir werden sie nicht pflegen. Wir werden sie aus den bestehenden Repos ziehen und @daffl wird sie in https://github.com/feathersjs/feathers-typescript einfügen . Wenn @jsgoupil , @rjsteinert , @AbraaoAlves oder andere Interessierte das Repo pflegen möchten , gewähren wir gerne Zugriff und/oder übertragen das Repo. Wir denken, dies wird es einfacher machen, die Definitionen auf dem neuesten Stand zu halten und es einfacher an DefinitelyTyped zu übermitteln (zugegeben, ich weiß nicht viel über diesen Prozess).

Wir lassen dieses Thema zur Diskussion offen, sperren aber den Thread, wenn er weiterhin die Vorzüge von Typescript diskutiert, im Gegensatz zu dem, was getan werden muss, um Definitionen außerhalb des Core-Repositorys zu implementieren. 😄

wenn Sie dies nicht einschließen möchten, könnten Sie bitte die Quellverzeichnisse in die auf npm veröffentlichten Versionen aufnehmen und jsnext:main oder module in package.json auf den Eintrag setzen

Da TypeScript jetzt Wildcard-Moduldefinitionen unterstützt, wäre es ein einfacher Workaround, alle Eingaben aus den Federn-Untermodulen zu entfernen und dies in feathers einzuschließen:

declare module 'feathers';
declare module 'feathers-*';

was Federn und alle Federn-was auch immer-Module als Typ any deklariert, was zumindest mit TS out-of-the-box "funktioniert". Sie erhalten keine verbesserte Intelligenz, aber es funktioniert einfach, ohne Dinge in bestehenden Projekten zu zerstören und das Problem von den Leuten zu lösen.

Ich auch:

"paths": {
            "feathers-socketio": ["typedefs/feathers-socketio/index.d.ts"]

falsche oder unvollständige Typedefs für die Zwischenzeit zu "überschreiben", anstatt viele kleine PRs zu öffnen und viele Patch-Versionen zu erstellen, die eigentlich nichts für Nicht-TS-Benutzer patchen.

Hallo,
Ich möchte nur einen Zweifel bezüglich der Typoskriptunterstützung ausräumen.
Gemäß der aktuellen Typdefinition von Service sind alle Servicemethoden erforderliche Methoden.

Laut Dokumentation sind Servicemethoden jedoch optional.
Sehen

Die Service-Definition sollte also in etwa wie folgt aussehen, nicht wahr?

  interface Service<T> extends events.EventEmitter {
    find?(params?: Params, callback?: any): Promise<T[] | Pagination<T>>;
    get?(id: number | string, params?: Params, callback?: any): Promise<T>;
    create?(data: T | T[], params?: Params, callback?: any): Promise<T | T[]>;
    update?(id: NullableId, data: T, params?: Params, callback?: any): Promise<T>;
    patch?(id: NullableId, data: any, params?: Params, callback?: any): Promise<T>;
    remove?(id: NullableId, params?: Params, callback?: any): Promise<T>;
    setup?(app?: Application, path?: string): void;
  }

@harish2704 ja das stimmt

Ich bleibe vorerst bei meinem Workaround "repo typedefs überschreiben" und veröffentliche vielleicht eines Tages (hehe Daumen) auf Federn-Typescript oder DefinitelyTyped, wenn ich mit meinem Projekt fertig bin.

Das stellt sicher, dass ich einige kampferprobte Definitionen für mindestens ein Produktionsprojekt einreiche.

Danke Coo!

Am Dienstag, den 9. Mai 2017 um 7:42 Uhr, Richard Michael Coo <
[email protected]> schrieb:

@harish2704 https://github.com/harish2704 ja das stimmt

Ich bleibe vorerst bei meiner Problemumgehung "Repo-Typedefs überschreiben" und
vielleicht eines Tages (hehe Daumen drücken) auf Federn-Typoskript veröffentlichen oder
Definitiv Typed, sobald ich mit meinem Projekt fertig bin.

Das stellt sicher, dass ich einige kampferprobte Definitionen auf at einreichen würde
mindestens ein Produktionsprojekt.

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/feathersjs/feathers/issues/381#issuecomment-300138396 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/ABezn0WGqH30NNp8-X-ckpVuk_BTQbbnks5r4FEQgaJpZM4Jears
.

@myknbani
Vielleicht ist es etwas zu früh, um einzuchecken - aber wie sind Sie mit den Typedefs zurechtgekommen? Brauchen Sie überhaupt eine Hand? :) Ich möchte Federn in einem neuen Projekt verwenden, aber der Mangel an TypeScript-Unterstützung ist ein kleiner Knackpunkt.

fehlende TypeScript-Unterstützung

Bin mir nicht sicher was du genau meinst. Es funktioniert total. Es ist bei weitem nicht perfekt, aber es funktioniert.

@jonlambert Ich stimme @j2L4e zu. Die vorhandenen sind nicht perfekt, aber ich mache einfach den Trick, den ich hier erwähnt habe, für alles, was keine Typprüfung macht.

IMHO, Pakete wie feathers-rest , die nur in etwa zwei Zeilen verwendet werden müssen, sind es überhaupt nicht wert :-)

Ich kann mich nicht einmal daran erinnern, was ich geändert habe, aber ich denke, es gibt keine Probleme mit Hooks und Diensten.

@j2L4e Ich feathers TypeScript nicht unterstützt. Sie haben Recht, es ist möglich, sie zusammen mit dem oben erwähnten Workaround zu verwenden, aber es wird sicherlich nicht "unterstützt", wie wir an diesem Problem sehen können!

TypeScript ist ein wesentlicher Bestandteil unseres Workflows, um sicherzustellen, dass unsere Apps auf der ganzen Linie wartbar sind, daher dachte ich, es lohnt sich zu überprüfen, ob die Definitionen von

Es funktioniert auch ohne diesen Workaround. In den offiziellen Repos sind Eingaben verfügbar, an denen nicht viel herumgefummelt werden muss. Nichts für ungut, aber es scheint mir, dass Sie nicht einmal versucht haben, ob es funktioniert.

Da keiner im Kernteam von Feathers Typescript verwendet, haben wir:

1. nicht über das ausreichende Wissen verfügen, um Definitionen richtig zu pflegen
2. können keine Zeit damit verbringen, an Definitionen zu arbeiten, wenn ein kleiner Prozentsatz unserer Benutzerbasis sie „benötigt“. Wir müssen an vielen anderen Dingen arbeiten, die mehr Menschen beeinflussen.

Als Neuling im Framework hätte ich gedacht, dass das Vorhandensein dieses Problems und die obigen Kommentare ausreichen, um einen Mangel an TS-Unterstützung anzunehmen. Tut mir leid, wenn das der falsche Schluss ist, ich werde es auf jeden Fall versuchen.

Es könnte auch "funktionieren", aber ohne jegliche Garantie, dass die Typdefinitionen mit der API auf dem neuesten Stand bleiben, scheint es in Zukunft Probleme zu verursachen.

Du hast recht.

Allerdings gab es in letzter Zeit einige Verbesserungen und der Abschluss der Typisierungen ist geplant und in Vorbereitung.

Das sind tolle Neuigkeiten 🙂 Die Arbeit mit dem Framework macht bisher wirklich Spaß und ich freue mich, es mit TS nutzen zu können 🎉

Es funktioniert auch ohne diesen Workaround. In den offiziellen Repos sind Eingaben verfügbar, an denen nicht viel herumgefummelt werden muss. Nichts für ungut, aber es scheint mir, dass Sie nicht einmal versucht haben, ob es funktioniert.

@j2L4e Du hast Recht. Ich denke, die Typedefs sind jetzt in einem viel besseren Zustand. Ich habe alle meine "Überschreibungen" gelöscht und das einzige verbleibende Problem sind die ! Behauptungen (coz von strictNullChecks ) bei der Verwendung von app.service(...) .

Ich würde vorschlagen, die Typisierungen für die Dienstdefinition (wo die Dienstmethoden alle optional sind) und die Dienstinstanz (wo alle Dienstmethoden nicht undefiniert sind) zu trennen. Momentan musste ich schmerzlich überall ! s hinzufügen, zB await app.service('api/foos').create!([{

Ich hatte dies in meinem Workaround:

interface ServiceDefinition<T> {
    find?(params?: Params, callback?: any): Promise<T[] | Pagination<T>>;
    get?(id: number | string, params?: Params, callback?: any): Promise<T>;
    create?(data: T | T[], params?: Params, callback?: any): Promise<T | T[]>;
    update?(id: NullableId, data: T, params?: Params, callback?: any): Promise<T>;
    patch?(id: NullableId, data: any, params?: Params, callback?: any): Promise<T>;
    remove?(id: NullableId, params?: Params, callback?: any): Promise<T>;
    setup?(app?: Application, path?: string): void;
  }

  interface ServiceInstance<T> extends events.EventEmitter {
    find(params?: Params, callback?: any): Promise<T[] | Pagination<T>>;
    get(id: number | string, params?: Params, callback?: any): Promise<T>;
    create(data: T | T[], params?: Params, callback?: any): Promise<T | T[]>;
    update(id: NullableId, data: T, params?: Params, callback?: any): Promise<T>;
    patch(id: NullableId, data: any, params?: Params, callback?: any): Promise<T>;
    remove(id: NullableId, params?: Params, callback?: any): Promise<T>;
  }

Wie wäre es damit:

  interface GetMethod<T>{
    /**
     * Retrieves a list of all resources from the service.
     * Provider parameters will be passed as params.query
     */
    find(params?: Params, callback?: any): Promise<T[] | Pagination<T>>;
  }

  interface FindMethod<T>{
    /**
     * Retrieves a single resource with the given id from the service.
     */
    get(id: number | string, params?: Params, callback?: any): Promise<T>;
  }

  interface CreateMethod<T>{
    /**
     * Creates a new resource with data.
     */
    create(data: T[], params?: Params, callback?: any): Promise<T[]>;
    create(data: T, params?: Params, callback?: any): Promise<T>;
  }

  interface UpdateMethod<T>{
    /**
     * Replaces the resource identified by id with data.
     * Update multiples resources with id equal `null`
     */
    update(id: NullableId, data: T, params?: Params, callback?: any): Promise<T>;
  }

  interface PatchMethod<T>{
    /**
     * Merges the existing data of the resource identified by id with the new data.
     * Implement patch additionally to update if you want to separate between partial and full updates and support the PATCH HTTP method.
     * Patch multiples resources with id equal `null`
     */
    patch(id: NullableId, data: any, params?: Params, callback?: any): Promise<T>;
  }

  interface RemoveMethod<T>{
    /**
     * Removes the resource with id.
     * Delete multiple resources with id equal `null`
     */
    remove(id: NullableId, params?: Params, callback?: any): Promise<T>;
  }

  interface OptionalMethods <T> {
    find?(params?: Params, callback?: any): Promise<T[] | Pagination<T>>;
    get?(id: number | string, params?: Params, callback?: any): Promise<T>;
    create?(data: T[], params?: Params, callback?: any): Promise<T[]>;
    create?(data: T, params?: Params, callback?: any): Promise<T>;
    update?(id: NullableId, data: T, params?: Params, callback?: any): Promise<T>;
    patch?(id: NullableId, data: any, params?: Params, callback?: any): Promise<T>;
    remove?(id: NullableId, params?: Params, callback?: any): Promise<T>;
  }

  type GetService<T> = GetMethod<T> & ServiceAddons;
  type FindService<T> = FindMethod<T> & ServiceAddons;
  type CreateService<T> = CreateMethod<T> & ServiceAddons;
  type UpdateService<T> = UpdateMethod<T> & ServiceAddons;
  type PatchService<T> = PatchMethod<T> & ServiceAddons;
  type RemoveService<T> = RemoveMethod<T> & ServiceAddons;

  interface ServiceCore<T> extends OptionalMethods<T> {
    setup?(app?: Application<any>, path?: string): void;
  }

  interface ServiceAddons extends events.EventEmitter {
    filter(any?: any): this;
  }

  type Service<T> = OptionalMethods<T> & ServiceAddons;

Auf diese Weise können Sie jeden Nicht-TS-Dienst eingeben, indem Sie einen neuen Typ erstellen, z. B. für Federn-Mailer:

type MailerService = CreateService<Mail>;

Oder ein (ziemlich nutzloser) Dienst, der nur erstellen und löschen kann:

type TrashyService<T> = CreateService<T> & RemoveService<T>;

Dies alles mit der Verwendung von Selektorfunktionen, um Dienste zu erhalten (zB app.service(s => s.mailout)) gibt diesen Dienst mit seinem entsprechenden Typ zurück. Wie hier zu sehen:

Einfach wieder einchecken, wie geht es weiter? @j2L4e Post ^ sieht wirklich ordentlich aus! Ich frage mich nur, was noch zu tun ist, um zu sehen, ob ich Ihnen helfen kann.

OK, Fehler, die ich bisher sehe:

import * as handler from 'feathers-errors/handler';
import * as notFound from 'feathers-errors/not-found'; //[1]

app.use(notFound()); //[2]
app.use(handler()); //[3]

[1]

[ts] Modul '"c:/Users/George/Source/Repos/ts4/node_modules/feathers-errors/not-found"' wird in eine Nicht-Modul-Entität aufgelöst und kann mit diesem Konstrukt nicht importiert werden.

[2]

Argument vom Typ 'Funktion' kann Parameter vom Typ 'PathParams' nicht zugewiesen werden.
Der Typ 'Funktion' ist dem Typ '(string | RegExp)[]' nicht zuordenbar.
Die Eigenschaft 'push' fehlt im Typ 'Funktion'.

[3]

Argument vom Typ 'Funktion' kann Parameter vom Typ 'PathParams' nicht zugewiesen werden.
Der Typ 'Funktion' ist dem Typ '(string | RegExp)[]' nicht zuordenbar.
(Alias) notFound(): Funktion

Gibt es vorhandene Problemumgehungen?

https://github.com/feathersjs/feathers-errors/pull/87

Für die nächste Version hat @j2L4e großartige Arbeit geleistet, um die Eingaben zu polieren. Hier sind die Schritte zum Ausprobieren und Betatest:

npm i -g lerna
git clone -b buzzard-j2L4e  https://github.com/feathersjs-ecosystem/feathers-typescript.git
cd feathers-typescript
lerna bootstrap

lerna verknüpft alle Pakete und Deps für Sie. Gehen Sie nun in den Unterordner ./packages/tests (wo noch keine Tests zu finden sind, also habe ich es zu einer Art Spielplatz gemacht) und probieren Sie die TS-Güte aus! Schauen Sie sich index.ts an.

Um zu kompilieren und auszuführen, führen Sie npm start von ./packages/tests aus

Die Migration von Feathers 2 nach 3 wurde gerade gestartet, index.d.ts-Dateien fehlen jetzt in den Head-@feathersjs- Paketen. Gibt es Pläne, sie wiederherzustellen?

Wie oben in einem Kommentar erwähnt, wurden sie nach https://github.com/feathersjs-ecosystem/feathers-typescript/tree/buzzard-j2L4e verschoben, um sie an DefinitelyTyped zu senden. @j2L4e ist im

Ja, es war viel mehr Arbeit als ich erwartet hatte und das Feedback der Community war praktisch null. Ich werde es machen, sobald ich die Zeit finde. Allerdings nicht zu früh.

wenn sich hier jemand melden würde, wäre das echt super. Es dreht sich jetzt alles um das DT-Flusen, das abgesehen davon, dass alles gut funktioniert

ein schnelles Kopieren und Einfügen von slack:

Leute, ich bin im Moment wirklich sehr beschäftigt, daher hat das Tippen alles andere als oberste Priorität. Sie funktionieren, aber DefinitelyTyped ist in Bezug auf die Linting-Regeln ziemlich streng. Wenn Sie helfen könnten, dass die Eingaben den definitiv typisierten Linting-Prozess bestehen, wäre das großartig

schau dir meine DT-Gabel hier an types/feathersjs__packagename

klonen, npm installieren und den Linter auf einem der Pakete ausführen, zB npm run lint @feathersjs/feathers (bearbeitet)

@feathersjs/feathers fusselt bereits richtig, sodass Sie es als Referenz verwenden können. (bearbeitet)

TypeScript-Definitionen warten darauf, dass sie DefinitelyTyped unter https://github.com/DefinitelyTyped/DefinitelyTyped/pull/22805 hinzugefügt werden

Definitionen sind jetzt über NPM zugänglich!

Ja, installiere @types/feathersjs__package für das Paket @feathersjs/package und gib bitte ein Feedback!

@erikma danke für deine Unterstützung!

@j2L4e Vielen Dank für Ihre Arbeit! Aber sind Sie sicher, dass Sie alle @featherjs/express Funktionen exportiert haben? Ich kann in Ihrer Typoskriptdefinitionsdatei keine Erwähnung von rest, json, notFound und urlencoded finden.

du hast recht, die fehlen.

füge vorerst eine typings.d.ts-Datei hinzu mit:

import { ErrorRequestHandler, RequestHandler } from 'express';

declare module '@feathersjs/express' {
    export function errorHandler(options?: any): ErrorRequestHandler;
    export function notFound(): RequestHandler;
    export const rest: {
        (): () => void;
        formatter: RequestHandler;
    };
}

keine ahnung wo urlencoded hingehen soll.

urlencoded und json wurden in der letzten Nebenversion zu express hinzugefügt. Wurden die Eingaben von express noch nicht aktualisiert?

Ist das Express oder Federn/Express?

Es wurde gerade aus Express reexportiert:

• https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/express/index.d.ts#L31
• https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/express/index.d.ts#L42

Sie sollten also in der Lage sein, Import { urlencoded, json } from '@feathersjs/express' zu tun? Oder würden Sie es von den exportierten original ?

Alles, was von require('express') exportiert wird, wird von @feathersjs/express wieder exportiert: https://github.com/feathersjs/express/blob/master/lib/index.js#L82

Weißt du auch, wie man mit channel.ts mit guten Definitionen umgeht?
Es tut mir leid, Sie in so kurzer Zeit mit all den Problemen konfrontiert zu haben.

@types/feathersjs__socket-commons importieren

Importieren ? ich verstehe nicht

Tut mir leid, es sollte eigentlich "@feathersjs/socket-commons importieren" heißen. Sie müssen seine Typen installieren.

Wenn ich @types/feathersjs__feathers installiere, funktioniert mein app.channel nicht. Wenn ich dann @types/feathersjs__socket-commons hinzufüge, funktioniert mein app.on mehr.

wird über DefinitelyTyped/DefinitelyTyped#23195 behoben

Bitte nehmen Sie alle weiteren Probleme hier auf: https://github.com/feathersjs-ecosystem/feathers-typescript/issues

Die Problemverfolgung für TS-Definitionen ist etwas verwirrend. Sie verweisen die Leute auf das Federn-Typoskript-Repository, aber Sie erwähnten _"Dieses Repository ist jetzt veraltet"_. Wenn Sie die Definitionen in den jeweiligen Repos nicht beibehalten und stattdessen DT verwenden, ist es meiner Meinung nach am sinnvollsten, die Issues auch im DT-Repo zu belassen, da dort vermutlich die PRs entstehen und zusammengeführt werden.

Ich denke, wir haben uns dann entschlossen, es hier auszuprobieren. Ich habe Anfragen über mehrere Kanäle erhalten und die Leute angewiesen, dorthin zu gehen. Das war eine schnelle Möglichkeit, das zu zentralisieren. Mir persönlich ist es egal, wohin es geht, solange es an einem Ort ist

Gibt es einen Grund, warum wir nicht feathers.services.dogs anstelle von feathers.service('dogs') ?

Ja. feathers.service('dogs') ruft defaultService (was den Dienst auf dem Client instanziiert) und entfernt Schrägstriche aus Dienstnamen.

TypeScript-Definitionen befinden sich jetzt in DefinitelyTyped .

Bitte richten Sie alle Probleme und Fragen an https://github.com/feathersjs-ecosystem/feathers-typescript/issues