Oh, acabo de ver https: //github.com/feathersjs/feathers/issues/64 ... ¿ Pero tal vez dejar esto abierto? ¿Entonces algunas personas ofrecerán ayuda?

La mejor manera de hacer avanzar esto sería iniciar un repositorio con algunas definiciones básicas de TypeScript (en el n. ° 64 publiqué algunos consejos sobre dónde comenzar) y continuar
discusión allí.

Puedo dejar este problema abierto durante uno o dos meses más, pero el otro problema estuvo abierto durante casi un año sin que nadie lo recogiera. Como se mencionó allí, el equipo central actual no está utilizando Typecript o Angular, por lo que realmente no está en nuestro radar (y preferiríamos mantener los problemas abiertos solo si existe la posibilidad de que se aborden en un futuro previsible).

Creo que @harangue ha estado trabajando en algunas definiciones básicas. ¿Quizás podamos mover la discusión que tuvimos en Slack sobre dónde vivirían aquí?

¡seguro! Si necesita cerrar este problema, continúe.

Sería muy bueno si se pudiera admitir el mecanografiado ... ¿en qué puedo ayudar?

@rollymaduk He logrado un progreso decente en las definiciones de Feathers, pero aún tenemos que establecer la mejor manera de distribuirlas (y las cosas son un poco transitorias con TypeScript 2 a punto de lanzarse). Si desea tener algo en lo que trabajar hasta entonces, puede ver la esencia en la que he trabajado.

@harangue realmente buen trabajo de hecho parece bastante listo ... Supongo que algunas áreas que pueden requerir algo de atención incorporarían algunos complementos básicos como autenticación, proveedores (rest, socke.io, primus) y algunos de los adaptadores db, ¿verdad? por favor, ¿a qué te refieres con la mejor forma de distribuirlos?

No estoy seguro de si hemos hablado de esto todavía, pero creo que estará bien si distribuimos las definiciones de TypeScript en el repositorio principal siempre que haya alguien que las mantenga y las mantenga actualizadas. Entonces, una vez que estén listos, podemos convertirlo en parte de una versión de Feathers 2.1 (que creo que también podría enviarse con algunas advertencias de que, por ejemplo, las devoluciones de llamada en los servicios quedarán obsoletas en la v3).

¿Hay alguna bifurcación de generator-feathers para TypeScript? ¿Interesado en trabajar en una bifurcación TS del generador?

editar: bifurqué el generador y presioné una primera confirmación.

Entonces @harangue prácticamente ha implementado un gran conjunto de definiciones de Feathers TypeScript que ya están en https://gist.github.com/harangue/9d4ed79118e2656f5e3d2d699296ed36 , solo necesitamos que alguien las revise y potencialmente las finalice y las envíe al repositorio de definiciones de TypeScript.

Voy a hacer esta parte del lanzamiento de Auk que aterrizará antes de fin de año. Si nadie da un paso adelante hasta entonces, este problema se cerrará para siempre y no habrá soporte oficial de TypeScript ni más discusiones sobre esto que no sea una solicitud de extracción para todo.

Si su calidad es buena, debería considerar agrupar las definiciones con Plumas. Creo que mucha gente querría evitar el uso de un administrador de paquetes secundario tanto como sea posible.

Se podrían instalar a través de npm i @types/feathers . Ya no necesitas cosas como typings .

Pensé que solo los agregarías a https://github.com/DefinitelyTyped/DefinitelyTyped. Cualquiera que sea la forma normal de hacer esto. Si los agregamos al repositorio central, los otros repositorios de complementos probablemente necesiten agregar definiciones en consecuencia.

De las preguntas frecuentes DefinitelyTyped:

La rama types-2.0 se publica automáticamente en el alcance de @types en NPM gracias a types-publisher. Esto suele suceder una hora después de la fusión de los cambios.

No lo sabía. Entonces, agregarlos a DefinitelyTyped sería suficiente.

Ah, JS. Te vas por un mes o dos y el ecosistema evoluciona: sonríe:

Lamento que haya habido un silencio de radio sobre esto por mi parte durante tanto tiempo. Acabo de publicar otra revisión de la esencia hoy que soluciona un problema que había tenido con los viejos mecanografiados. Finalmente puedo comenzar a trabajar con Feathers nuevamente en uno de mis proyectos, y espero agregar mecanografía al menos para los módulos que me encuentro usando.

La definición tal como existe en la esencia está lista para ser enviada a Definitely Typed excepto por 1) pruebas de mecanografía (solo necesito extraer algunos ejemplos de los documentos de Feathers) y 2) anotaciones de JS Doc (lo cual sería bueno para intellisense, pero son no esencial).

Técnicamente, los tipos de anzuelos también deben extraerse a los anzuelos de plumas. Sin embargo, extender la mecanografía aquí se vuelve un poco complicado, ya que uberproto tiene algunos patrones de mezcla que son un poco difíciles de replicar con tipos estáticos.

Es bueno tenerte de vuelta @harangue. Creo que podemos dejar las mecanografías de los ganchos aquí por ahora, ya que estamos planeando hacer que los ganchos formen parte del núcleo (ver # 408). Además, es posible que sea necesario actualizar las mecanografías con el nuevo método .hooks como se describe en https://blog.feathersjs.com/feathers-application-and-error-hooks-7a5982e70024 (aún no documentado, trabajando en él :).

@harangue, ¿ cuándo cree que enviará sus tipos a definitivamente mecanografiado?

Hola a todos, es genial ver aparecer definiciones de TypeScript. @harangue , ¿cuál es tu recomendación para importar plumas junto con las definiciones en tu esencia? No están exportando espacios de nombres que coincidan con las bibliotecas feathers , por lo que import ... from 'feathers' arroja un error.

Hola @subvertallchris , puedes usar

import * as feathers from 'feathers';`

o

import feathers = require('feathers');

son equivalentes. :) Justo cuando pensé que estaba teniendo tiempo para Feathers nuevamente, me vi envuelto en otras cosas, pero espero tener estas definiciones completamente desarrolladas para el nuevo año.

@ j2L4e ¿ Su horquilla de generador TS parece estar 404'ing? ¿Alguna noticia sobre esto? Además, @harangue , feathers generate --ts para hacer que el cli juegue bien con el mecanografiado o los documentos. Hágamelo saber.

Era difícil de mantener, funcionaba correctamente para mysql y solo para autenticación local, y de todos modos los generadores de plumas quedarán obsoletos pronto. Así que lo deseché.

Esperando ansiosamente el lanzamiento del nuevo cli

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

@ j2L4e ¿ Su horquilla de generador TS parece estar 404'ing? ¿Alguna noticia sobre esto?
Además, @harangue ,
tierra y estoy feliz de ayudar a la implementación de archivos de definición de TS, un
tenedor con una bandera feathers generate --ts para hacer que el cli juegue con
mecanografiado agradablemente o docs. Hágamelo saber.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub:
https://github.com/feathersjs/feathers/issues/381#issuecomment -267966376

¿Hay alguien todavía trabajando en este tema? Me gustaría mucho usar este proyecto con Typecript

Hola a todos

Estoy feliz de decir: _Ya casi está terminado_ 😄
Hice muchas bifurcaciones en FeatherjsOrg y escribí definiciones por repositorio. Y puede ver estas muestras usando feathersjs con las mejores definiciones de mecanografiado

Plumas + Nodejs + Mecanografiado
PlumasCliente + Aurelia + Texto mecanografiado

[sí, es compatible con ESNext, Commonjs, AMD y módulos globales para fragmentos de clientes]

La muestra de aurelia te da pistas sobre cómo trabajar con angular2. Estos repositorios tienen muchos detalles sobre cómo el mecanografiado puede ser útil para brindar una documentación en vivo sobre

Pronto haré relaciones públicas, pero pueden ver, hacer preguntas y darme comentarios. 👌?

Horquilla con definiciones:

• plumas-ganchos
• plumas-primus
• plumas-socketio
• plumas-descanso
• Plumas-autenticación-cliente
• plumas-cliente
• plumas

Tuve un poco de trabajo, pero me encantan las plumas y el mecanografiado.

eso es todo enlaces relativos

Arreglé los enlaces.

@AbraaoAlves ¡ Esto luce genial, gracias! Estaba a punto de escribir un comentario malhumorado y cerrar el problema y me alegra que hayas comentado primero 😉 ¡Espero ver las solicitudes de extracción!

Buen hombre @AbraaoAlves !

@AbraaoAlves Solo quería

@AbraaoAlves Tengo problemas para usar cualquiera de sus definiciones. Cuando instalo los paquetes en package.json como

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

Entonces, cuando intento usarlo en un archivo TypeScript como:

import * as feathers from "feathers"

pasa la compilación pero en realidad no se ejecuta correctamente.

Solo instalan las definiciones de tipo y no la fuente. También parece que feathers-rest no exporta una función para que el mecanografiado reconozca
rest()' as a valid command for app.use(rest());

También un problema más, parece que app.use ya no acepta argumentos como
this.app.use(bodyParser.json());

y debe usarse como

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

@Chrisdf Arreglo esto con archivos tgz en package.json, clono ahora e intento instalarlo nuevamente.

Más detalles sobre esto: problema

@AbraaoAlves, ¿hay alguna razón por la que no está poniendo las definiciones en DefinitelyTyped? De esta manera, estarían disponibles a través del espacio de nombres @types de NPM y eliminaría el requisito de que el equipo central mantenga las definiciones actualizadas como parte de una versión.

@AbraaoAlves Por cierto, ¿por qué las definiciones no se confirmaron sino que se publicaron como versión tarball? Estarían más disponibles por typings esta manera. Aprecio mucho este esfuerzo y estoy de acuerdo en que sería beneficioso llevar las definiciones a la comunidad en una forma utilizable. DefinitelyTyped será una buena decisión.

Reescribí las mecanografías basadas en el trabajo de @AbraaoAlves y @harangue. En breve enviaré estos mecanografiados a DefinitelyTyped.

Frio. ¿Algo que podamos / deberíamos hacer para esto? De lo contrario, supongo que una vez que se hayan incluido las cosas en DefinitelyTyped, ¿podemos cerrar este problema?

debe incluirse en este repositorio y el package.json
(al menos ese sería el mejor de los casos)

Ejemplo: archivo incluido package.json

Hola a todos o /
Gracias por la paciencia y los comentarios.

@stevehipwell y @daffl : Creo que el archivo de definiciones mecanografiado es como una documentación, una documentación en vivo. ¡Pero la documentación que no está alineada con el código es peor que no tener documentación!

Conozco @types y la iniciativa

Hoy, si tenemos la oportunidad de mantener ambos en un solo lugar, bajo un solo comunicado, los errores de comunicación tendrán una incidencia mucho menor y tendremos definiciones oficiales por comunicado!

Ejemplos de proyectos javascript mantienen sus propias definiciones: Aurelia , Preact , ...

Si todos están de acuerdo, aquí están los enlaces de PullRequest:

• plumas
• Plumas-autenticación-cliente
• plumas-ganchos
• plumas-primus
• plumas-descanso
• plumas-socketio
• Autenticación de plumas
• feathers-client (lo enviaré después de que estos otros se hayan resuelto)

Hay mucho más trabajo por hacer, como pruebas mecanografiadas, automatización, ... pero esto recién está comenzando.

Mecanografiado S2 FeathersJS!

Hola a todos,

Estoy de acuerdo con @AbraaoAlves en que la solución ideal es incluir los archivos de definición de TypeScript con los paquetes directamente, sin embargo, el peor de los casos son los archivos de definición incluidos que terminan siendo desactualizados. Es por eso que estaba sugiriendo que DefinitlyTyped se usó para mantener las definiciones como una solución intermedia que está en consonancia con la mentalidad de Node de dividir cosas complejas en componentes más pequeños y más fáciles de administrar.

Para asegurarse de que las definiciones se mantengan sincronizadas con los comunicados del proyecto, sería necesario que el equipo de plumas ofreciera una mayor transparencia. Hasta ahora, mientras escribo mis propias definiciones, no estoy seguro de cuál es el estado actual del lanzamiento; el blog no se mantiene actualizado y hay una serie de nombres en clave (v3, auk, buzzard ??) que no significan nada.

@AbraaoAlves : sus definiciones se ven bien, pero por lo que puedo ver, faltan áreas como los métodos hooks() . ¿Estaría interesado en agregarlos?

Hola @stevehipwell ,

Gracias por la respuesta. Y aquí están mis respuestas sobre:

Sin embargo, en el peor de los casos se incluyen archivos de definición que terminan siendo obsoletos ...
Para asegurarse de que las definiciones se mantengan sincronizadas con los lanzamientos del proyecto, debería haber una mayor transparencia por parte del equipo de plumas.

Sí, el problema de sincronización es un problema real, pero se puede solucionar con pruebas.
Sugiero hacer pruebas en mecanografiado: # 508

Si está de acuerdo o no con esta solución, tome su opinión allí.

Estoy realmente motivado para hacer de feathersjs un texto mecanografiado amigable, sin cambios disruptivos, por supuesto.
Tenemos mucho más trabajo por hacer, como los métodos hooks() , pero ahora podemos construir esto juntos.

Si ve un error o pierde una definición, plantee un problema.

@AbraaoAlves parece que existe el deseo de mantener las definiciones actualizadas y estoy más que feliz de ayudar. Supongo que desea generar errores en los repositorios principales para las definiciones faltantes una vez que se completen sus solicitudes de fusión.

@stevehipwell Sí, ese es el punto.

¿Cuál es el problema con el calendario de lanzamientos y qué podemos hacer para mejorarlo? Los hitos aquí siguen siendo aproximadamente los que estamos planeando:

• La próxima versión es Auk, que tiene un código completo con el generador finalizado y la actualización de los documentos. Los cambios más importantes están en la autenticación de plumas v1.0.0
• El lanzamiento posterior es Buzzard, que incluirá los siguientes cambios fundamentales importantes (a los que, de hecho, a veces me refiero como v3, y probablemente no debería 😉):
  
  
  
  • Independencia del marco (https://github.com/feathersjs/feathers/milestone/9) (y con eso una estructura unificada para el cliente )
  
  
  • Ganchos en el núcleo (https://github.com/feathersjs/feathers/issues/408)
  
  
  • Filtrado de eventos basado en canales (https://github.com/feathersjs/feathers/issues/388#issuecomment-239564856)
  
  

¿Cuál debería ser el proceso para actualizar las definiciones una vez que esas características hayan aterrizado?

Las definiciones de mecanografiado son como .h (encabezado) en C ++. Si tiene un encabezado que no responde a su módulo, pueden ocurrir problemas en tiempo de ejecución, como una documentación que no se alinea con la versión del código utilizado.

Por lo tanto, creo que se deben incluir definiciones en cada hito que requiera un cambio en la API, por ejemplo: mover el método a otro repositorio o agregar un nuevo parámetro a un método, ...

Cambiaré la definición de autenticación de plumas, eliminando los ganchos a proyectos específicos para alinearlos con v1.
La pregunta ahora es: ¿Deberían incluirse definiciones en esta versión actual de FeathersJS?

@AbraaoAlves Creo que sí. Puedo hacer un lanzamiento menor para todos sus RP y podemos iterar desde allí. Lo único que todavía me pregunto es el número 508, pero lo comentaré.

Me he enfrentado a dos problemas con las tipificaciones anteriores.

socketio no quiere trabajar.

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

Y el descanso requiere un controlador a pesar de que su feathers-cli genera sin argumentos.

.configure (rest ()) // Error aquí declare la función rest (manejador: Función): Función;
.configurar (socketio ())

nodo -v
v6.6.0

npm -v
3.10.5

tsc -v
2.1.6

También sería interesante mostrar cómo utilizar "feathers ()" como módulo, ya que este es el punto de entrada.
Puedo convertir todos los demás servicios / middleware generados, pero debe haber una forma más agradable de encapsular feathers () en un constructor () {}. (Soy nuevo en las plumas, podría estar haciéndolo mal también ...)

¿Podemos publicar las definiciones como una versión de parche? Este nivel de cambio encajaría perfectamente en una versión de parche; sin cambios importantes y sin nuevas funciones. Incluso los mecanografiados parciales o incorrectos son mejores que ningún mecanografiado.

Una vez que tengamos un lanzamiento, entonces tendremos un punto de partida funcional en el que podemos usar el aumento para mejorar la mecanografía.

Si esto continúa estancando y tendré que seguir la ruta DefinitelyTyped para mis definiciones. No quiero tener que hacer esto y estoy feliz de ayudar con las definiciones en los repositorios.

Tenía una pregunta para @AbraaoAlves en el n. ° 508, pero aún no he recibido una respuesta. Si hacemos los lanzamientos, necesitamos que alguien esté disponible para abordar rápidamente cualquier problema que pueda surgir (especialmente porque, en el peor de los casos, podría romper las aplicaciones existentes que usan TypeScript). ¿Podemos coordinar en Slack para pasar un buen rato para realizar y verificar el lanzamiento (podemos empezar con un minor.pre)?

Lanzado en versiones menores para cada módulo a través de

• 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

En primer lugar, gracias a todos los que participaron en esta discusión y especialmente a los que contribuyeron. Lanzamos versiones menores con las definiciones de TypeScript para muchos repositorios de Feathers, pero causó una serie de problemas, y lanzamientos no programados para módulos bastante estables, lo que hace que los usuarios actualicen que incluso no usan TypeScript en absoluto, sin forma para el núcleo. team (donde nadie usa TypeScript) para corregirlos de manera confiable.

Mi principal conclusión de toda la discusión de Feathers + TypeScript es que parece ser muy difícil crear y mantener mecanografiados para un proyecto de JavaScript existente (para mí, eso no hablaba muy bien de las afirmaciones de interoperabilidad de TypeScript). Dado que el equipo principal no está utilizando TypeScript, nuestra única opción para avanzar cuando se lanzan cambios importantes en la API es eliminar las definiciones de TypeScript obsoletas.

Sería genial tener definiciones de TypeScript actualizadas para los módulos Feathers en el repositorio DefinitelyTyped y haremos todo lo posible para ayudar a que eso suceda, pero con el tiempo limitado que tenemos disponible no podemos agregar la sobrecarga de apoyar y mantener algo que no usamos personalmente en nuestros propios repositorios.

para mí eso no hablaba muy bien de las afirmaciones de interoperabilidad de TypeScript

Feathers se puede usar perfectamente sin tipificaciones específicas, es simplemente JS sin el intellisense y los tipos. Especialmente el sistema de complementos de feathers con su uso intensivo de mixins dificulta la creación de mecanografía, porque es una forma de hacer las cosas que no es mecanografiada. Soy un usuario habitual de mecanografiado (y fan del mismo), pero volví a ES6 para las cosas de plumas del lado del servidor por ahora.
Mantener los tipos por separado parece ser la forma más adecuada aquí, ya que nadie en el equipo central usa realmente mecanografiado.

Feathers sería el marco del lado del servidor preferido para Angular si funcionara bien con TypeScript. Sólo digo' :-). Me estoy moviendo por ahora.

@ j2L4e Creo que esto será más fácil para la próxima versión una vez que la mayoría de las cosas que ahora están mezcladas con complementos serán parte del núcleo. Sin embargo, no estoy seguro de si resolverá el problema general de obtener ayuda confiable con esto.

@rjsteinert Lo que hay en este momento debería funcionar principalmente, pero sí, como con cualquier proyecto de código abierto, tienes la oportunidad de intentar ayudar o seguir adelante.

tienes la oportunidad de intentar ayudar o seguir adelante.

Soy una de esas personas nuevas en Angular, programador de JS desde hace mucho tiempo, dándome cuenta de cuánto TS hace la vida grandiosa y dándome cuenta de que si no actuamos con él en el lado del servidor, el equipo lo maldecirá y fantaseará con la reescritura. todos los días durante los próximos años. Después de todo, podemos optar por las plumas debido a la falta de opciones y, en ese caso, definitivamente ayudar a mantener a Typings actualizado. Sin embargo, solo digo que cuando pasamos y vemos que "nuestra única opción para avanzar cuando lanzamos cambios importantes en la API es eliminar cualquier definición de TypeScript obsoleta", buscamos en otro lugar. No lo tome como un desaire, entiendo la necesidad de apoyar proyectos existentes, ustedes no tienen la suerte (puede que esté condenado) para estar en mi situación en la que estamos haciendo una reescritura.

@rjsteinert, ¿qué ofrece TypeScript que lo hace tan valioso para usted? (pregunta honesta) Después de que mi conjunto actual de trabajo de Feathers esté completo, mi curiosidad casi se despierta lo suficiente por el interés en él como para echar un vistazo a TypeScript, yo mismo. Sé que ayuda con el autocompletado / CodeSense, pero la API Feathers es tan pequeña que no puedo imaginar que sea TAN útil. Perdone mi ignorancia. ;)

autocomplete/CodeSense es un buen subproducto, pero normalmente estoy en Vim, así que no obtengo los beneficios. El gran cambio que veo hasta ahora es estandarizar cómo se hace obvio cómo usar algunas funciones u objetos contribuidos. Al mirar a través de bibliotecas en NPM, encuentro muchas bibliotecas que utilizan su propia solución creativa y de cosecha propia para hacer obvio y utilizable lo que un lenguaje escrito dinámicamente no le dice. TS ahorra una tonelada de placas de caldera de tipo verificando las cosas usted mismo cuando está escribiendo código y facilita la comprensión rápida de cómo usar el código de otra persona. En estos días tiendo a pensar que estoy harto de escribir JS boiler plate que es mi propio estilo y realmente no quiero leer el README de alguien cada vez que uso una biblioteca externa.

Estoy de acuerdo con @rjsteinert , he trabajado con JavaScript durante más de 15 años y soy un gran fanático de recordar todas las API. Incluso solía codificar con el Bloc de notas sin ningún color. Solía ​​trabajar en un equipo en Microsoft donde todo el sitio estaba escrito solo con JavaScript. Puedo decirle que una vez que su sitio llega a más de 50 programadores, todo se vuelve un desastre. No solo debe seguir más convenciones, sino que su sitio se bloquea solo en tiempo de ejecución.

Si está escribiendo en esta publicación de GitHub y usa FeatherJS, probablemente sea un ávido desarrollador de JavaScript. Si usted es uno de los desarrolladores de FeatherJS, no verá ningún sentido en usar TypeScript por sí mismo. No necesita herramientas especiales ni ayuda de TypeScript. Eres un unicornio de JavaScript.
Estaba extremadamente en contra de TypeScript (especialmente porque nos vimos obligados a usarlo con la versión Alpha 1.1), pero a lo largo de los años, he aprendido a apreciarlo y no puedo vivir sin él. Los colegas con los que trabajará no estarán tan bien informados como usted en JavaScript. Vendrán de diferentes orígenes y estarán maldiciendo por qué JavaScript es una mierda.

El lenguaje TypeScript ha crecido mucho a partir de los comentarios de la comunidad desde entonces.
No se puede construir un sitio web masivo sin herramientas y con un gran equipo. Como dice @rjsteinert , el equipo comenzará a usar TypeScript para el lado del cliente, luego, después de un tiempo, estarán extremadamente descontentos de usar el lado del servidor. Se hará un esfuerzo para cambiar la infraestructura para que coincida con los requisitos de la empresa, luego se dejarán de lado las plumas.

Eche un vistazo a los lenguajes más populares utilizados en la web: PHP, NodeJS, Ruby, C #, Java ... Algunos de ellos están escritos, otros no. Trabajé con todos estos lenguajes y puedo decirles que después de todos estos años, no quiero volver a un lenguaje de "descubrimiento-error-solo-en-tiempo de ejecución". Todos tienen su encanto, pros y contras. En un equipo grande, siempre sugeriría ir con algo un poco más fuerte y mecanografiado.

El ejemplo más reciente de alguien que usa un SDK de PHP que escribí. Si tiene un método que acepta un "número grande" con 100 dígitos, en realidad lo trata como una cadena. El desarrollador principiante abrirá un error preguntando por qué cuando llamar a setValue(123456789123...) no funciona, parece fallar bastante en NodeJS o en un método substr . Ahora, el desarrollador intermedio revisará su documentación y encontrará que debería haber sido una cadena. Imagine que al escribir, fuerza a ingresar una cadena a medida que escribe o compila. Entonces el desarrollador no necesita leer la documentación específica ni abrir un error.

Investigué un poco sobre qué marco usar para mi nuevo proyecto Angular2 + NodeJS, y FeatherJS parecía ser justo lo que necesitaba. Sin embargo, si hoy aparece otro proyecto de servidor y dice "Soy compatible oficialmente con TypeScript", lo cambiaré de inmediato.

Gracias por el aporte de todos sobre este tema. Ha habido una muy buena discusión, pero creo que está comenzando a inclinarse hacia los méritos de la escritura mecanografiada y de eso no se trata realmente este tema. El equipo central ha debatido y no vamos a admitir las definiciones de Typecript, ya que no son esenciales para trabajar con Feathers y reducirán la velocidad a la que podemos evolucionar el núcleo de Feathers. Ya tenemos muchas cosas que actualizar al hacer un lanzamiento. Estamos tratando de reducir las dependencias para que las versiones se publiquen antes, mientras que agregar definiciones de TypeScript agregaría más trabajo. Dado que ninguno en el equipo central de Feathers usa Typecript, nosotros:

1. no tengo el conocimiento adecuado para mantener correctamente las definiciones
2. No podemos perder tiempo trabajando en definiciones cuando un pequeño porcentaje de nuestra base de usuarios las “requiere”. Tenemos muchos otros elementos en los que trabajar que impactan a más personas.

Para aquellos que deseen crear / mantener definiciones oficiales, estaremos encantados de vincularlos en la sección de ecosistemas de los nuevos documentos, pero debido a que no los usamos nosotros mismos y las definiciones de TS no son necesarias cuando se usa Feathers y son más una preferencia personal. no los vamos a mantener. Los sacaremos de los repositorios existentes y https://github.com/feathersjs/feathers-typescript. Si @jsgoupil , @rjsteinert , @AbraaoAlves o cualquier otra persona interesada quisiera mantener el repositorio, estaremos encantados de otorgar acceso y / o transferir el repositorio. Creemos que esto hará que sea más fácil mantener las definiciones actualizadas y facilitar su envío a DefinitelyTyped (es cierto que no sé mucho sobre ese proceso).

Dejaremos este tema abierto para discusión, pero bloquearemos el hilo si continúa por el camino de discutir los méritos de TypeScript en lugar de lo que se debe hacer para implementar definiciones fuera del repositorio principal. 😄

Si no desea incluir esto, ¿podría incluir los directorios de origen en las versiones publicadas en npm y establecer jsnext:main o module en package.json en la entrada

Dado que TypeScript ahora admite definiciones de módulos comodín, sería una solución fácil eliminar todas las mecanografías de los submódulos de plumas e incluir esto en feathers :

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

que declarará plumas y todos los módulos de plumas como tipo any , lo que al menos "lo hace funcionar" con TS listo para usar. No obtienes intellisense mejorado, pero simplemente funciona sin romper cosas en proyectos existentes y elimina el problema de las espaldas de las personas.

Yo también hago:

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

para "anular" typedefs incorrectos o incompletos mientras tanto, en lugar de abrir muchos PR pequeños y crear muchas versiones de parches que en realidad no parchean nada para los usuarios que no son TS.

Hola,
Solo quiero aclarar una duda con respecto al soporte de mecanografiado.
Según la definición de tipo actual de Servicio , todos los métodos de servicio son métodos obligatorios.

Pero según la documentación, los métodos de servicio son opcionales.
Ver

Entonces, la definición del servicio debería ser algo como a continuación, ¿no es así?

  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 sí, eso es correcto

Me quedo con mi solución de "anular typedefs de repositorios" por ahora, y tal vez algún día (jeje, cruzar los dedos) publique en feathers-mecanografiado o DefinitelyTyped, una vez que termine con mi proyecto.

Eso asegura que estaría enviando algunas definiciones probadas en batalla en al menos un proyecto de producción.

¡Gracias Coo!

El martes 9 de mayo de 2017 a las 7:42 a. M., Richard Michael Coo <
[email protected]> escribió:

@ harish2704 https://github.com/harish2704 sí, eso es correcto

Me quedo con mi solución alternativa "anular typedefs de repositorios" por ahora, y
tal vez algún día (jeje cruzó los dedos) publicar en plumas-mecanografiado o
DefinitelyTyped, una vez que termine con mi proyecto.

Eso asegura que estaría enviando algunas definiciones probadas en batalla en el
al menos un proyecto de producción.

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/feathersjs/feathers/issues/381#issuecomment-300138396 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ABezn0WGqH30NNp8-X-ckpVuk_BTQbbnks5r4FEQgaJpZM4Jears
.

@myknbani
Puede que sea un poco temprano para registrarse, pero ¿cómo te fue con las typedefs? ¿Necesitas una mano? :) Estoy buscando usar plumas en un nuevo proyecto, pero la falta de compatibilidad con TypeScript es un punto conflictivo.

falta de compatibilidad con TypeScript

No estoy seguro de a qué te refieres exactamente. Funciona totalmente. Está lejos de ser perfecto, pero funciona.

@jonlambert Estoy de acuerdo con @ j2L4e. Los existentes no son perfectos, pero solo hago el truco que mencioné aquí para cualquier cosa que no revise el tipo.

En mi humilde opinión, no vale la pena escribir paquetes como feathers-rest que solo necesitan usarse en aproximadamente dos líneas :-)

Ni siquiera puedo recordar lo que cambié, pero creo que no hay problemas para usar hooks y servicios.

@ j2L4e Quería decir que feathers no es compatible con TypeScript. Tiene razón, es posible usarlos junto con la solución alternativa que mencionó anteriormente, pero ciertamente no es 'compatible' como podemos ver en este problema.

TypeScript es parte integral de nuestro flujo de trabajo para garantizar que nuestras aplicaciones se mantengan en el futuro , por lo que pensé que valía la pena verificar si las definiciones de

También funciona sin esa solución. Hay tipificaciones disponibles en los repositorios oficiales que no necesitan demasiada manipulación. No te ofendas, pero me parece que ni siquiera lo intentaste si funciona.

Dado que ninguno en el equipo central de Feathers usa Typecript, nosotros:

1. no tengo el conocimiento adecuado para mantener correctamente las definiciones
2. No podemos perder tiempo trabajando en definiciones cuando un pequeño porcentaje de nuestra base de usuarios las “requiere”. Tenemos muchos otros elementos en los que trabajar que impactan a más personas.

Como recién llegado al marco, habría pensado que la presencia de este problema, más los comentarios anteriores, eran suficientes para asumir la falta de soporte de TS. Lo siento si esa es la conclusión incorrecta, me aseguraré de intentarlo.

Además, podría "funcionar", pero sin ningún tipo de garantía para asegurar que las definiciones de tipo se mantengan actualizadas con la API, parece que tiene el potencial de causar problemas en el futuro.

Estás bien.

Sin embargo, últimamente hubo bastantes mejoras y la finalización de la mecanografía está planificada y en proceso.

Es una gran noticia 🙂 Realmente disfruto trabajando con el marco hasta ahora y estoy emocionado de poder usarlo con TS 🎉

También funciona sin esa solución. Hay tipificaciones disponibles en los repositorios oficiales que no necesitan demasiada manipulación. No te ofendas, pero me parece que ni siquiera lo intentaste si funciona.

@ j2L4e Tienes razón. Creo que los typedefs están en un estado mucho mejor ahora. Eliminé todas mis "invalidaciones" y el único problema que queda hasta ahora son las afirmaciones ! (porque strictNullChecks ) al usar app.service(...) .

Sugeriría separar las tipificaciones para la definición de servicio (donde los métodos de servicio son todos opcionales) y la instancia de servicio (donde todos los métodos de servicio no están indefinidos). Actualmente, tuve que agregar dolorosamente ! s en todas partes, por ejemplo, await app.service('api/foos').create!([{

Tenía esto en mi solución:

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

¿Qué tal esto?

  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;

Esto le permite escribir cualquier servicio que no sea de TS mediante la construcción de un nuevo tipo, por ejemplo, para feathers-mailer:

type MailerService = CreateService<Mail>;

O un servicio (bastante inútil) que solo puede crear y eliminar:

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

Todo esto se debe al uso de funciones de selector para tener los servicios en mente (por ejemplo, app.service (s => s.mailout)) devolverá ese servicio con su tipo apropiado. Como se ve aquí:

Regresando, ¿cómo nos va? @ j2L4e post ^ ¡se ve muy bien! Me pregunto qué más se necesita hacer para ver si puedo ser de alguna ayuda.

OK, errores que estoy viendo hasta ahora:

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] El módulo '"c: / Users / George / Source / Repos / ts4 / node_modules / feathers-errors / not-found"' se resuelve en una entidad que no es un módulo y no se puede importar con esta construcción.

[2]

El argumento de tipo 'Función' no se puede asignar al parámetro de tipo 'PathParams'.
El tipo 'Función' no se puede asignar al tipo '(cadena | RegExp) []'.
Falta la propiedad 'empujar' en el tipo 'Función'.

[3]

El argumento de tipo 'Función' no se puede asignar al parámetro de tipo 'PathParams'.
El tipo 'Función' no se puede asignar al tipo '(cadena | RegExp) []'.
(alias) notFound (): Función

¿Existen soluciones alternativas?

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

Para la próxima versión, @ j2L4e ha estado haciendo un gran trabajo para pulir los mecanografiados. Estos son los pasos para probarlo y hacer una prueba beta:

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

lerna vinculará todos los paquetes y departamentos por usted. Ahora vaya a la subcarpeta ./packages/tests (donde aún no se pueden encontrar pruebas, así que lo convertí en una especie de patio de recreo) y pruebe la bondad de TS. Consulte index.ts.

Para compilar y ejecutar, ejecute npm start desde ./packages/tests

Recién comenzada la migración de Feathers 2 a 3, los archivos index.d.ts ahora faltan en los paquetes head @feathersjs . ¿Algún plan para restaurarlos?

Como se mencionó en un comentario anterior, se han movido a https://github.com/feathersjs-ecosystem/feathers-typescript/tree/buzzard-j2L4e para enviarlos a DefinitelyTyped. @ j2L4e está demasiado ocupado en este momento, por lo que alguien más debe ocuparse de esto. Por lo que entendí, se trata principalmente de obtener la aprobación de Linting y enviarlos a DefinitelyTyped. Con mucho gusto ayudaré a quien esté dispuesto a aceptar esto, pero no tengo planes de hacerlo yo mismo.

Sí, fue mucho más trabajo del que había anticipado y los comentarios de la comunidad fueron prácticamente nulos. Lo haré realidad tan pronto como tenga tiempo. Sin embargo, no demasiado pronto.

si alguien pudiera intervenir aquí, sería realmente increíble. Ahora se trata de la capa de DT, que aparte de todo funciona bien

una copia y pegado rápidos de Slack:

chicos, estoy realmente muy ocupado en este momento, por lo que la mecanografía es cualquier cosa menos la máxima prioridad. funcionan, pero DefinitelyTyped es bastante estricto en términos de reglas de borrado. Si pudieras ayudar a hacer que los mecanografiados pasen el proceso de borrado definido definitivamente, sería increíble

echa un vistazo a mi bifurcación DT aquí https://github.com/j2L4e/definitelytyped , encontrarás los paquetes de feathersjs en types/feathersjs__packagename

clonar, instalar npm y ejecutar el linter en uno de los paquetes, por ejemplo, npm run lint @feathersjs/feathers (editado)

@feathersjs/feathers ya está alineado correctamente, por lo que puede usarlo como referencia. (editado)

Las definiciones de TypeScript están esperando que se agreguen a DefinitelyTyped en https://github.com/DefinitelyTyped/DefinitelyTyped/pull/22805

¡Ahora se puede acceder a las definiciones a través de NPM!

Sí, instale @types/feathersjs__package para el paquete @feathersjs/package y proporcione sus comentarios, por favor.

@erikma ¡ gracias por tu apoyo!

@ j2L4e ¡ Gracias por tu trabajo! Pero, ¿está seguro de haber exportado todas las funciones @featherjs/express ? No puedo encontrar ninguna mención de rest, json, notFound y urlencoded en su archivo de definiciones de mecanografiado.

tienes razón, esos faltan.

agregue un archivo typings.d.ts por ahora con:

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

no tengo idea de dónde debería ir urlencoded.

urlencoded y json se han agregado a express en la última versión secundaria. ¿Aún no se han actualizado las mecanografías de express ?

¿Eso es expreso o feathersjs / express?

Se acaba de volver a exportar desde 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

Entonces, ¿debería poder hacer Import { urlencoded, json } from '@feathersjs/express' ? ¿O lo obtendría de los original exportados?

Todo lo que se exporta desde require('express') es reexportado por @feathersjs/express : https://github.com/feathersjs/express/blob/master/lib/index.js#L82

Además, ¿sabes cómo lidiar con los channel.ts con definiciones que están bien?
Lamento haberte planteado todos los problemas en tan poco tiempo.

Importar @ tipos / feathersjs__socket-commons

Importar? No lo entiendo

Lo siento, debería decir "Importar @ feathersjs / socket-commons". Necesitas instalar sus tipos.

Si instalo @types/feathersjs__feathers mi app.channel no funciona. Si luego agrego @types/feathersjs__socket-commons mi app.on deja de funcionar.

se solucionará a través de DefinitelyTyped / DefinitelyTyped # 23195

por favor, resuelva cualquier problema adicional aquí: https://github.com/feathersjs-ecosystem/feathers-typescript/issues

El seguimiento de problemas para las definiciones de TS es un poco confuso. Está dirigiendo a la gente al repositorio de feathers-mecanografiado, pero mencionó _ "Este repositorio ahora es obsoleto" _. Si no va a mantener las definiciones en los repositorios respectivos y, en su lugar, utilizará DT, creo que tendría más sentido mantener los problemas en el repositorio de DT también, ya que es presumiblemente donde se originarán y fusionarán los RP.

Creo que decidimos intentarlo aquí. He estado recibiendo solicitudes a través de varios canales y ordenar a las personas que vayan allí fue una forma rápida de centralizar eso. Personalmente, no me importa a dónde va siempre que sea un lugar

¿Hay alguna razón por la que no podamos usar feathers.services.dogs lugar de feathers.service('dogs') ?

Si. feathers.service('dogs') llama a defaultService (que crea una instancia del servicio en el cliente) y elimina las barras de los nombres de los servicios.

Las definiciones de TypeScript ahora están en DefinitelyTyped .

Dirija cualquier problema o pregunta a https://github.com/feathersjs-ecosystem/feathers-typescript/issues