Ah, acabei de ver https: //github.com/feathersjs/feathers/issues/64 ... Mas talvez deixe isso aberto? Então, algumas pessoas vão oferecer ajuda?

A melhor maneira de avançar seria iniciar um repositório com algumas definições básicas de Typescript (em # 64 eu postei algumas dicas sobre por onde começar) e continuar
discussão lá.

Posso deixar essa edição em aberto por mais um mês ou dois, mas a outra edição ficou aberta por quase um ano e ninguém a levantou. Conforme mencionado lá, a equipe principal atual não está usando Typescript ou Angular, portanto, não está realmente em nosso radar (e preferiríamos apenas manter os problemas em aberto se houver uma chance de que sejam resolvidos em um futuro previsível).

Acho que @harangue está trabalhando em algumas definições básicas. Talvez possamos mudar a discussão que tivemos no Slack sobre onde eles iriam morar aqui?

certo! Se necessário, feche este problema, vá em frente.

Será muito bom se o texto digitado puder ser suportado ... como posso ajudar?

@rollymaduk Fiz alguns progressos decentes nas definições de Feathers, mas ainda temos que estabelecer a melhor maneira de distribuí-las (e as coisas estão um pouco transitórias com o TypeScript 2 prestes a ser lançado). Se você gostaria de ter algo para trabalhar até então, pode ver a essência em que trabalhei.

@harangue trabalho muito bom, de fato parece bastante pronto .. Eu acho que algumas áreas que podem exigir alguma atenção estariam incorporando alguns plugins básicos como autenticação, provedores (rest, socke.io, primus) e alguns dos adaptadores db, certo? por favor, o que você quer dizer com a melhor forma de distribuí-los?

Não tenho certeza se discutimos isso ainda, mas acho que não haverá problema se distribuirmos as definições de Typescript no repositório principal, desde que haja alguém para mantê-las atualizadas. Então, uma vez que eles estejam prontos, podemos torná-lo parte de uma versão 2.1 do Feathers (que eu acho que também pode vir com alguns avisos de que, por exemplo, callbacks em serviços serão descontinuados na v3).

Existe algum fork de generator-feathers para TypeScript? Interessado em trabalhar em uma bifurcação TS do gerador?

editar: Eu bifurquei o gerador e enviei um primeiro commit.

Portanto, @harangue praticamente implementou um grande conjunto de definições do Feathers Typescript já em https://gist.github.com/harangue/9d4ed79118e2656f5e3d2d699296ed36 , só precisamos de alguém para revisar e potencialmente finalizá-las e enviá-las ao repositório de definições do TypeScript.

Vou fazer essa parte do lançamento do Auk que vai pousar antes do final do ano. Se ninguém se manifestar até então, esse problema será resolvido para sempre e não haverá suporte oficial do TypeScript ou discussão adicional sobre isso, a não ser uma solicitação de pull para a coisa toda.

Se sua qualidade for boa, você deve considerar agrupar as definições com Feathers. Eu acho que muitas pessoas gostariam de evitar o uso de um gerenciador de pacotes secundário tanto quanto possível.

Eles seriam instaláveis ​​por meio de npm i @types/feathers . Você não precisa mais de coisas como typings .

Pensei que você apenas os adicionasse a https://github.com/DefinitelyTyped/DefinitelyTyped. Qualquer que seja a maneira normal de fazer isso. Se os adicionarmos ao repositório principal, os outros repositórios de plug-ins provavelmente precisarão de definições adicionadas de acordo.

Do FAQ DefinitelyTyped:

O branch types-2.0 é publicado automaticamente no escopo @types no NPM graças ao types-publisher. Isso geralmente acontece dentro de uma hora após a fusão das alterações.

Não sabia disso. Portanto, adicioná-los ao DefinitelyTyped seria suficiente.

Ah, JS. Você fica fora por um mês ou dois e o ecossistema evolui: sorria:

Lamento que tenha havido silêncio no rádio sobre isso da minha parte por tanto tempo. Acabei de lançar outra revisão da essência hoje que corrige alguns problemas que tive com as datilografias antigas. Finalmente, posso começar a trabalhar com o Feathers novamente em um de meus projetos e espero adicionar pelo menos tipificações para os módulos que estou usando.

A definição que existe na essência está pronta para ser submetida a Definitely Typed, exceto por 1) testes de tipificação (só é necessário extrair alguns exemplos dos documentos do Feathers) e 2) anotações JS Doc (o que seria bom para o intellisense, mas são não essencial).

Tecnicamente, as tipificações de ganchos devem ser extraídas de ganchos de penas também. Estender as tipificações aqui fica um pouco confuso, entretanto, já que uberproto tem alguns padrões de mixin que são um pouco desafiadores para replicar com tipos estáticos.

É bom ter você de volta @harangue. Acho que podemos deixar as tipificações de ganchos aqui por enquanto, já que estamos planejando fazer os ganchos parte do núcleo (consulte # 408). Além disso, as digitações podem precisar ser atualizadas com o novo método .hooks , conforme descrito em https://blog.feathersjs.com/feathers-application-and-error-hooks-7a5982e70024 (ainda não documentado, trabalhando nisso :).

@harangue quando você acha que enviará seus tipos para definitivamente digitados?

Olá a todos, é muito bom ver as defs do TypeScript chegando. @harangue , qual é a sua recomendação para importar penas em conjunto com os defs em sua essência? Eles não estão exportando namespaces que correspondem às bibliotecas feathers , então import ... from 'feathers' gera um erro.

Ei @subvertallchris , você pode usar

import * as feathers from 'feathers';`

ou

import feathers = require('feathers');

eles são equivalentes. :) Bem quando eu pensei que estava tendo tempo para Feathers novamente, me envolvi com outras coisas, mas espero ter essas definições completamente desenvolvidas no ano novo.

@ j2L4e Sua bifurcação do gerador de TS parece estar desligando? Alguma novidade sobre isso? Além disso, @harangue , como você está feathers generate --ts para fazer o cli funcionar bem com o texto datilografado ou documentos. Avise.

Era difícil de manter, funcionava corretamente apenas para mysql e autenticação local, e o gerador de penas estará obsoleto logo de qualquer maneira. Então eu desisti.

Esperando ansiosamente pelo lançamento do novo cli

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

@ j2L4e Sua bifurcação do gerador de TS parece estar desligando? Alguma novidade sobre isso?
Além disso, @harangue , como você está
pousar e estou feliz em ajudar na implementação de arquivos de definição de TS, um
garfo com uma bandeira feathers generate --ts para fazer o cli brincar com
bem datilografado ou docs. Avise.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/feathersjs/feathers/issues/381#issuecomment -267966376

Alguém ainda está trabalhando nesse problema? Eu gostaria muito de usar este projeto com Typescript

Olá pessoal

Fico feliz em dizer: _Está quase pronto._ 😄
Eu fiz muitos garfos em FeatherjsOrg e escrevo definições por repo. E você pode ver esses exemplos usando penasjs com as melhores definições de datilografia

Feathers + Nodejs + Typescript
FeathersClient + Aurelia + Typescript

[sim, é compatível com ESNext, Commonjs, AMD e módulos globais para partes do cliente]

O exemplo de aurelia fornece dicas de como trabalhar com angular2. Esses repositórios têm muitos detalhes de como o typescript pode ser útil para fornecer uma documentação ao vivo sobre

Farei PRs em breve, mas vocês podem ver, tirar dúvidas e me dar feedbacks. 👌?

Bifurcação com definições:

• ganchos de penas
• penas primus
• penas-socketio
• descanso de penas
• cliente de autenticação de penas
• cliente-penas
• penas

Tive um pouco de trabalho, mas adoro penas e texto datilografado

são todos links relativos

Consertei os links.

@AbraaoAlves Isso está ótimo, obrigado! Eu estava prestes a escrever um comentário mal-humorado e encerrar o problema e estou feliz que você comentou primeiro 😉 Estou ansioso para ver as solicitações de pull!

Bom homem @AbraaoAlves !

@AbraaoAlves Só queria agradecer muito, é uma grande ajuda para mim! Eu não posso acreditar que você veio no último momento

@AbraaoAlves Estou tendo problemas para usar qualquer uma de suas definições. Quando eu instalo os pacotes no 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"`

Então, quando tento usá-lo em um arquivo TypeScript, como:

import * as feathers from "feathers"

ele passa na compilação, mas não funciona corretamente.

Eles instalam apenas as definições de tipo e não a fonte. Também parece que o descanso de penas não exporta uma função para o texto datilografado reconhecer
rest()' as a valid command for app.use(rest());

Além disso, mais um problema, parece que app.use não aceita mais argumentos como
this.app.use(bodyParser.json());

e deve ser usado como

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

@Chrisdf Corrijo isso com arquivos tgz em package.json, clone agora e tente instalar novamente.

Mais detalhes sobre este: problema

@AbraaoAlves existe uma razão para você não @types do NPM e removeria a necessidade de a equipe principal manter as definições atualizadas como parte de um lançamento.

@AbraaoAlves A propósito, por que as definições não foram confirmadas, mas postadas como lançamento do tarball? Eles estariam mais disponíveis por typings desta forma. Eu aprecio muito este esforço e concordo que seria benéfico trazer as definições para a comunidade de forma utilizável. DefinitelyTyped será uma boa jogada.

Reescrevi as @AbraaoAlves e @harangue. Enviarei essas digitações para o DefinitelyTyped em breve.

Legal. Há algo que podemos / devemos fazer para isso? Caso contrário, presumo que, uma vez que tudo tenha sido incluído no DefinitelyTyped, podemos encerrar este problema.

deve ser incluído neste repositório e o pacote.json
(pelo menos esse seria o melhor caso)

Exemplo: arquivo incluído package.json

Olá a todos o /
Obrigado pela paciência e feedbacks.

@stevehipwell e @daffl : Eu acredito que os arquivos de definições de typescript são como uma documentação, uma documentação ao vivo. Mas a documentação que não está alinhada com o código é pior do que nenhuma documentação!

Eu conheço a iniciativa @types e DefinitlyTyped, e isso é importante para a comunidade de typescript no momento em que os caras do javascript não se preocupem com as definições.

Hoje, se tivermos a oportunidade de manter os dois em um único local, em um único release, os erros de comunicação terão uma incidência muito menor e teremos definições de oficiais por release!

Exemplos de projetos javascript mantêm suas próprias definições: Aurelia , Preact , ...

Se todos concordarem, aqui estão os links PullRequest:

• penas
• cliente de autenticação de penas
• ganchos de penas
• penas primus
• descanso de penas
• penas-socketio
• autenticação de penas
• penas-cliente (enviarei depois que esses outros resolverem)

Há muito mais tarefas a fazer, como testes digitados, automação, ... mas isso está apenas começando.

Texto datilografado S2 FeathersJS!

Olá a todos,

Concordo com @AbraaoAlves que a solução ideal é incluir os arquivos de definição TypeScript diretamente nos pacotes, porém o pior cenário é incluir arquivos de definição que acabam ficando desatualizados. É por isso que eu estava sugerindo que DefinitlyTyped fosse usado para manter as definições como uma solução intermediária que está de acordo com a mentalidade do Node de quebrar coisas complexas em componentes menores e mais fáceis de gerenciar.

Para garantir que as definições sejam mantidas em sincronia com os lançamentos do projeto, seria necessário haver mais transparência por parte da equipe de penas. Até agora, enquanto escrevia minhas próprias definições, não tenho certeza de qual é o estado atual da versão; o blog não é atualizado e há vários codinomes (v3, auk, buzzard ??) que não significam nada.

@AbraaoAlves - Suas definições parecem boas, mas pelo que posso ver, há áreas ausentes, como os métodos hooks() . Você estaria interessado em adicioná-los?

Olá @stevehipwell ,

Obrigado pelo feedback. E aqui estão minhas respostas sobre:

No entanto, o pior cenário é incluir arquivos de definição que acabam ficando desatualizados ...
Para garantir que as definições sejam mantidas em sincronia com os lançamentos do projeto, seria necessário haver mais transparência por parte da equipe de penas

Sim, o problema de sincronização é um problema real, mas pode ser corrigido com testes.
Eu sugiro fazer testes em texto digitado: # 508

Se concorda ou não com esta solução leve a sua opinião aí.

Estou realmente motivado para fazer o featherjs amigável, sem mudanças disruptivas, é claro.
Temos muito mais trabalho a fazer, como hooks() métodos, mas agora podemos construir isso juntos.

Se você encontrar um bug ou perder uma definição, crie um problema.

@AbraaoAlves parece que há o desejo de manter as definições atualizadas e estou mais do que feliz em ajudar. Presumo que você queira o aumento de bugs nos repositórios principais para definições ausentes, uma vez que suas solicitações de mesclagem sejam concluídas.

@stevehipwell Sim, é esse o ponto.

Qual é o problema com o cronograma de lançamento e o que podemos fazer para torná-lo melhor? Os marcos aqui ainda são aproximadamente o que estamos planejando:

• A próxima versão é Auk, que é um código completo com o gerador sendo finalizado e os documentos sendo atualizados. As mudanças mais recentes estão na autenticação por penas v1.0.0
• O lançamento seguinte é o Buzzard, que incluirá as seguintes mudanças importantes (que eu às vezes me refiro como v3 - e provavelmente não deveria 😉):
  
  
  
  • Independência da estrutura (https://github.com/feathersjs/feathers/milestone/9) (e com isso uma estrutura unificada para o cliente )
  
  
  • Ganchos no núcleo (https://github.com/feathersjs/feathers/issues/408)
  
  
  • Filtragem de eventos baseada em canal (https://github.com/feathersjs/feathers/issues/388#issuecomment-239564856)
  
  

Qual deve ser o processo para atualizar as definições depois que esses recursos forem implantados?

As definições de texto datilografado são como .h (cabeçalho) em C ++. Se você tiver um cabeçalho que não responde ao seu módulo, podem ocorrer problemas no tempo de execução, como uma documentação não alinhada com a versão do código usado.

Portanto, acredito que as definições devem ser incluídas em cada marco que requer uma mudança na API, por exemplo: mover o método para outro repositório ou adicionar um novo parâmetro a um método,…

Vou mudar a definição de autenticação de penas, removendo ganchos para projetos específicos para alinhar com v1.
A questão agora é: as definições devem ser incluídas nesta versão atual do FeathersJS?

@AbraaoAlves Acho que sim. Posso fazer um lançamento menor para todos os seus PRs e podemos iterar a partir daí. A única coisa que ainda estou pensando é o # 508, mas irei comentar sobre isso.

Tenho enfrentado dois problemas com as digitações acima.

socketio não quer trabalhar.

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

E o descanso requer um manipulador, mesmo que seu penas-cli produza sem argumentos.

.configure (rest ()) // Erro ao declarar a função rest (handler: Function): Function;
.configure (socketio ())

node -v
v6.6.0

npm -v
3.10.5

tsc -v
2.1.6

Seria interessante também mostrar como usar "penas ()" como um módulo, pois esse é o ponto de entrada.
Posso converter todos os outros serviços / middleware gerados, mas deve haver uma maneira mais agradável de encapsular penas () em um construtor () {}. (Eu sou novo em penas, posso estar fazendo errado também ...)

Podemos obter as definições como uma versão de patch? Este nível de mudança se encaixaria perfeitamente em uma versão de patch; sem alterações significativas e sem novas funcionalidades. Mesmo digitações parciais ou incorretas são melhores do que nenhuma digitação.

Assim que tivermos uma versão, temos um ponto de partida de trabalho que podemos usar para melhorar a digitação.

Se isso continuar a estagnar e terei que seguir a rota DefinitelyTyped para minhas definições. Não quero ter que fazer isso e fico feliz em ajudar com definições nos repos.

Eu tinha uma pergunta para @AbraaoAlves no # 508 mas ainda não recebi uma resposta. Se fizermos os lançamentos, precisamos de alguém disponível para resolver rapidamente quaisquer problemas que possam surgir (especialmente porque o pior caso pode quebrar aplicativos existentes que estão usando TypeScript). Podemos coordenar no Slack por um bom momento para fazer e verificar o lançamento (podemos começar com um minor.pre)?

Lançado em versões menores para cada módulo 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

Em primeiro lugar, obrigado a todos que participaram dessa discussão e principalmente a quem contribuiu. Lançamos versões secundárias com as definições de TypeScript para muitos repositórios Feathers, mas causou uma série de problemas - e lançamentos não programados para módulos bastante estáveis, fazendo com que os usuários atualizassem até mesmo sem usar TypeScript - sem nenhuma maneira para o núcleo equipe (onde ninguém usa TypeScript) para corrigi-los de forma confiável.

Minha principal lição de toda a discussão do Feathers + TypeScript é que parece ser muito difícil criar e manter tipificações para um projeto JavaScript existente (para mim, isso não fala muito bem para as afirmações de interoperabilidade do TypeScript). Uma vez que a equipe principal não está usando o TypeScript, nossa única opção no futuro ao liberar as alterações importantes da API é remover quaisquer definições do TypeScript desatualizadas.

Seria ótimo ter definições TypeScript atualizadas para os módulos Feathers no repositório DefinitelyTyped e faremos tudo que pudermos para ajudar a fazer isso acontecer, mas com o tempo limitado que temos disponível, não podemos adicionar a sobrecarga de apoiar e manter algo que não usamos pessoalmente em nossos próprios repositórios.

para mim, isso não fala muito bem para as afirmações do TypeScript de interoperabilidade

Feathers é perfeitamente utilizável sem tipificações específicas, é simplesmente JS sem o intellisense e os tipos. Especialmente o sistema de plugins de penas com seu uso pesado de mixins torna a criação de tipificações difícil, porque essa é uma maneira muito não tipificada de fazer as coisas. Eu sou um usuário datilografado regular (e um fã disso), mas voltei para ES6 para coisas de penas do lado do servidor por enquanto.
Manter os tipos separadamente parece ser a maneira mais adequada aqui, com ninguém na equipe principal usando realmente a digitação.

Feathers seria a estrutura preferida do lado do servidor para Angular se funcionasse bem com o TypeScript. Apenas dizendo' :-). Estou seguindo em frente por enquanto.

@ j2L4e Acho que será mais fácil para o próximo lançamento, uma vez que a maioria das coisas que agora estão mixadas pelos plug-ins farão parte do núcleo. Não tenho certeza se isso resolverá o problema geral de obter ajuda confiável com isso.

@rjsteinert O que está lá no momento deve funcionar principalmente, mas sim, como em qualquer projeto de código aberto, você tem a chance de tentar ajudar ou seguir em frente.

você tem a chance de tentar ajudar ou seguir em frente.

Eu sou um daqueles caras novos no Angular, programador JS de longa data, percebendo o quanto o TS torna a vida grande e percebendo que se não trabalharmos com ele no lado do servidor, a equipe vai xingar e fantasiar sobre a reescrita isso todos os dias durante os próximos dois anos. Afinal de contas, podemos ir com penas devido à falta de opções e, nesse caso, definitivamente ajudar a manter a digitação atualizada. Apenas dizendo, entretanto, que quando estamos passando e vemos "nossa única escolha seguir em frente ao liberar as alterações de API de interrupção é remover quaisquer definições TypeScript desatualizadas", olhamos em outro lugar. Não leve a mal, eu entendo a necessidade de apoiar projetos existentes, vocês não têm sorte o suficiente (posso estar condenado) de estar na minha situação em que estamos reescrevendo.

@rjsteinert o que o TypeScript oferece que o torna tão valioso para você? (pergunta honesta) Depois que meu conjunto atual de trabalhos do Feathers estiver concluído, minha curiosidade é quase aguçada o suficiente pelo interesse nele para dar uma olhada no TypeScript, eu mesmo. Eu sei que ajuda com autocomplete / CodeSense, mas a API Feathers é tão pequena que não consigo imaginá-la TÃO útil. Por favor, perdoe minha ignorância. ;)

autocomplete/CodeSense é um bom subproduto, mas geralmente estou no Vim, então não entendo as guloseimas. A grande mudança que vejo até agora é a padronização de como tornar óbvio como usar algumas funções ou objetos de contribuição. Procurando nas bibliotecas do NPM, encontro muitas bibliotecas usando suas próprias soluções criativas e próprias para tornar óbvio e utilizável o que uma linguagem digitada dinamicamente não diz a você. TS economiza uma tonelada de clichês de verificação de tipo você mesmo quando você está escrevendo código e torna mais fácil entender rapidamente como usar o código de outra pessoa. Hoje em dia, tendo a pensar que estou cansado de escrever um JS que é o meu próprio estilo e realmente não quero ler o README de alguém toda vez que uso uma biblioteca externa.

Eu concordo com @rjsteinert , trabalho com JavaScript há mais de 15 anos e sou um grande fã de lembrar de todas as APIs. Até codificava com o Notepad sem cor. Eu costumava trabalhar em uma equipe na Microsoft onde todo o site era escrito apenas em JavaScript. Posso dizer que quando seu site atingir mais de 50 programadores, tudo ficará uma bagunça. Não só você tem que seguir mais convenções, mas seu site trava apenas no tempo de execução.

Se você está escrevendo nesta postagem do GitHub e usando o FeatherJS, provavelmente é um desenvolvedor de JavaScript ávido. Se você for um dos desenvolvedores do FeatherJS, não verá por que usar o TypeScript para você mesmo. Você não precisa de nenhuma ferramenta especial ou ajuda do TypeScript. Você é um unicórnio JavaScript.
Eu era extremamente contra o TypeScript (especialmente porque fomos forçados a usá-lo com a versão Alpha 1.1), mas ao longo dos anos, aprendi a apreciá-lo e não posso viver sem ele. Os colegas com quem você trabalhará não terão tanto conhecimento quanto você em JavaScript. Eles virão de diferentes origens e reclamarão de como o JavaScript é uma merda.

A linguagem TypeScript cresceu muito com o feedback da comunidade desde então.
Você não pode construir um site enorme sem ferramentas e uma grande equipe. Como @rjsteinert disse, a equipe começará a usar o TypeScript para o lado do cliente, depois de um tempo, eles ficarão extremamente infelizes em usar o lado do servidor. Esforços serão feitos para mudar a infraestrutura para atender aos requisitos da empresa, então as penas serão postas de lado.

Dê uma olhada nas linguagens mais populares usadas na web: PHP, NodeJS, Ruby, C #, Java ... Algumas delas são digitadas, outras não. Trabalhei com todas essas linguagens e posso dizer que depois de todos esses anos, não quero voltar a uma linguagem "descobrir-erro-no-tempo de execução". Todos eles têm seu charme, prós e contras. Em uma equipe grande, eu sempre sugeriria ir com algo um pouco mais forte e digitado.

O exemplo mais recente de alguém usando um SDK de PHP que escrevi. Se você tem um método que aceita um "número grande" com 100 dígitos, você o trata como uma string. O desenvolvedor iniciante abrirá um bug perguntando por que, quando chamar setValue(123456789123...) não funciona, ele parece travar muito baixo no NodeJS ou em um método substr . Agora, o desenvolvedor intermediário irá verificar sua documentação e descobrir que deveria ser uma string. Imagine que, ao digitar, você força uma string a ser inserida enquanto digita ou compila. Então o desenvolvedor não precisa ler a documentação específica nem abrir um bug.

Pesquisei um pouco sobre qual framework usar para meu novo projeto Angular2 + NodeJS, e FeatherJS parecia ser exatamente o que eu precisava. No entanto, se outro projeto de servidor saiu hoje e disse "Eu suporte oficialmente TypeScript fora da caixa", vou mudar imediatamente.

Obrigado pela contribuição de todos sobre este assunto. Tem havido uma discussão muito boa, mas sinto que está começando a se voltar para os méritos da datilografia e não é exatamente disso que se trata. A equipe principal discutiu e não vamos oferecer suporte a definições de Typecript, pois elas não são essenciais para trabalhar com Feathers e reduzirão a taxa na qual podemos evoluir o núcleo do Feathers. Já temos muitas coisas para atualizar ao fazer um lançamento. Estamos tentando reduzir as dependências para lançar versões mais cedo, ao passo que adicionar definições de Typescript traria mais trabalho. Uma vez que ninguém na equipe principal do Feathers usa o Typecript, nós:

1. não tenho o conhecimento adequado para manter as definições de maneira adequada
2. não podemos perder tempo trabalhando em definições quando uma pequena porcentagem de nossa base de usuários as “exige”. Temos muitos outros itens para trabalhar para impactar mais pessoas.

Para aqueles que desejam criar / manter definições oficiais, ficaríamos felizes em criar um link para eles na seção de ecossistema dos novos documentos, mas porque não os usamos nós mesmos e as definições de TS não são necessárias ao usar Feathers e são mais de uma preferência pessoal não vamos mantê-los. Vamos retirá- los dos @daffl vai colocá-los em https://github.com/feathersjs/feathers-typescript. Se @jsgoupil , @rjsteinert , @AbraaoAlves ou qualquer outra pessoa interessada quiser manter o repo, ficaremos felizes em conceder acesso e / ou transferir o repo. Achamos que isso tornará mais fácil manter as definições atualizadas e enviar ao DefinitelyTyped (reconhecidamente, não sei muito sobre esse processo).

Deixaremos esse problema aberto para discussão, mas bloquearemos o thread se continuar discutindo os méritos do Typescript em oposição ao que precisa ser feito para implementar as definições fora do repositório principal. 😄

se não quiser incluir isso, você poderia incluir os diretórios de origem nas versões publicadas para npm e definir jsnext:main ou module em package.json para a entrada

Como o TypeScript agora oferece suporte a definições de módulo curinga, seria uma solução fácil remover todas as digitações de submódulos penas e incluí-lo em feathers :

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

que irá declarar penas e todos os módulos penas - qualquer que seja o tipo any , que pelo menos "faz funcionar" com o TS pronto para usar. Você não obtém o intellisense aprimorado, mas ele simplesmente funciona sem quebrar coisas em projetos existentes e tira o problema das costas das pessoas.

Eu também faço:

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

para "sobrescrever" typedefs incorretos ou incompletos por enquanto, ao invés de abrir muitos PRs pequenos e criar muitas versões de patch que não corrigem nada para usuários não-TS.

Oi,
Eu só quero esclarecer uma dúvida a respeito do suporte à digitação.
De acordo com a definição de tipo atual de Serviço , todos os métodos de serviço são métodos obrigatórios.

Mas, de acordo com a documentação, os métodos de serviço são opcionais.
Ver

Portanto, a definição de serviço deve ser algo como abaixo, não é?

  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 sim está certo

Estou mantendo minha solução alternativa "substituir repositório de typedefs" por agora, e talvez um dia (hehe dedos cruzados) publicar em penas datilografadas ou DefinitelyTyped, assim que terminar meu projeto.

Isso garante que eu estaria enviando algumas definições testadas em batalha em pelo menos um projeto de produção.

Obrigado Coo!

Na terça-feira, 9 de maio de 2017 às 7h42, Richard Michael Coo <
notificaçõ[email protected]> escreveu:

@ harish2704 https://github.com/harish2704 sim, está certo

Vou continuar com a minha solução alternativa "substituir repo typedefs" por agora, e
talvez algum dia (hehe dedos cruzados) publicar em penas datilografadas ou
Definitivamente digitado, assim que terminar meu projeto.

Isso garante que eu estaria enviando algumas definições testadas em batalha em às
pelo menos um projeto de produção.

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/feathersjs/feathers/issues/381#issuecomment-300138396 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ABezn0WGqH30NNp8-X-ckpVuk_BTQbbnks5r4FEQgaJpZM4Jears
.

@myknbani
Pode ser um pouco cedo para fazer o check-in - mas como você se saiu com os typedefs? Você precisa de uma mão em tudo? :) Estou procurando usar penas em um novo projeto, mas a falta de suporte TypeScript é um pouco um obstáculo.

falta de suporte TypeScript

Não tenho certeza do que você quer dizer exatamente. Funciona totalmente. Está longe de ser perfeito, mas funciona.

@jonlambert Eu concordo com @ j2L4e. Os existentes não são perfeitos, mas eu apenas faço o truque que mencionei aqui para qualquer coisa que não seja verificada.

IMHO, pacotes como feathers-rest que só precisam ser usados ​​em cerca de duas linhas não valem a pena serem digitados :-)

Não consigo nem lembrar o que mudei, mas acho que não há problemas no uso de ganchos e serviços.

@ j2L4e Eu queria dizer que feathers não suporta TypeScript. Você está certo, é possível usá-los junto com a solução alternativa que você mencionou acima, mas certamente não é 'compatível', como podemos ver neste problema!

O TypeScript é parte integrante do nosso fluxo de trabalho para garantir que nossos aplicativos sejam sustentáveis ​​ao longo da linha, então achei que valia a pena verificar se as definições de @myknbani estavam disponíveis. Não se preocupe! 🙂

Ele também funciona sem essa solução alternativa. Existem tipificações disponíveis nos repositórios oficiais que não precisam de muita manipulação. Sem ofensa, mas me parece que você nem tentou se dar certo.

Uma vez que ninguém na equipe principal do Feathers usa o Typecript, nós:

1. não tenho o conhecimento adequado para manter as definições de maneira adequada
2. não podemos perder tempo trabalhando em definições quando uma pequena porcentagem de nossa base de usuários as “exige”. Temos muitos outros itens para trabalhar para impactar mais pessoas.

Como um novato no framework, eu teria pensado que a presença desse problema, além dos comentários acima, eram suficientes para supor falta de suporte ao TS. Desculpe se essa é a conclusão errada, com certeza vou tentar.

Além disso, pode "funcionar", mas sem qualquer forma de garantia para garantir que as definições de tipo permaneçam atualizadas com a API, parece que tem o potencial de causar problemas no futuro.

Você tem razão.

No entanto, houve algumas melhorias recentemente e a conclusão das digitações está planejada e em construção.

Ótima notícia 🙂 Estou gostando muito de trabalhar com o framework até agora e estou animado para poder usá-lo com o TS 🎉

Ele também funciona sem essa solução alternativa. Existem tipificações disponíveis nos repositórios oficiais que não precisam de muita manipulação. Sem ofensa, mas me parece que você nem tentou se dar certo.

@ j2L4e Você está certo. Acho que os typedefs estão em um estado muito melhor agora. Excluí todas as minhas "substituições" e o único problema restante até agora são as ! asserções (coz de strictNullChecks ) ao usar app.service(...) .

Eu sugeriria separar tipificações para definição de serviço (onde os métodos de serviço são opcionais) e instância de serviço (onde todos os métodos de serviço não são indefinidos). Atualmente, eu tive que adicionar dolorosamente ! s em todos os lugares, por exemplo, await app.service('api/foos').create!([{

Eu tive isso em minha solução alternativa:

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 tal isso:

  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;

Isso permite que você digite qualquer serviço não-TS, construindo um novo tipo, por exemplo, para correio de penas:

type MailerService = CreateService<Mail>;

Ou um serviço (totalmente inútil) que só pode criar e excluir:

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

Isso tudo com o uso de funções de seletor para obter serviços em mente (por exemplo, app.service (s => s.mailout)) retornará esse serviço com seu tipo apropriado. Como pode ser visto aqui:

Só checando de novo, como estamos indo? @ post

OK, erros que estou vendo até agora:

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] Módulo '"c: / Users / George / Source / Repos / ts4 / node_modules / feather-errors / not-found"' resolve para uma entidade não-módulo e não pode ser importado usando esta construção.

[2]

O argumento do tipo 'Função' não pode ser atribuído ao parâmetro do tipo 'PathParams'.
O tipo 'Função' não pode ser atribuído ao tipo '(string | RegExp) []'.
A propriedade 'push' está ausente no tipo 'Função'.

[3]

O argumento do tipo 'Função' não pode ser atribuído ao parâmetro do tipo 'PathParams'.
O tipo 'Função' não pode ser atribuído ao tipo '(string | RegExp) []'.
(alias) notFound (): Função

Existem soluções alternativas?

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

Para a próxima versão, @ j2L4e tem feito um ótimo trabalho no polimento das digitações. Aqui estão as etapas para experimentá-lo e fazer o teste beta:

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

lerna irá vincular todos os pacotes e departamentos para você. Agora vá para a subpasta ./packages/tests (onde nenhum teste pode ser encontrado ainda, então eu fiz uma espécie de playground) e experimente a bondade do TS! Verifique index.ts.

Para compilar e executar, execute npm start de ./packages/tests

Acabei de iniciar a migração do Feathers 2 para o 3, os arquivos index.d.ts agora estão faltando nos pacotes @feathersjs principais. Algum plano para restaurá-los?

Conforme mencionado em um comentário acima, eles foram movidos para https://github.com/feathersjs-ecosystem/feathers-typescript/tree/buzzard-j2L4e para serem enviados para DefinitelyTyped. @ j2L4e está muito ocupado agora, então cabe a outra pessoa

Sim, deu muito mais trabalho do que eu esperava e o feedback da comunidade foi praticamente zero. Eu farei isso acontecer assim que eu encontrar tempo. Mas não tão cedo.

se alguém parasse aqui, seria realmente incrível. É tudo sobre o DT linting agora, que apesar de tudo funcionar bem

um rápido copiar e colar do Slack:

Pessoal, estou realmente muito ocupado no momento, então as digitações são tudo menos prioridade. eles funcionam, mas DefinitelyTyped é bastante rígido em termos de regras de linting. se você pudesse ajudar a fazer as digitações passarem no processo de linting definitivamente tipado, isso seria incrível

verifique meu DT fork aqui https://github.com/j2L4e/definitelytyped , você encontrará os pacotes featherjs em types/feathersjs__packagename

clone, npm instale e execute o linter em um dos pacotes, por exemplo, npm run lint @feathersjs/feathers (editado)

@feathersjs/feathers já está lintando corretamente, então você pode usá-lo como uma referência. (editado)

As definições de TypeScript estão aguardando revisão para serem adicionadas ao DefinitelyTyped em https://github.com/DefinitelyTyped/DefinitelyTyped/pull/22805

As definições agora estão acessíveis via NPM!

Sim, instale @types/feathersjs__package para o pacote @feathersjs/package e forneça alguns comentários, por favor!

@erikma obrigado pelo seu apoio!

@ j2L4e Obrigado pelo seu trabalho! Mas tem certeza de que exportou todas as funções @featherjs/express ? Não consigo encontrar nenhuma menção de rest, json, notFound e urlencoded em seu arquivo de definições de typescript.

você está certo, esses estão faltando.

adicione um arquivo typings.d.ts por enquanto com:

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

nenhuma ideia para onde deve ir urlencoded.

urlencoded e json foram adicionados a express na última versão secundária. As tipificações de express ainda não foram atualizadas?

Isso é expresso ou penas / expresso?

É apenas reexportado do 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

Então você deve ser capaz de fazer Import { urlencoded, json } from '@feathersjs/express' ? Ou você o obteria do original exportado?

Tudo o que é exportado de require('express') é reexportado por @feathersjs/express : https://github.com/feathersjs/express/blob/master/lib/index.js#L82

Além disso, você sabe como lidar com channels.ts com definições adequadas?
Lamento lançar todos os problemas para você em tão pouco tempo.

Importar @ typesjs__socket-commons

Importar? eu não entendo

Desculpe, na verdade deveria dizer 'Import @ penasjs / socket-commons'. Você precisa instalar seus tipos.

Se eu instalar @types/feathersjs__feathers meu app.channel não funcionará. Se eu adicionar @types/feathersjs__socket-commons meu app.on para de funcionar.

será corrigido via DefinitelyTyped / DefinitelyTyped # 23195

por favor, resolva quaisquer questões adicionais aqui: https://github.com/feathersjs-ecosystem/feathers-typescript/issues

O rastreamento de problemas para definições de TS é um pouco confuso. Você está direcionando o pessoal para o repositório penas-datilografado, mas mencionou _ "Este repositório agora está obsoleto" _. Se você não vai manter as definições nos respectivos repos e, em vez disso, utilizar o DT, acho que faria mais sentido manter os problemas no repo do DT também, uma vez que é presumivelmente onde os PRs se originarão e serão mesclados.

Acho que decidimos tentar aqui. Tenho recebido solicitações em vários canais e direcionado as pessoas para irem lá. Foi uma maneira rápida de centralizar isso. Pessoalmente, eu realmente não me importo para onde vai, contanto que seja um lugar

Existe alguma razão pela qual não podemos usar feathers.services.dogs vez de feathers.service('dogs') ?

sim. feathers.service('dogs') chama defaultService (que instancia o serviço no cliente) e remove barras dos nomes dos serviços.

As definições de TypeScript agora estão em DefinitelyTyped .

Encaminhe quaisquer problemas e perguntas para https://github.com/feathersjs-ecosystem/feathers-typescript/issues