ああ、ちょうどhttps：//github.com/feathersjs/feathers/issues/64を見ました

これを前進させる最良の方法は、いくつかの基本的なTypescript定義を使用してリポジトリを開始し（＃64で、開始する場所に関するいくつかのポインタを投稿しました）、続行することです。
そこでの議論。

この号はあと1、2か月は開いたままにしておくことができますが、他の号はほぼ1年間開いていて、誰も取り上げませんでした。 そこに記載されているように、現在のコアチームはTypescriptまたはAngularを使用していないため、実際にはレーダーに載っていません（そして、近い将来に対処される可能性がある場合にのみ、問題を開いたままにしておくことをお勧めします）。

@harangueはいくつかの基本的な定義に取り組んできたと思います。 たぶん、Slackで彼らがここに住む場所についての議論を動かすことができますか？

承知しました！ この問題を解決する必要がある場合は、先に進んでください。

typescriptをサポートできれば本当にいいでしょう..どうすれば手伝うことができますか？

@rollymaduk私はFeathersの定義についてある程度の進歩を遂げましたが、それらを配布するための最良の方法をまだ確立していません（そして、TypeScript 2がリリースされようとしているので少し過渡的です）。 それまでに何かを解決したい場合は、私が取り組んだこの要点をます。

@harangue本当に素晴らしい仕事で、実際にはかなり準備ができているように見えます。注意が必要な領域には、認証、プロバイダー（rest、socke.io、primus）、dbアダプターなどの基本的なプラグインが組み込まれていると思います。 それらを配布する最良の方法とはどういう意味ですか？

これについてまだ話し合ったかどうかはわかりませんが、Typescript定義を維持し、最新の状態に保つ人がいる限り、メインリポジトリでTypescript定義を配布しても問題ないと思います。 したがって、準備ができたら、Feathers 2.1リリースの一部にすることができます（これには、サービスのコールバックがv3で非推奨になるなどの警告も含まれている可能性があります）。

TypeScript用のgenerator-feathersフォークはありますか？ 発電機のTSフォークに興味がありますか？

編集：ジェネレーターをフォークし、最初のコミットをプッシュしました。

したがって、 @ harangueはすでにhttps://gist.github.com/harangue/9d4ed79118e2656f5e3d2d699296ed36にあるFeathersTypescript定義の大規模なセットをほぼ実装しています。レビューして、場合によってはファイナライズして、TypeScript定義リポジトリに送信する必要があります。

年末までに上陸するAukリリースのこの部分を作成します。 それまで誰もステップアップしない場合、この問題は完全にクローズされ、TypeScriptの公式サポートや、全体のプルリクエスト以外のこれに関するさらなる議論はありません。

それらの品質が良好な場合は、定義をフェザーとバンドルすることを検討する必要があります。 多くの人は、セカンダリパッケージマネージャーの使用をできるだけ避けたいと思うでしょう。

それらはnpm i @types/feathers介してインストール可能です。 typingsようなものはもう必要ありません。

https://github.com/DefinitelyTyped/DefinitelyTypedに追加するだけだと思いました

DefinitelyTyped FAQから：

types-2.0ブランチは、types-publisherのおかげで、NPMの@typesスコープに自動的に公開されます。 これは通常、変更がマージされてから1時間以内に発生します。

それを知りませんでした。 したがって、それらをDefinitelyTypedに追加するだけで十分です。

ああ、JS。 あなたは1、2か月間去り、エコシステムは進化します：smile：

長い間、私の側でこれについてラジオの沈黙があったことを残念に思います。 私は今日、古いタイピングで抱えていたいくつかの問題を修正する要点の別のリビジョンを

要旨に存在する定義は、1）タイピングテスト（Feathersドキュメントからいくつかの例をプルする必要がある）と2）JS Docアノテーション（インテリセンスには適していますが、必須ではありません）。

技術的には、フックのタイプはフェザーフックにも抽出する必要があります。 ただし、ここで型指定を拡張すると、静的型で複製するのが少し難しいミックスインパターンがuberprotoにあるため、少し面倒になります。

@harangueに戻っていただきありがとうございます。 フックをコアの一部にすることを計画しているので、ここではフックの入力をそのままにしておくことができると思います（＃408を参照）。 また、https：//blog.feathersjs.com/feathers-application-and-error-hooks-7a5982e70024で説明されているように、新しい.hooksメソッドでタイピングを更新する必要がある場合があります（まだ文書化されておらず、作業中です） :)。

@harangueいつあなたはあなたのタイプを間違いなくタイプされたものに提出すると思いますか？

みなさん、こんにちは。TypeScriptの定義が登場するのを見るのは本当にクールです。 @harangue 、feathersライブラリに一致する名前空間をエクスポートしていないため、 import ... from 'feathers'はエラーをスローします。

ねえ@subvertallchris 、あなたは使うことができます

import * as feathers from 'feathers';`

また

import feathers = require('feathers');

それらは同等です。 :)再びフェザーズの時間が取れると思ったとき、他のことに巻き込まれましたが、新年までにこれらの定義が完全に具体化されることを望んでいます。

@ j2L4e TSジェネレーターフォークが404になっているようですか？ これに関するニュースはありますか？ また、 @ harangueはどうですか？ 私はこの土地を本当に見たいと思っており、TS定義ファイルの実装を喜んでお手伝いします。 feathers generate --tsフラグが付いたフォークで、CLIでTypescriptやドキュメントをうまく再生できます。 お知らせ下さい。

維持するのは難しく、mysqlとローカル認証でのみ適切に機能し、generator-feathersはとにかくすぐに廃止されます。 だから私はそれを廃棄しました。

新しいCLIのリリースを熱心に待っています

アム19. Dezember 2016 14時41分42秒MEZ、schriebのgeorgeedwards [email protected] ：

@ j2L4e TSジェネレーターフォークが404になっているようですか？ これに関するニュースはありますか？
また、 @ harangueはどうですか？ 私はこれを見たいと思っています
着陸し、TS定義ファイルの実装を喜んでお手伝いします。
feathers generate --tsフラグが付いたフォークでCLIを再生します
うまくtypescriptまたはドキュメント。 お知らせ下さい。

-
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください。
https://github.com/feathersjs/feathers/issues/381#issuecomment -267966376

この問題にまだ取り組んでいる人はいますか？ このプロジェクトをTypescriptで使用したいと思います

こんにちは、みんな

嬉しいことに：_ほぼ完了です。_😄
私はFeatherjsOrgで多くのフォークを作成し、リポジトリによって定義を記述しました。 そして、あなたは最高のタイプスクリプト定義でfeathersjsを使ってこのサンプルを見ることができます

Feathers + Nodejs + Typescript
FeathersClient + Aurelia + Typescript

[はい、ESNext、Commonjs、AMD、およびクライアントチャンクへのグローバルモジュールをサポートしています]

aureliaサンプルは、angular2の操作方法の手がかりを提供します。 これらのリポジトリには、typescriptがライブドキュメントを提供するのにどのように役立つかについて多くの詳細があります。

私はすぐにPRを行いますが、あなたは見て、質問をして、私にフィードバックを与えることができます。 👌？

フォークwihの定義：

• 羽フック
• 羽毛-primus
• 羽毛-socketio
• 羽-残り
• フェザー-認証-クライアント
• 羽-クライアント
• 羽毛

少し仕事がありましたが、羽とタイプスクリプトが大好きです

それはすべて相対的なリンクです

リンクを修正しました。

@AbraaoAlvesこれは素晴らしく見えます、ありがとう！ 私はちょうど不機嫌なコメントを書いて問題を閉じようとしていました、そしてあなたが最初にコメントしてくれてうれしいです😉プルリクエストを見るのを楽しみにしています！

いい男@AbraaoAlves ！

@AbraaoAlves本当にありがとうと言いたかったのですが、これは私にとって大きな助けになります！ あなたが最後の瞬間にやってきたなんて信じられない

@AbraaoAlves私はあなたの定義のいずれかを実際に使用するのに問題があります。 package.jsonにパッケージをインストールすると

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

したがって、次のようなTypeScriptファイルで使用しようとすると次のようになります。

import * as feathers from "feathers"

コンパイルに合格しますが、実際には正しく実行されません。

タイプ定義のみをインストールし、ソースはインストールしません。 また、feathers-restはtypescriptが認識する関数をエクスポートしないようです
rest()' as a valid command for app.use(rest());

また、もう1つの問題として、app.useは次のような引数を受け入れなくなったようです。
this.app.use(bodyParser.json());

として使用する必要があります

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

@Chrisdf package.jsonのtgzファイルでこれを修正し、今すぐクローンを作成して、もう一度インストールしてみてください。

これに関する詳細：問題

@AbraaoAlves DefinitelyTypedに定義を入れない理由はありますか？ このようにして、NPMから@types名前空間を介して利用できるようになり、リリースの一部として定義を最新の状態に保つためのコアチームの要件が削除されます。

@AbraaoAlvesところで、なぜ定義はコミットされず、代わりにtarballリリースとして投稿されたのですか？ この方法では、 typingsでより多く利用できるようになります。 私はこの努力に非常に感謝し、定義を使用可能な形式でコミュニティに提供することが有益であることに同意します。DefinitelyTypedは良い動きになるでしょう。

@AbraaoAlvesと@harangueの両方の作業に基づいて

涼しい。 これのために私たちができる/すべきことはありますか？ それ以外の場合は、DefinitelyTypedに含まれるものがあれば、この問題を解決できると思いますか？

このリポジトリとpackage.jsonに含める必要があります
（少なくともそれが最良のケースです）

例： package.jsonインクルードファイル

みなさん、こんにちは/
忍耐とフィードバックをありがとう。

@stevehipwellと@daffl ：typescript定義ファイルは、ドキュメント、ライブドキュメントのようなものだと

私は@typesとDefinitlyTypedイニシアチブを知っています。これは、JavaScriptコミュニティにとって、javascriptの人が定義について心配しないようにするために重要です。

今日、両方を1つの場所で、1つのリリースで維持する機会があれば、通信エラーの発生率ははるかに低くなり、リリースごとに公式の定義が作成されます。

javascriptプロジェクトの例は、独自の定義を維持しています： Aurelia 、 Preact 、..。

全員が同意する場合は、PullRequestリンクを次に示します。

• 羽毛
• フェザー-認証-クライアント
• 羽フック
• 羽毛-primus
• 羽-残り
• 羽毛-socketio
• 羽毛-認証
• 羽-クライアント（これらの他の人が解決した後に送信します）

型付きテスト、自動化など、やるべきことはまだまだたくさんありますが、これはまだ始まったばかりです。

Typescript S2 FeathersJS！

こんにちは、みんな、

私は@AbraaoAlvesに同意し

定義がプロジェクトのリリースと同期していることを確認するには、フェザーチームからの透明性を高める必要があります。 これまでのところ、私自身の定義を書いている間、リリースの現在の状態が何であるかはわかりません。 ブログは最新の状態に保たれておらず、意味のないコードネーム（v3、auk、buzzard ??）がいくつかあります。

@ AbraaoAlves-あなたの定義は良さそうですが、私が見ることができることから、 hooks()メソッドなどの欠落している領域があります。 これらを追加することに興味がありますか？

こんにちは@stevehipwell 、

フィードバックをお寄せいただきありがとうございます。 そして、これが私の答えです：

ただし、最悪のシナリオには、最終的に古くなる定義ファイルが含まれています...
定義がプロジェクトのリリースと同期していることを確認するには、フェザーチームからの透明性を高める必要があります

はい、同期の問題は実際の問題ですが、テストで修正できます。
私はtypescriptでテストを行うことを提案します：＃508

この解決策について同意するかどうかにかかわらず、そこで意見を述べてください。

もちろん、破壊的な変更を加えることなく、feathersjsをタイプスクリプトに適したものにすることに本当に意欲的です。
hooks()メソッドなど、やるべきことはまだたくさんありますが、これを一緒に構築できるようになりました。

バグを見つけたり、定義を見逃したりした場合は、問題を作成してください。

@AbraaoAlves定義を最新の状態に保ちたいという願望があるようですが、喜んでお手伝いさせていただきます。 マージリクエストが完了したら、不足している定義のメインリポジトリでバグを発生させたいと思いますか？

@stevehipwellはい、それがポイントです。

リリーススケジュールの問題は何ですか？それを改善するために何ができるでしょうか？ ここでのマイルストーンは、まだ大まかに私たちが計画しているものです。

• 次のリリースはAukです。これは、ジェネレーターが完成し、ドキュメントが更新されたコードです。 重大な変更は
• その後のリリースはBuzzardであり、次の重大なコア変更が含まれます（実際、v3-と呼ばれることもありますが、おそらくそうすべきではありません😉）：
  
  
  
  • フレームワークの独立性（https://github.com/feathersjs/feathers/milestone/9）（そしてそれによってクライアントの統一された構造）
  
  
  • コアのフック（https://github.com/feathersjs/feathers/issues/408）
  
  
  • チャネルベースのイベントフィルタリング（https://github.com/feathersjs/feathers/issues/388#issuecomment-239564856）
  
  

それらの機能が着陸したら、定義を更新するプロセスはどうあるべきですか？

Typescriptの定義は、C ++の.h（ヘッダー）に似ています。 モジュールに応答しないヘッダーがある場合、ドキュメントが使用されているコードのバージョンと一致しないなど、実行時に問題が発生する可能性があります。

したがって、APIの変更が必要な各マイルストーンに定義を含める必要があると思います。たとえば、メソッドを他のリポジトリに移動したり、メソッドに新しいパラメータを追加したりします…

フェザー認証の定義を変更し、特定のプロジェクトへのフックを削除してv1に合わせます。
ここでの問題は、この現在のバージョンのFeathersJSに定義を含める必要があるかどうかです。

@AbraaoAlvesそう思います。 私はあなたのすべてのPRのマイナーリリースを作成することができ、そこから繰り返すことができます。 私がまだ疑問に思っているのは＃508だけですが、それについてコメントします。

上記の入力で2つの問題に直面しています。

socketioは動作したくありません。

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

また、feathers-cliは引数なしで出力しますが、残りにはハンドラーが必要です。

.configure（rest（））//ここでのエラーdeclare function rest（handler：Function）：Function;
.configure（socketio（））

ノード-v
v6.6.0

npm -v
3.10.5

tsc -v
2.1.6

これがエントリポイントであるため、モジュールとして「feathers（）」を使用する方法を示すことも興味深いでしょう。
生成された他のすべてのサービス/ミドルウェアを変換できますが、コンストラクター（）{}にfeathers（）をカプセル化するより良い方法が必要です。 （私は羽毛に不慣れです、私もそれを間違っているかもしれません...）

パッチリリースとして定義を出すことはできますか？ このレベルの変更は、パッチリリースに完全に適合します。 重大な変更や新機能はありません。 部分的または誤った入力でも、入力しないよりはましです。

リリースができたら、拡張を使用してタイピングを改善できる作業の開始点があります。

これが停滞し続け、私の定義のためにDefinitelyTypedルートをたどる必要がある場合。 私はこれを行う必要はなく、リポジトリの定義を喜んでお手伝いします。

＃508で@AbraaoAlvesに質問がありましたが、まだ返信がありません。 リリースを作成する場合、発生する可能性のある問題に迅速に対処できる人が必要です（特に、最悪の場合、TypeScriptを使用している既存のアプリが破損する可能性があるため）。 Slackで調整して、リリースを作成および検証できますか（minor.preから開始できます）？

経由で各モジュールのマイナーバージョンでリリース

• 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

まず第一に、この議論に参加したすべての人、特に貢献した人に感謝します。 多くのFeathersリポジトリのTypeScript定義を使用してマイナーバージョンをリリースしましたが、多くの問題が発生しました。それ以外の場合はかなり安定したモジュールの予定外のリリースであるため、ユーザーはTypeScriptをまったく使用しないように更新されます。チーム（誰もTypeScriptを使用しない）を確実に修正します。

Feathers + TypeScriptの議論全体からの私の主なポイントは、既存のJavaScriptプロジェクトの型付けを作成および維持するのが非常に難しいように思われることです（相互運用性のTypeScriptの主張についてはあまりよく話せませんでした）。 コアチームはTypeScriptを使用していないため、APIの重大な変更をリリースする際に前進する唯一の選択肢は、古いTypeScript定義を削除することです。

DefinitelyTypedリポジトリにFeathersモジュールの最新のTypeScript定義があると

TypeScriptの相互運用性の主張についてはあまりよく話せなかった私には

Feathersは、特定の型指定なしで完全に使用できます。それは、インテリセンスと型なしの単純なJSです。 特に、ミックスインを多用するfeathersのプラグインシステムでは、タイピングの作成が困難になります。これは、タイプスクリプトではない方法であるためです。 私は通常のtypescriptユーザー（およびそのファン）ですが、今のところサーバーサイドのフェザーを使用するためにES6に戻りました。
コアチームの誰も実際にtypescriptを使用していないので、ここでは型を個別に維持する方が適しているようです。

TypeScriptでうまく機能する場合、フェザーはAngularのサーバー側フレームワークとして推奨されます。 言ってるだけ' ：-）。 とりあえず先に進みます。

@ j2L4eプラグインによって現在混合されているほとんどのものがコアの一部になると、これは次のリリースでより簡単になると思います。 しかし、これで確実に助けを得るという一般的な問題が解決するかどうかはわかりません。

@rjsteinert現時点で存在するものはほとんど機能するはずですが、そうです。他のオープンソースプロジェクトと同様に、試して支援するか、先に進む機会があります。

試して手伝うか、先に進むチャンスがあります。

私はAngularの長年のJSプログラマーに不慣れな人の一人であり、TSがどれほど人生を壮大にするかを理解し、サーバー側でTSを使用しないと、チームはそれを呪い、書き直そうとしていることに気づきます。次の数年間は毎日それを。 オプションが不足しているため、結局のところフェザーを使用する可能性があります。その場合は、タイピングを最新の状態に保つのに間違いなく役立ちます。 私たちが通りかかって、「APIの重大な変更をリリースするときに前進する唯一の選択肢は、古いTypeScript定義を削除することです」と言っているだけですが、他の場所を探します。 ちょっと考えないでください。既存のプロジェクトをサポートする必要があることは理解しています。私たちが書き直しをしている状況では、すべての人が幸運ではありません（運命にあるかもしれません）。

@rjsteinert TypeScriptは、あなたにとって非常に価値のあるものとして何を提供しますか？ （正直な質問）私の現在の一連のFeathersの作業が完了した後、私の好奇心は、TypeScriptを見るのに十分な興味をそそられます。 オートコンプリート/ CodeSenseに役立つことは知っていますが、Feathers APIは非常に小さいので、それほど便利だとは思えません。 私の無知を許してください。 ;）

autocomplete/CodeSenseは素晴らしい副産物ですが、私は通常Vimにいるので、グッズを入手できません。 私がこれまでに見た大きな変化は、提供された関数やオブジェクトの使用方法を明確にする方法を標準化することです。 NPMのライブラリを調べてみると、動的型付けされた言語ではわからないことを明確で使いやすくするために、独自の独創的なソリューションを使用しているライブラリがたくさんあります。 TSは、コードを書いているときに自分でチェックするタイプのボイラープレートを大量に節約し、他の人のコードの使用方法をすばやく理解しやすくします。 最近は自分のスタイルのボイラープレートJSを書くのにうんざりしていると思う傾向があり、外部ライブラリを使用するたびに誰かのREADMEを読みたくありません。

私は@rjsteinertに同意し

このGitHubの投稿に書き込み、FeatherJSを使用している場合は、おそらく熱心なJavaScript開発者です。 あなたがFeatherJS開発者の一人であれば、TypeScriptを自分で使用しても意味がありません。 特別なツールやTypeScriptのヘルプは必要ありません。 あなたはJavaScriptのユニコーンです。
私はTypeScriptに非常に反対していました（特にバージョンAlpha 1.1で使用することを余儀なくされました）が、長年にわたって、TypeScriptを高く評価することを学び、TypeScriptなしでは生きていけません。 一緒に仕事をする同僚は、JavaScriptの知識ほど知識がありません。 彼らはすべての異なる背景から来ており、JavaScriptがいかにくだらないものであるかを罵倒します。

それ以来、TypeScript言語はコミュニティのフィードバックから大きく成長しました。
ツールと大きなチームがなければ、大規模なWebサイトを構築することはできません。 @rjsteinertが言うように、チームはクライアント側でTypeScriptの使用を開始し、しばらくすると、サーバー側を使用することに非常に不満を

ウェブ上で使用されている最も人気のある言語を見てください：PHP、NodeJS、Ruby、C＃、Java ...それらのいくつかは型付けされていますが、そうでないものもあります。 私はこれらすべての言語で作業しましたが、これらすべての年月を経て、「実行時のみのエラーの検出」言語に戻りたくないと言えます。 それらはすべて、魅力、長所、短所があります。 大規模なチームでは、私は常に少し強くてタイプされたものを使うことを提案します。

私が書いたPHPSDKを使用している人の最新の例。 100桁の「大きな数」を受け入れるメソッドがある場合、実際には文字列として扱います。 初心者の開発者は、 setValue(123456789123...)呼び出しが機能しない理由を尋ねるバグを開きますが、NodeJSまたはsubstrメソッドではかなり低くクラッシュするようです。 これで、中間開発者はドキュメントをチェックして、それが文字列である必要があることを確認します。 タイピングを想像してみてください。タイピングまたはコンパイル時に文字列を強制的に入力します。 そうすれば、開発者は特定のドキュメントを読む必要も、バグを開く必要もありません。

新しいAngular2 + NodeJSプロジェクトに使用するフレームワークについて少し調べたところ、FeatherJSがまさに必要なもののようでした。 ただし、今日別のサーバープロジェクトが出て、「TypeScriptをすぐにサポートします」と言った場合は、すぐに切り替えます。

この問題に関する皆さんのご意見に感謝します。 非常に良い議論がいくつかありましたが、それはタイプスクリプトのメリットに向けられ始めていると感じています。それは実際にはこの問題の目的ではありません。 コアチームは話し合いましたが、Typescript定義はフェザーの操作に不可欠ではなく、フェザーのコアを進化させる速度を低下させるため、サポートしません。 リリース時に更新するものはすでにたくさんあります。 リリースをより早くリリースするために依存関係を減らしようとしていますが、Typescript定義を追加すると作業が増えます。 Feathersコアチームの誰もTypescriptを使用していないので、次のようにします。

1. 定義を適切に維持するための十分な知識がない
2. ユーザーベースのごく一部が定義を「必要とする」場合、定義の作業に時間を費やすことはできません。 より多くの人々に影響を与えるために取り組むべき他の多くの項目があります。

公式の定義を作成/維持したい場合は、新しいドキュメントのエコシステムセクションでそれらにリンクできますが、自分で使用しないでください。フェザーを使用する場合はTS定義は不要であり、個人的な好みです。それらを維持するつもりはありません。 それらを既存のリポジトリからプルし、 @ dafflはそれらをhttps://github.com/feathersjs/feathers-typescriptに配置し@jsgoupil、@rjsteinert、@AbraaoAlvesまたは他の誰興味がレポを維持したい場合、我々は、アクセス権を付与および/またはレポを転送させていただきます。 これにより、定義を最新の状態に保ち、DefinitelyTypedに送信しやすくなると思います（確かに、そのプロセスについてはよくわかりません）。

この問題は議論のために開いたままにしておきますが、コアリポジトリの外部で定義を実装するために必要なこととは対照的に、Typescriptのメリットについて議論し続ける場合は、スレッドをロックします。 😄

あなたはこれを含めたくない場合は、NPMに公開され、設定されたバージョンのソースディレクトリを含めてください可能性がjsnext:mainまたはmoduleでpackage.jsonエントリに

TypeScriptはワイルドカードモジュール定義をサポートするようになったため、feathers-sub-modulesからすべての型を削除し、これをfeathers含めるのは簡単な回避策です。

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

これは、フェザーとすべてのフェザーを宣言します。どのモジュールもタイプanyとして宣言します。これにより、TSをすぐに使用できるようになります。 強化されたインテリセンスは得られませんが、既存のプロジェクトの内容を壊すことなく機能し、問題を解決します。

私もします：

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

多数の小さなPRを開いて、TS以外のユーザーに対して実際には何もパッチを適用しないパッチバージョンを多数作成するのではなく、当面の間、誤ったまたは不完全なtypedefを「オーバーライド」します。

こんにちは、
タイプスクリプトのサポートに関する疑問を1つ明確にしておきたいと思います。
サービスの現在のタイプ定義によると、すべてのサービスメソッドは必須メソッドです。

しかし、ドキュメントによると、サービスメソッドはオプションです。
見る

ですから、サービスの定義は以下のようになりますね。

  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はいそうです

私は今のところ「オーバーライドレポtypedef」の回避策に固執しており、プロジェクトが完了したら、いつか（指を交差させて）feathers-typescriptまたはDefinitelyTypedで公開するかもしれません。

これにより、少なくとも1つの本番プロジェクトで戦闘テスト済みの定義を提出することができます。

ありがとうクー！

2017年5月9日火曜日午前7時42分、リチャードマイケルクー<
[email protected]>は次のように書いています：

@ harish2704https ：//github.com/harish2704はいそうです

私は今のところ「オーバーライドレポtypedef」の回避策に固執しています、そして
多分いつか（彼の指が交差した）羽に公開する-typescriptまたは
プロジェクトが完了したら、DefinitelyTyped。

それは私がでいくつかの戦闘テストされた定義を提出することを確実にします
少なくとも1つの生産プロジェクト。

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/feathersjs/feathers/issues/381#issuecomment-300138396 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ABezn0WGqH30NNp8-X-ckpVuk_BTQbbnks5r4FEQgaJpZM4Jears
。

@myknbani
チェックインするのは少し早いかもしれませんが、typedefをどのように利用しましたか？ 手が必要ですか？ :)私は新しいプロジェクトでフェザーを使用したいと思っていますが、TypeScriptのサポートがないことは少し厄介な点です。

TypeScriptサポートの欠如

正確に何を意味するのかわからない。 それは完全に機能します。 完璧にはほど遠いですが、機能します。

@jonlambert @ ここで説明したトリックを実行します。

IMHO、約2行でのみ使用する必要があるfeathers-restようなパッケージは、入力する価値がまったくありません:-)

何を変えたのかすら思い出せませんが、フックやサービスは問題ないと思います。

@ j2L4e feathersはTypeScriptをサポートしていないという意味

TypeScriptは、アプリが将来的に保守可能であることを保証するワークフローに不可欠であるため、

この回避策がなくても機能します。 公式リポジトリには、あまりいじる必要のないタイピングがあります。 不快感はありませんが、うまくいったとしても試していないようです。

Feathersコアチームの誰もTypescriptを使用していないので、次のようにします。

1. 定義を適切に維持するための十分な知識がない
2. ユーザーベースのごく一部が定義を「必要とする」場合、定義の作業に時間を費やすことはできません。 より多くの人々に影響を与えるために取り組むべき他の多くの項目があります。

フレームワークの新参者として、私はこの問題の存在を考えていたでしょう。さらに、上記のコメントは、TSサポートの欠如を想定するのに十分でした。 それが間違った結論である場合は申し訳ありませんが、私はそれを試してみます。

また、「機能する」可能性もありますが、型定義がAPIで最新の状態に保たれることを保証する形式がなければ、将来的に問題を引き起こす可能性があるようです。

あなたが正しい。

ただし、最近はかなりの数の機能強化が行われ、タイピングの完了が計画されており、作成中です。

これは素晴らしいニュースです🙂これまでのところフレームワークでの作業を本当に楽しんでおり、TSで使用できることに興奮しています🎉

この回避策がなくても機能します。 公式リポジトリには、あまりいじる必要のないタイピングがあります。 不快感はありませんが、うまくいったとしても試していないようです。

@ j2L4eその通りです。 typedefは今でははるかに良い状態になっていると思います。 すべての「オーバーライド」を削除しましたが、これまでに残っている問題は、 app.service(...)を使用する場合の!アサーション（ strictNullChecks coz）だけです。

サービス定義（サービスメソッドがすべてオプションである場合）とサービスインスタンス（すべてのサービスメソッドが未定義ではない場合）の型を分けることをお勧めします。 現在、 !どこにでも追加する必要がありました（例： await app.service('api/foos').create!([{

私は回避策でこれを持っていました：

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

これはどうですか：

  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;

これにより、新しいタイプを作成することで、TS以外のサービスを入力できます。たとえば、feathers-mailerの場合：

type MailerService = CreateService<Mail>;

または、作成と削除のみが可能な（まったく役に立たない）サービス：

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

これはすべて、セレクター関数を使用してサービスを念頭に置いて（たとえば、app.service（s => s.mailout））、適切なタイプでそのサービスを返します。 ここに見られるように：

もう一度チェックインするだけで、どうやって乗りますか？ @ j2L4e post ^本当にきれいに見えます！ 私が何か助けになるかどうかを確認するために他に何をする必要があるのか​​疑問に思っています。

OK、これまでに見たエラー：

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]モジュール '"c：/ Users / George / Source / Repos / ts4 / node_modules / females-errors / not-found"'は非モジュールエンティティに解決され、この構成を使用してインポートすることはできません。

[2]

タイプ 'Function'の引数は、タイプ 'PathParams'のパラメーターに割り当てることができません。
タイプ 'Function'はタイプ '（string | RegExp）[]'に割り当てることができません。
プロパティ「push」がタイプ「Function」にありません。

[3]

タイプ 'Function'の引数は、タイプ 'PathParams'のパラメーターに割り当てることができません。
タイプ 'Function'はタイプ '（string | RegExp）[]'に割り当てることができません。
（エイリアス）notFound（）：関数

既存の回避策はありますか？

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

次のバージョンでは、 @ j2L4eは

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

lernaはすべてのパッケージとdepsをリンクします。 次に、。/ packages / testsサブフォルダー（テストがまだ見つからないため、一種の遊び場にしました）に移動して、TSの良さを試してみてください。 index.tsをチェックしてください。

コンパイルして実行するには、。/ packages / testsからnpm startを実行します

Feathers 2から3への移行を開始したばかりで、index.d.tsファイルがヘッド@feathersjsパッケージから欠落しています。 それらを復元する計画はありますか？

上記の1つのコメントで述べたように、それらはhttps://github.com/feathersjs-ecosystem/feathers-typescript/tree/buzzard-j2L4eに移動され、DefinitelyTypedに送信されます。 @ j2L4eは現在忙しすぎるので、これを拾うのは他の誰か次第です。 私が理解したことから、それは主にLintingを通過させ、DefinitelyTypedに送信することです。 私はこれを喜んで手に入れる人を喜んで助けますが、自分でそれを受け入れる予定はありません。

うん、それは私が予想していたよりもはるかに多くの作業であり、コミュニティからのフィードバックは事実上ゼロでした。 時間を見つけたらすぐに実現させます。 しかし、それほど早くはありません。

誰かがここでチャイムを鳴らすとしたら、それは本当に素晴らしいでしょう。 DTリンティングがすべてですが、すべてが正常に機能していることは別として、

Slackからのクイックコピーアンドペースト：

みんな、私は今本当に忙しいので、タイピングは最優先事項ではありません。 それらは機能しますが、DefinitelyTypedはリンティングルールに関して非常に厳格です。 タイピングが明確にタイピングされたリンティングプロセスを通過するのを手伝ってくれるなら、それは素晴らしいことです

ここで私のDTフォークをチェックしてくださいhttps://github.com/j2L4e/definitelytyped 、あなたはtypes/feathersjs__packagename feathersjsパッケージを見つけるでしょう

クローン、npmインストールして、パッケージの1つにリンターを実行します（例： npm run lint @feathersjs/feathers （編集済み））

@feathersjs/feathersはすでに適切にリントされているので、参照として使用できます。 （編集）

TypeScript定義は、 https：//github.com/DefinitelyTyped/DefinitelyTyped/pull/22805でDefinitelyTypedにレビューが追加されるのを待っています

NPMを介して定義にアクセスできるようになりました！

はい、パッケージ@feathersjs/package @types/feathersjs__packageをインストールして、フィードバックをお寄せください。

@erikmaご支援ありがとう

@ j2L4eお疲れ様でした！ しかし、すべての@featherjs/express関数をエクスポートしてもよろしいですか？ typescript定義ファイルにrest、json、notFound、urlencodedについての言及が見つかりません。

あなたが正しい、それらは欠けています。

今のところ、typings.d.tsファイルを次のように追加します。

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

urlencodedがどこに行くべきかわからない。

urlencodedとjsonは、最後のマイナーバージョンのexpressに追加されました。 express入力はまだ更新されていませんか？

それはエクスプレスですか、それともfeathersjs / expressですか？

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

だからあなたはImport { urlencoded, json } from '@feathersjs/express'をすることができるはずですか？ または、エクスポートされたoriginalから取得しますか？

require('express')からエクスポートされたものはすべて、 @feathersjs/expressによって再エクスポートされます： //github.com/feathersjs/express/blob/master/lib/index.js#L82

また、問題のない定義でchannels.tsを処理する方法を知っていますか？
こんなに短い時間ですべての問題を投げてすみません。

@ types / feathersjs__socket-commonsをインポートします

輸入 ？ 理解できない

申し訳ありませんが、実際には「Import @ femalesjs / socket-commons」と表示されているはずです。 そのタイプをインストールする必要があります。

@types/feathersjs__feathersをインストールすると、 app.channelが機能しません。 次に@types/feathersjs__socket-commons追加すると、 app.onが機能しなくなります。

DefinitelyTyped / DefinitelyTyped＃23195を介して修正されます

ここでさらに問題を取り上げてください： https ：

TS定義の問題追跡は少し混乱します。 あなたは人々をfeathers-typescriptリポジトリに誘導していますが、あなたは_ "このリポジトリは現在廃止述べました。 それぞれのリポジトリで定義を維持せず、代わりにDTを利用する場合は、おそらくPRが発生してマージされる場所であるため、DTリポジトリでも問題を保持するのが最も理にかなっていると思います。

ここで試してみることにしました。 私はいくつかのチャネルを通じてリクエストを受け取っており、そこに行くように人々に指示することはそれを一元化するための迅速な方法でした。 個人的には、1か所である限りどこに行くのか気にしない

feathers.services.dogs代わりにfeathers.service('dogs') feathers.services.dogs使用できない理由はありますか？

はい。 feathers.service('dogs')はdefaultService （クライアントでサービスをインスタンス化する）を呼び出し、サービス名からスラッシュを削除します。

TypeScript定義はDefinitelyTypedになりました。

問題や質問がある場合は、 https：//github.com/feathersjs-ecosystem/feathers-typescript/issuesに送信して