Oh, je viens de voir https://github.com/feathersjs/feathers/issues/64... Mais peut-être laisser cela ouvert ? Alors certaines personnes proposeront de l'aide ?

La meilleure façon de faire avancer les choses serait de démarrer un référentiel avec quelques définitions de base de Typescript (dans #64, j'ai posté quelques pointeurs sur l'endroit où commencer) et de continuer
discussion là-bas.

Je peux laisser ce numéro ouvert pendant encore un mois ou deux, mais l'autre numéro a été ouvert pendant presque un an sans que personne ne l'ait relevé. Comme mentionné ici, l'équipe de base actuelle n'utilise pas Typescript ou Angular, donc ce n'est pas vraiment sur notre radar (et nous préférerions ne garder les problèmes ouverts que s'il y a une chance qu'ils soient résolus dans un avenir prévisible).

Je pense que @harangue a travaillé sur quelques définitions de base. Peut-être pourrions-nous déplacer la discussion que nous avons eue sur Slack sur l'endroit où ils vivraient ici ?

Bien sur! Si vous avez besoin de résoudre ce problème, allez-y.

Ce serait vraiment bien si le tapuscrit peut être pris en charge. Comment puis-je aider ?

@rollymaduk J'ai fait des progrès décents sur les définitions de Feathers, mais nous n'avons pas encore établi le meilleur moyen de les distribuer (et les choses sont un peu transitoires avec TypeScript 2 sur le point de sortir). Si vous souhaitez avoir quelque chose à travailler d'ici là, vous pouvez voir l'essentiel sur lequel j'ai travaillé.

@harangue très beau travail en fait, il a l'air tout à fait prêt. s'il vous plaît, qu'entendez-vous par la meilleure façon de les distribuer ?

Je ne sais pas si nous en avons déjà discuté, mais je pense que tout ira bien si nous distribuons les définitions Typescript dans le référentiel principal tant qu'il y a quelqu'un pour les maintenir et les tenir à jour. Donc, une fois qu'ils sont prêts, nous pouvons en faire une partie d'une version Feathers 2.1 (qui, je pense, pourrait également être livrée avec quelques avertissements indiquant que, par exemple, les rappels dans les services seront obsolètes dans la v3).

Existe-t-il un fork de generator-feathers pour TypeScript ? Intéressé à travailler sur une fourche TS du générateur ?

edit : j'ai forké le générateur et poussé un premier commit.

Donc @harangue a déjà implémenté un grand nombre de définitions Feathers Typescript dans https://gist.github.com/harangue/9d4ed79118e2656f5e3d2d699296ed36 nous avons juste besoin de quelqu'un pour les examiner et potentiellement les finaliser et les soumettre dans le référentiel de définitions TypeScript.

Je vais faire cette partie de la release Auk qui débarquera avant la fin de l'année. Si personne n'intervient d'ici là, ce problème sera définitivement clos et il n'y aura pas de prise en charge officielle de TypeScript ni de discussion supplémentaire à ce sujet, à part une demande d'extraction pour l'ensemble.

Si leur qualité est bonne, vous devriez envisager de regrouper les définitions avec Feathers. Je pense que beaucoup de gens voudraient éviter autant que possible d'utiliser un gestionnaire de paquets secondaire.

Ils seraient installables via npm i @types/feathers . Vous n'avez plus besoin de trucs comme typings .

Je pensais que vous veniez de les ajouter à https://github.com/DefinitelyTyped/DefinitelyTyped. Quelle que soit la manière normale de procéder. Si nous les ajoutons au référentiel principal, les autres référentiels de plugins auront probablement besoin de définitions ajoutées en conséquence.

Dans la FAQ DefinitelyTyped :

La branche types-2.0 est automatiquement publiée dans la portée @types sur NPM grâce à types-publisher. Cela se produit généralement dans l'heure suivant la fusion des modifications.

Je ne le savais pas. Donc, les ajouter à DefinitelyTyped suffirait.

Ah, JS. Vous êtes parti un mois ou deux et l'écosystème évolue :sourire:

Désolé qu'il y ait eu un silence radio à ce sujet de mon côté depuis si longtemps. Je viens de publier une autre révision de l'essentiel aujourd'hui qui résout un problème que j'avais eu avec les anciennes frappes. Je suis enfin en mesure de recommencer à travailler avec Feathers sur l'un de mes projets, et je m'attends à ajouter au moins des saisies pour les modules que j'utilise.

La définition telle qu'elle existe dans l'essentiel est prête à être soumise à Definitely Typed sauf pour 1) les tests de dactylographie (il suffit de tirer quelques exemples des documents Feathers) et 2) les annotations JS Doc (ce qui serait bien pour intellisense, mais sont pas essentiel).

Techniquement, les dactylographies des crochets doivent également être extraites des crochets à plumes. L'extension des typages ici devient cependant un peu compliquée, car uberproto a des modèles de mixin qui sont un peu difficiles à reproduire avec des types statiques.

Content de te retrouver @harangue. Je pense que nous pouvons laisser les saisies de crochet ici pour le moment puisque nous prévoyons de faire des crochets une partie du noyau (voir #408). De plus, les saisies devront peut-être être mises à jour avec la nouvelle méthode .hooks comme décrit dans https://blog.feathersjs.com/feathers-application-and-error-hooks-7a5982e70024 (pas encore documenté, travail dessus :).

@harangue quand pensez-vous que vous allez soumettre vos types à définitivement tapés ?

Salut tout le monde, vraiment cool de voir les defs TypeScript arriver. @harangue , quelle est votre recommandation pour l'importation de plumes en conjonction avec les defs dans votre esprit ? Ils n'exportent pas les espaces de noms qui correspondent aux bibliothèques feathers , donc import ... from 'feathers' renvoie une erreur.

Hé @subvertallchris , vous pouvez utiliser

import * as feathers from 'feathers';`

ou

import feathers = require('feathers');

ils sont équivalents. :) Juste au moment où je pensais avoir à nouveau du temps pour Feathers, je me suis retrouvé pris dans d'autres trucs, mais j'espère que ces définitions seront complètement étoffées d'ici la nouvelle année.

@j2L4e Votre fourche de générateur TS semble être en 404 ? des nouvelles à ce sujet? Et @harangue comment ça va ? Je suis vraiment impatient de voir ce terrain et je suis heureux d'aider à la mise en œuvre des fichiers de définition TS, un fork avec un indicateur feathers generate --ts pour que le cli joue bien avec le tapuscrit ou les docs. Fais-moi savoir.

Il était difficile à maintenir, fonctionnait correctement pour mysql et l'authentification locale uniquement et les plumes de générateur seront bientôt obsolètes de toute façon. Alors je l'ai mis au rebut.

En attendant avec impatience une sortie de la nouvelle cli

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

@j2L4e Votre fourche de générateur TS semble être en 404 ? des nouvelles à ce sujet?
Et @harangue comment ça va ? j'ai vraiment hâte de voir ça
et je suis heureux d'aider à la mise en œuvre des fichiers de définition TS, un
fork avec un drapeau feathers generate --ts pour faire jouer le cli avec
tapuscrit bien ou docs. Fais-moi savoir.

--
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/feathersjs/feathers/issues/381#issuecomment-267966376

Y a-t-il encore quelqu'un qui travaille sur ce problème ? J'aimerais beaucoup utiliser ce projet avec Typescript

Bonjour à tous

Je suis heureux de dire : _C'est presque fini._ 😄
J'ai fait de nombreux forks dans FeatherjsOrg et j'écris des définitions par repo. Et vous pouvez voir ces exemples à l'aide de feathersjs avec la meilleure des définitions dactylographiées

Plumes+Nodejs+Type de texte
PlumesClient+Aurelia+Type de texte

[oui, il prend en charge ESNext, Commonjs, AMD et les modules globaux pour les morceaux de client]

L'échantillon d'aurelia vous donne des indices sur la façon de travailler avec angular2. Ces référentiels contiennent de nombreux détails sur la façon dont le dactylographe peut être utile pour fournir une documentation en direct sur

Je ferai des relations publiques bientôt, mais vous pouvez voir, poser des questions et me donner votre avis. ?

Fourche avec définitions :

• plumes-crochets
• plumes-primus
• plumes-douille
• plumes-reste
• plumes-authentification-client
• plumes-client
• plumes

J'ai eu un peu de boulot, mais j'adore les plumes et le tapuscrit

c'est tous les liens relatifs

J'ai corrigé les liens.

@AbraaoAlves C'est super, merci ! J'étais sur le point d'écrire un commentaire boudeur et de clore le problème et je suis heureux que vous ayez commenté en premier 😉 J'ai hâte de voir les pull request !

Bon homme @AbraaoAlves !

@AbraaoAlves Je voulais juste dire merci beaucoup, c'est une aide énorme pour moi ! Je ne peux pas croire que tu sois venu au dernier moment

@AbraaoAlves J'ai du mal à utiliser l'une de vos définitions. Lorsque j'installe les packages dans le package.json tels que

"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"`

Ainsi, lorsque j'essaie de l'utiliser dans un fichier TypeScript tel que :

import * as feathers from "feathers"

il réussit la compilation mais ne s'exécute pas correctement.

Ils n'installent que les définitions de type et non la source. Il semble également que le repose-plumes n'exporte pas de fonction pour que le texte dactylographié reconnaisse
rest()' as a valid command for app.use(rest());

Encore un autre problème, il semble que app.use n'accepte plus les arguments tels que
this.app.use(bodyParser.json());

et doit être utilisé comme

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

@Chrisdf Je

Plus de détails à ce sujet : problème

@AbraaoAlves y a-t-il une raison pour laquelle vous ne mettez pas les définitions sur DefinitelyTyped ? De cette façon, ils seraient disponibles via l'espace de noms @types de NPM et cela supprimerait l'exigence pour l'équipe principale de maintenir les définitions à jour dans le cadre d'une version.

@AbraaoAlves Au fait, pourquoi les définitions n'ont-elles pas été validées mais publiées sous forme de version tarball ? Ils seraient plus disponibles pour typings cette façon. J'apprécie grandement cet effort et conviens qu'il serait bénéfique d'apporter les définitions à la communauté sous une forme utilisable, DefinitelyTyped sera une bonne chose.

J'ai réécrit les frappes en fonction du travail de @AbraaoAlves et de @harangue. Je soumettrai ces saisies à DefinitelyTyped sous peu.

Cool. Que pouvons-nous/devrions-nous faire pour cela ? Sinon, je suppose qu'une fois que les choses ont été incluses dans DefinitelyTyped, nous pouvons fermer ce problème ?

devrait être inclus dans ce référentiel et le package.json
(au moins ce serait le meilleur des cas)

Exemple : fichier inclus package.json

Salut tout le monde o/
Merci pour la patience et les retours.

@stevehipwell et @daffl : Je crois que les fichiers de définitions

Je connais l'initiative @types et

Aujourd'hui, si nous avons la possibilité de maintenir les deux au même endroit, sous une même version, les erreurs de communication auront une incidence bien moindre et nous aurons des définitions officielles par version !

Des exemples de projets javascript conservent vos propres définitions : Aurelia , Preact , ...

Si tout le monde est d'accord, voici les liens PullRequest :

• plumes
• plumes-authentification-client
• plumes-crochets
• plumes-primus
• plumes-reste
• plumes-douille
• plumes-authentification
• plumes-client (j'enverrai après que ces autres aient résolu)

Il y a encore beaucoup de travail à faire, comme les tests de saisie, l'automatisation, ... mais cela ne fait que commencer.

Dactylographiée S2 FeathersJS !

Salut tout le monde,

Je suis d'accord avec @AbraaoAlves que la solution idéale consiste à inclure les fichiers de définition TypeScript avec les packages directement, mais le pire des cas est l'inclusion de fichiers de définition qui finissent par être obsolètes. C'est pourquoi je suggérais que DefinitlyTyped soit utilisé pour maintenir les définitions en tant que solution intermédiaire conforme à la mentalité de Node consistant à diviser des éléments complexes en composants plus petits et plus faciles à gérer.

Pour s'assurer que les définitions sont synchronisées avec les versions du projet, il faudrait une meilleure transparence de la part de l'équipe Plumes. Jusqu'à présent, en écrivant mes propres définitions, je ne suis pas sûr de l'état actuel de la version ; le blog n'est pas tenu à jour et il y a un certain nombre de noms de code (v3, pingouin, buse ??) qui ne veulent rien dire.

@AbraaoAlves - Vos définitions semblent bonnes, mais d'après ce que je peux voir, il manque des domaines tels que les méthodes hooks() . Seriez-vous intéressé à les ajouter ?

Salut @stevehipwell ,

Merci pour les commentaires. Et voici mes réponses sur :

Cependant, le pire des cas est l'inclusion de fichiers de définition qui finissent par être obsolètes...
Pour s'assurer que les définitions sont synchronisées avec les versions du projet, il faudrait une meilleure transparence de la part de l'équipe Plumes

Oui, le problème de synchronisation est un vrai problème, mais peut être résolu avec des tests.
Je suggère de faire des tests en tapuscrit : #508

Si d'accord ou pas sur cette solution, donnez votre avis là-bas.

Je suis vraiment motivé pour faire de feathersjs un texte dactylographié convivial, sans changements perturbateurs, bien sûr.
Nous avons beaucoup plus de travail à faire, comme les méthodes hooks() , mais maintenant nous pouvons construire cela ensemble.

Si vous voyez un bogue ou manquez une définition, faites un problème.

@AbraaoAlves, on dirait qu'il y a le désir de garder les définitions à jour et je suis plus qu'heureux de vous aider. Je suppose que vous souhaitez signaler des bogues sur les dépôts principaux pour les définitions manquantes une fois que vos demandes de fusion sont terminées ?

@stevehipwell Oui, c'est le but.

Quel est le problème avec le calendrier de sortie et que pouvons-nous faire pour l'améliorer ? Les jalons ici sont encore à peu près ce que nous prévoyons :

• La prochaine version est Auk qui est le code complet avec le générateur en cours de finalisation et les documents mis à jour. Les changements de rupture sont dans l' authentification par
• La version suivante est Buzzard qui inclura les changements de base suivants (que j'appelle en fait parfois v3 - et ne devrait probablement pas ) :
  
  
  
  • Indépendance du framework (https://github.com/feathersjs/feathers/milestone/9) (et avec cela une structure unifiée pour le client )
  
  
  • Crochets dans le noyau (https://github.com/feathersjs/feathers/issues/408)
  
  
  • Filtrage des événements basé sur les canaux (https://github.com/feathersjs/feathers/issues/388#issuecomment-239564856)
  
  

Quel devrait être le processus pour mettre à jour les définitions une fois que ces fonctionnalités ont atterri ?

Les définitions dactylographiées sont comme .h (en-tête) en C++. Si vous avez un en-tête qui ne répond pas à votre module, des problèmes peuvent survenir à l'exécution, comme une documentation non alignée avec la version du code utilisé.

Par conséquent, je pense que des définitions doivent être incluses dans chaque étape nécessitant une modification de l'API, par exemple : déplacer une méthode vers un autre référentiel ou ajouter un nouveau paramètre à une méthode, …

Je vais changer la définition de l'authentification par plumes, en supprimant les crochets vers des projets spécifiques pour les aligner sur la v1.
La question est maintenant : les définitions doivent-elles être incluses dans cette version actuelle de FeathersJS ?

@AbraaoAlves Je pense que oui. Je peux faire une version mineure pour tous vos PR et nous pouvons itérer à partir de là. La seule chose sur laquelle je me pose encore des questions, c'est le #508, mais je ferai un commentaire là-dessus.

J'ai fait face à deux problèmes avec les frappes ci-dessus.

socketio ne veut pas fonctionner.

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

Et le repos nécessite un gestionnaire même si votre plumes-cli sort sans arguments.

.configure(rest()) // Erreur ici declare function rest(handler:Function): Function;
.configure(socketio())

nœud -v
v6.6.0

npm -v
3.10.5

tsc -v
2.1.6

Il serait également intéressant de montrer comment utiliser "feathers()" comme module puisque c'est le point d'entrée.
Je peux convertir tous les autres services/intergiciels générés, mais il doit y avoir un moyen plus agréable d'encapsuler plumes () dans un constructeur () {}. (Je suis nouveau dans les plumes, je le fais peut-être mal aussi...)

Pouvons-nous sortir les définitions en tant que version de correctif ? Ce niveau de changement conviendrait parfaitement à une version de correctif ; aucun changement de rupture et aucune nouvelle fonctionnalité. Même des frappes partielles ou incorrectes valent mieux que pas de frappes.

Une fois que nous avons une version, nous avons un point de départ de travail que nous pouvons utiliser pour améliorer les frappes.

Si cela continue de stagner et devra suivre la route DefinitelyTyped pour mes définitions. Je ne veux pas avoir à faire cela et je suis heureux de vous aider avec les définitions dans les dépôts.

J'avais une question pour @AbraaoAlves dans #508 mais je n'ai pas encore reçu de réponse. Si nous publions les versions, nous avons besoin de quelqu'un pour résoudre rapidement les problèmes qui pourraient survenir (d'autant plus que dans le pire des cas, cela pourrait casser les applications existantes qui utilisent TypeScript). Peut-on se coordonner sur Slack pour un bon moment pour faire et vérifier la sortie (on peut commencer par un minor.pre) ?

Sortie en versions mineures pour chaque module via

• 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

Tout d'abord, merci à tous ceux qui ont participé à cette discussion et surtout à ceux qui ont contribué. Nous avons publié des versions mineures avec les définitions TypeScript pour de nombreux référentiels Feathers, mais cela a causé un certain nombre de problèmes - et des versions imprévues pour des modules par ailleurs assez stables, obligeant les utilisateurs à mettre à jour qui n'utilisent même pas du tout TypeScript - sans aucun moyen pour le noyau team (où personne n'utilise TypeScript) pour les corriger de manière fiable.

Mon principal point à retenir de toute la discussion Feathers + TypeScript est qu'il semble très difficile de créer et de maintenir des typages pour un projet JavaScript existant (pour moi, cela ne parlait pas très bien pour les revendications d'interopérabilité de TypeScript). Étant donné que l'équipe principale n'utilise pas TypeScript, notre seul choix pour avancer lors de la publication de modifications d'API importantes est de supprimer toutes les définitions TypeScript obsolètes.

Ce serait formidable d'avoir des définitions TypeScript à jour pour les modules Feathers dans le référentiel DefinitelyTyped et nous ferons tout notre possible pour y arriver, mais avec le temps limité dont nous disposons, nous ne pouvons pas ajouter la surcharge de soutenir et maintenir quelque chose que nous n'utilisons pas personnellement dans nos propres référentiels.

pour moi, cela ne parlait pas très bien pour les revendications d'interopérabilité de TypeScript

Feathers est parfaitement utilisable sans dactylographies spécifiques, il s'agit simplement de JS puis sans l'intellisense et les types. Le système de plugins de plumes, en particulier, avec son utilisation intensive de mixins, rend la création de saisies difficile, car c'est une façon de faire les choses très peu dactylographiée. Je suis un utilisateur régulier de dactylographes (et fan de celui-ci), mais je suis retourné à ES6 pour les trucs de plumes côté serveur pour le moment.
Maintenir les types séparément semble être le moyen le mieux adapté ici, personne dans l'équipe de base n'utilisant réellement le script dactylographié.

Feathers serait le framework côté serveur préféré pour Angular s'il fonctionnait bien avec TypeScript. Je dis juste :-). J'avance pour le moment.

@j2L4e Je pense que ce sera plus facile pour la prochaine version une fois que la plupart des choses qui sont maintenant mélangées par les plugins feront partie du noyau. Je ne sais pas si cela résoudra le problème général d'obtenir de l'aide de manière fiable avec cela.

@rjsteinert Ce qui existe en ce moment devrait fonctionner principalement, mais oui, comme pour tout projet open source, vous avez la possibilité d'essayer d'aider ou de passer à autre chose.

vous avez la possibilité d'essayer d'aider ou de passer à autre chose.

Je suis l'une de ces personnes qui découvrent Angular, programmeur JS de longue date, réalisant à quel point TS rend la vie grandiose et réalisant que si nous ne jouons pas avec lui côté serveur, l'équipe va maudire et fantasmer sur la réécriture tous les jours pendant les deux prochaines années. Après tout, nous pouvons opter pour des plumes en raison du manque d'options et dans ce cas, nous aidons certainement à maintenir les dactylographies à jour. En disant simplement que lorsque nous passons par là et que nous voyons "notre seul choix pour avancer lors de la publication de modifications d'API est de supprimer toutes les définitions TypeScript obsolètes", nous regardons ailleurs. Ne le prenez pas pour un léger, je comprends la nécessité de soutenir les projets existants, vous n'êtes pas assez chanceux (je suis peut-être condamné) pour être dans ma situation où nous faisons une réécriture.

@rjsteinert qu'est-ce que TypeScript offre qui le rend si précieux pour vous ? (question honnête) Une fois mon travail actuel sur Feathers terminé, ma curiosité est presque suffisamment piquée par l'intérêt qu'il suscite pour jeter un œil à TypeScript, moi-même. Je sais que cela aide avec la saisie semi-automatique/CodeSense, mais l'API Feathers est si petite que je ne peux pas imaginer qu'elle soit AUSSI utile. Veuillez pardonner mon ignorance. ;)

autocomplete/CodeSense est un sous-produit sympa mais je suis généralement dans Vim donc je ne reçois pas les goodies. Le grand changement que je vois jusqu'à présent est la standardisation de la façon dont vous expliquez clairement comment utiliser certaines fonctions ou objets contribués. En parcourant les bibliothèques dans NPM, je trouve de nombreuses bibliothèques utilisant leur propre solution maison et créative pour rendre évident et utilisable ce qu'un langage typé dynamiquement ne vous dit pas. TS vous permet d'économiser une tonne de tâches de vérification de type vous-même lorsque vous écrivez du code et facilite la compréhension rapide de l'utilisation du code de quelqu'un d'autre. Ces jours-ci, j'ai tendance à penser que j'en ai marre d'écrire du JS standard, c'est mon propre style et je ne veux vraiment pas lire le README de quelqu'un à chaque fois que j'utilise une bibliothèque externe.

Je suis d'accord avec @rjsteinert , je travaille avec JavaScript depuis plus de 15 ans et je suis un grand fan de se souvenir de toutes les API. J'avais même l'habitude de coder avec Notepad sans aucune couleur. J'avais l'habitude de travailler dans une équipe chez Microsoft où l'ensemble du site était écrit uniquement en JavaScript. Je peux vous dire qu'une fois que votre site atteint plus de 50 programmeurs, tout devient un gâchis. Non seulement vous devez suivre plus de conventions, mais votre site ne plante qu'à l'exécution.

Si vous écrivez sur ce post GitHub et utilisez FeatherJS, vous êtes probablement un développeur JavaScript passionné. Si vous êtes l'un des développeurs de FeatherJS, vous ne verrez aucun intérêt à utiliser TypeScript pour vous-même. Vous n'avez pas besoin d'outillage spécial ni d'aide de TypeScript. Vous êtes une licorne JavaScript.
J'étais extrêmement contre TypeScript (surtout que nous étions obligés de l'utiliser avec la version Alpha 1.1), mais au fil des années, j'ai appris à l'apprécier et je ne peux pas m'en passer. Les collègues avec qui vous travaillerez ne connaîtront pas aussi bien que vous l'êtes en JavaScript. Ils viendront de tous les horizons et maudissent à quel point JavaScript est une merde.

Le langage TypeScript s'est tellement développé grâce aux commentaires de la communauté depuis lors.
Vous ne pouvez pas créer un site Web massif sans outillage et sans une grande équipe. Comme le dit @rjsteinert , l'équipe commencera à utiliser TypeScript pour le côté client, puis après un certain temps, elle sera extrêmement mécontente d'utiliser le côté serveur. Des efforts seront déployés pour modifier l'infrastructure afin qu'elle corresponde aux besoins de leur entreprise, puis les plumes seront écartées.

Découvrez les langages les plus utilisés sur le web : PHP, NodeJS, Ruby, C#, Java... Certains sont typés, d'autres non. J'ai travaillé avec tous ces langages et je peux vous dire qu'après toutes ces années, je n'ai pas envie de revenir à un langage de type « discover-error-at-runtime-only ». Ils ont tous leur charme, leurs avantages et leurs inconvénients. Dans une grande équipe, je suggérerais toujours d'aller avec quelque chose d'un peu plus fort et typé.

Exemple le plus récent de quelqu'un utilisant un SDK PHP que j'ai écrit. Si vous avez une méthode qui accepte un "grand nombre" avec 100 chiffres, vous traitez en fait is comme une chaîne. Le développeur débutant ouvrira un bogue demandant pourquoi lorsque l'appel de setValue(123456789123...) ne fonctionne pas, il semble planter assez bas dans NodeJS ou dans une méthode substr . Maintenant, le développeur intermédiaire ira vérifier votre documentation et constatera qu'il aurait dû s'agir d'une chaîne. Imaginez qu'en tapant, vous forcez la saisie d'une chaîne au fur et à mesure que vous tapez ou compilez. Ensuite, le développeur n'a pas besoin de lire la documentation spécifique ni d'ouvrir un bogue.

J'ai fait quelques recherches sur le framework à utiliser pour mon nouveau projet Angular2 + NodeJS, et FeatherJS semblait être exactement ce dont j'avais besoin. Cependant, si un autre projet de serveur est sorti aujourd'hui et a déclaré "Je prends officiellement en charge TypeScript dès la sortie de la boîte", je passerai immédiatement à autre chose.

Merci pour la contribution de chacun sur cette question. Il y a eu de très bonnes discussions mais j'ai l'impression qu'elles commencent à s'orienter vers les mérites du tapuscrit et ce n'est pas vraiment de cela qu'il s'agit. L'équipe principale a discuté et nous n'allons pas prendre en charge les définitions de Typescript car elles ne sont pas essentielles pour travailler avec Feathers et réduiront la vitesse à laquelle nous pouvons faire évoluer le noyau de Feathers. Nous avons déjà beaucoup de choses à mettre à jour lors d'une sortie. Nous essayons de réduire les dépendances afin de sortir les versions plus tôt, alors que l'ajout de définitions Typescript ajouterait plus de travail. Comme aucun membre de l'équipe principale de Feathers n'utilise Typescript, nous :

1. ne pas avoir les connaissances adéquates pour maintenir correctement les définitions
2. ne peut pas passer du temps à travailler sur des définitions alors qu'un petit pourcentage de notre base d'utilisateurs « en a besoin ». Nous avons beaucoup d'autres éléments sur lesquels travailler qui ont un impact sur plus de gens.

Pour ceux qui souhaitent créer/maintenir des définitions officielles, nous serions heureux de les lier dans la section écosystème des nouveaux documents, mais parce que nous ne les utilisons pas nous-mêmes et que les définitions TS ne sont pas nécessaires lors de l'utilisation de Feathers et sont plus une préférence personnelle nous n'allons pas les maintenir. Nous les extrairons des dépôts existants et https://github.com/feathersjs/feathers-typescript. Si @jsgoupil , @rjsteinert , @AbraaoAlves ou toute autre personne intéressée souhaite maintenir le référentiel, nous serions heureux d'accorder l'accès et/ou de transférer le référentiel. Nous pensons que cela facilitera la mise à jour des définitions et la soumission à DefinitelyTyped (il est vrai que je ne connais pas grand-chose à ce processus).

Nous laisserons ce problème ouvert à la discussion mais verrouillerons le fil s'il continue de discuter des mérites de Typescript par opposition à ce qui doit être fait pour implémenter des définitions en dehors du référentiel principal. ??

si vous ne souhaitez pas inclure cela, pourriez-vous s'il vous plaît inclure les répertoires source dans les versions publiées sur npm et définir jsnext:main ou module dans package.json à l'entrée

Étant donné que TypeScript prend désormais en charge les définitions de modules génériques, ce serait une solution de contournement facile pour purger toutes les saisies des sous-modules plumes et les inclure dans feathers :

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

qui déclarera les plumes et tous les modules Plumes-quel que soit le type any , ce qui au moins "le fait fonctionner" avec TS prêt à l'emploi. Vous n'obtenez pas d'intellisense amélioré, mais cela fonctionne simplement sans casser des éléments dans les projets existants et élimine le problème du dos des gens.

Je fais aussi:

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

pour « remplacer » les définitions de type incorrectes ou incomplètes pour l'instant, plutôt que d'ouvrir de nombreux petits PR et de créer de nombreuses versions de correctifs qui ne corrigent rien pour les utilisateurs non-TS.

Salut,
Je veux juste clarifier un doute concernant le support dactylographié.
Selon la définition de type actuelle de Service , toutes les méthodes de service sont des méthodes obligatoires.

Mais selon la documentation, les méthodes de service sont facultatives.
Voir

Donc, la définition du service devrait être quelque chose comme ci-dessous, n'est-ce pas ?

  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 oui c'est vrai

Je m'en tiens à ma solution de contournement "override repo typedefs" pour le moment, et peut-être qu'un jour (je croise les doigts) publier sur plumes-typescript ou DefinitelyTyped, une fois que j'aurai terminé mon projet.

Cela garantit que je soumettrais des définitions testées au combat sur au moins un projet de production.

Merci Coo !

Le mar 9 mai 2017 à 07:42, Richard Michael Coo <
[email protected]> a écrit :

@harish2704 https://github.com/harish2704 oui c'est vrai

Je m'en tiens à ma solution de contournement "override repo typedefs" pour le moment, et
peut-être qu'un jour (je croise les doigts) publier sur plumes dactylographiées ou
DefinitelyTyped, une fois que j'ai terminé mon projet.

Cela garantit que je soumettrais des définitions testées au combat sur à
au moins un projet de production.

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/feathersjs/feathers/issues/381#issuecomment-300138396 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ABezn0WGqH30NNp8-X-ckpVuk_BTQbbnks5r4FEQgaJpZM4Jears
.

@myknbani
Peut-être qu'il est un peu tôt pour s'enregistrer - mais comment avez-vous géré les typesdefs ? Avez-vous besoin d'un coup de main? :) Je cherche à utiliser des plumes dans un nouveau projet, mais le manque de prise en charge de TypeScript est un peu un point de friction.

manque de prise en charge de TypeScript

Je ne sais pas ce que vous voulez dire exactement. Cela fonctionne totalement. C'est loin d'être parfait, mais ça marche.

@jonlambert je suis d'accord avec @j2L4e. Ceux qui existent ne sont pas parfaits, mais je fais juste l'astuce que j'ai mentionnée ici pour tout ce qui ne fait pas de vérification de type.

À mon humble avis, les packages comme feathers-rest qui ne doivent être utilisés que sur environ deux lignes ne valent pas du tout la peine d'être tapés :-)

Je ne me souviens même pas de ce que j'ai changé, mais je pense qu'il n'y a aucun problème à utiliser les crochets et les services.

@j2L4e Je feathers ne prend pas en charge TypeScript. Vous avez raison, il est possible de les utiliser avec la solution de contournement que vous avez mentionnée ci-dessus, mais ce n'est certainement pas « pris en charge » comme nous pouvons le voir par ce problème !

TypeScript fait partie intégrante de notre flux de travail pour garantir que nos applications sont maintenables sur toute la ligne, j'ai donc pensé qu'il valait la peine de vérifier si les définitions de @myknbani étaient disponibles. Pas de soucis cependant ! ??

Cela fonctionne également sans cette solution de contournement. Il existe des dactylographies disponibles dans les dépôts officiels qui n'ont pas besoin de trop de manipulations. Ne vous offensez pas, mais il me semble que vous n'avez même pas essayé si cela fonctionne.

Comme aucun membre de l'équipe principale de Feathers n'utilise Typescript, nous :

1. ne pas avoir les connaissances adéquates pour maintenir correctement les définitions
2. ne peut pas passer du temps à travailler sur des définitions alors qu'un petit pourcentage de notre base d'utilisateurs « en a besoin ». Nous avons beaucoup d'autres éléments sur lesquels travailler qui ont un impact sur plus de gens.

En tant que nouveau venu dans le framework, j'aurais pensé que la présence de ce problème, ainsi que les commentaires ci-dessus étaient suffisants pour supposer le manque de support TS. Désolé si c'est une mauvaise conclusion, je vais être sûr de l'essayer.

En outre, cela pourrait "fonctionner", mais sans aucune forme de garantie pour garantir que les définitions de type restent à jour avec l'API, il semble que cela puisse potentiellement causer des problèmes à l'avenir.

Vous avez raison.

Cependant, il y a eu pas mal d'améliorations ces derniers temps et l'achèvement des dactylographies est prévu et en cours.

C'est une excellente nouvelle 🙂 J'apprécie vraiment de travailler avec le framework jusqu'à présent et je suis ravi de pouvoir l'utiliser avec TS 🎉

Cela fonctionne également sans cette solution de contournement. Il existe des dactylographies disponibles dans les dépôts officiels qui n'ont pas besoin de trop de manipulations. Ne vous offensez pas, mais il me semble que vous n'avez même pas essayé si cela fonctionne.

@j2L4e Vous avez raison. Je pense que les typesdefs sont dans un bien meilleur état maintenant. J'ai supprimé tous mes "remplacements" et le seul problème restant jusqu'à présent sont les assertions ! (coz of strictNullChecks ) lors de l'utilisation de app.service(...) .

Je suggérerais de séparer les typages pour la définition de service (où les méthodes de service sont toutes facultatives) et l'instance de service (où toutes les méthodes de service ne sont pas indéfinies). Actuellement, je devais péniblement ajouter des ! s partout par exemple await app.service('api/foos').create!([{

J'avais ceci dans ma solution de contournement:

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

Que diriez-vous de ceci :

  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;

Cela vous permet de taper n'importe quel service non-TS en construisant un nouveau type, par exemple pour plumes-mailer :

type MailerService = CreateService<Mail>;

Ou un service (assez inutile) qui ne peut que créer et supprimer :

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

Tout cela en utilisant des fonctions de sélection pour avoir des services à l'esprit (par exemple, app.service(s => s.mailout)) renverra ce service avec son type approprié. Comme vu ici :

Je viens de revenir, comment allons-nous ? @j2L4e post ^ a l'air vraiment

OK, les erreurs que je vois jusqu'à présent :

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] Le module '"c:/Users/George/Source/Repos/ts4/node_modules/feathers-errors/not-found"' se résout en une entité non-module et ne peut pas être importé à l'aide de cette construction.

[2]

L'argument de type 'Function' n'est pas assignable au paramètre de type 'PathParams'.
Le type 'Function' n'est pas assignable au type '(string | RegExp)[]'.
La propriété 'push' est manquante dans le type 'Function'.

[3]

L'argument de type 'Function' n'est pas assignable au paramètre de type 'PathParams'.
Le type 'Function' n'est pas assignable au type '(string | RegExp)[]'.
(alias) notFound() : fonction

Existe-t-il des solutions de contournement ?

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

Pour la prochaine version, @j2L4e a fait un excellent travail pour peaufiner les frappes. Voici les étapes pour l'essayer et le test bêta :

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

lerna reliera tous les packages et deps pour vous. Maintenant, allez dans le sous-dossier ./packages/tests (où aucun test n'a encore été trouvé, donc j'en ai fait une sorte de terrain de jeu) et essayez la bonté TS ! Consultez index.ts.

Pour compiler et exécuter, exécutez npm start partir de ./packages/tests

Je viens de commencer la migration de Feathers 2 vers 3, les fichiers index.d.ts sont désormais manquants dans les packages @feathersjs principaux . Avez-vous l'intention de les restaurer ?

Comme mentionné dans un commentaire ci-dessus, ils ont été déplacés vers https://github.com/feathersjs-ecosystem/feathers-typescript/tree/buzzard-j2L4e pour être soumis à DefinitelyTyped. @j2L4e est trop occupé en ce moment, c'est donc à quelqu'un d'autre de le récupérer. D'après ce que j'ai compris, il s'agit principalement d'obtenir le passage de Linting et de les soumettre à DefinitelyTyped. Je serai heureux d'aider quiconque est prêt à le ramasser mais n'a pas l'intention de le prendre sur moi.

Oui, c'était beaucoup plus de travail que prévu et les retours de la communauté étaient pratiquement nuls. Je le ferai dès que je trouverai le temps. Pas trop tôt, cependant.

si quelqu'un intervenait ici, ce serait vraiment vraiment génial. Tout tourne autour du linting DT maintenant, qu'à part tout fonctionne bien

un copier-coller rapide depuis slack :

les gars, je suis vraiment très occupé en ce moment, donc les frappes sont tout sauf la priorité absolue. ils fonctionnent mais DefinitelyTyped est assez strict en termes de règles de linting. si vous pouviez aider à faire en sorte que les frappes passent le processus de linting définitivement typé, ce serait génial

consultez ma fourchette DT ici https://github.com/j2L4e/definitelytyped , vous trouverez les packages Feathersjs en types/feathersjs__packagename

cloner, npm installer et exécuter le linter sur l'un des packages, par exemple npm run lint @feathersjs/feathers (édité)

@feathersjs/feathers est déjà en train de pelucher correctement, vous pouvez donc l'utiliser comme référence. (édité)

Les définitions TypeScript attendent d'être révisées pour être ajoutées à DefinitelyTyped sur https://github.com/DefinitelyTyped/DefinitelyTyped/pull/22805

Les définitions sont désormais accessibles via NPM !

Oui, installez @types/feathersjs__package pour le package @feathersjs/package et donnez votre avis s'il vous plaît !

@erikma merci pour votre soutien !

@j2L4e Merci pour votre travail ! Mais êtes-vous sûr d'avoir exporté toutes les fonctions @featherjs/express ? Je ne trouve aucune mention de rest, json, notFound et urlencoded dans votre fichier de définitions tapuscrit.

tu as raison, il en manque.

ajoutez un fichier typings.d.ts pour l'instant avec :

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

aucune idée où urlencoded devrait aller.

urlencoded et json ont été ajoutés à express dans la dernière version mineure. Les saisies express n'ont-elles pas encore été mises à jour ?

Est-ce express ou plumes/express ?

Il vient d'être réexporté depuis Express :

• 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

Donc tu devrais pouvoir faire Import { urlencoded, json } from '@feathersjs/express' ? Ou l'obtiendriez-vous du original exporté ?

Tout ce qui est exporté depuis require('express') est réexporté par @feathersjs/express : https://github.com/feathersjs/express/blob/master/lib/index.js#L82

De plus, savez-vous comment gérer channel.ts avec des définitions correctes ?
Je suis désolé de vous jeter tous les problèmes en si peu de temps.

Importer @types/feathersjs__socket-commons

Importer ? Je ne comprends pas

Désolé, il devrait en fait dire « Importer @feathersjs/socket-commons ». Vous devez installer ses types.

Si j'installe @types/feathersjs__feathers mon app.channel ne fonctionne pas. Si j'ajoute ensuite @types/feathersjs__socket-commons mon app.on cesse de fonctionner.

sera corrigé via DefinitelyTyped/DefinitelyTyped#23195

veuillez prendre d'autres problèmes ici : https://github.com/feathersjs-ecosystem/feathers-typescript/issues

Le suivi des problèmes pour les définitions TS est un peu déroutant. Vous dirigez les gens vers le dépôt de plumes, mais vous avez mentionné _"Ce dépôt est maintenant obsolète"_. Si vous n'allez pas conserver les définitions dans les référentiels respectifs et utiliser à la place DT, je pense qu'il serait plus logique de conserver les problèmes dans le référentiel DT également, car c'est vraisemblablement de là que les PR proviendront et seront fusionnés.

Je pense que nous avons décidé de l'essayer ici. J'ai reçu des demandes via plusieurs canaux, et demander aux gens d'aller là-bas était un moyen rapide de centraliser cela. Personnellement, je me fiche de savoir où ça va tant que c'est un endroit

Y a-t-il une raison pour laquelle nous ne pouvons pas utiliser feathers.services.dogs au lieu de feathers.service('dogs') ?

Oui. feathers.service('dogs') appelle defaultService (qui instancie le service sur le client) et supprime les barres obliques des noms de service.

Les définitions TypeScript sont désormais au format DefinitelyTyped .

Veuillez adresser vos problèmes et questions à https://github.com/feathersjs-ecosystem/feathers-typescript/issues