思ったほど簡単ではありません。 FeathersはES5の継承とミックスインに依存しているため、TSへの切り替えが「正しく機能する」かどうかは疑わしいです。

TSでフェザーを操作する方法（j2L4eから）： https ：

余談ですが、 「コミュニティの他の人が喜んで助けてくれるだろう」というのは真実ではありません。 私たちは、TSについて声を上げている人々に、返事をせず、もっと多くの要求をするのを手伝ってくれるように頼みました。 一人は前進しましたが、TSについて声を上げた人々は、定義を完成させるためにステップアップしませんでした。 サポートが不足しているため、最終的にTS定義をプロジェクトから移動しました。

支援が必要な場合

__TL; DR__現在のFeathersコアの最終的な定義（ほとんどの場合、とにかく行われる）をDefinitelyTypedリポジトリに送信するには、__ someone__が必要です。 私はその人と協力して、フェザーズが行う可能性のある奇妙なことによって引き起こされるブロッカーを排除します。 これが機能する場合は、チームで次のバージョンのFeathersコアにTypeScriptを使用して立ち上げます。 そうでなければ、一般的な関心が十分にないか、TypeScriptコミュニティがそのような大きな一歩を踏み出すのに十分な信頼性があるとは思いません。

私は、多くの人々によって使用され、貢献され、長く続くことを願って、TypeScriptが賢明な選択であるかもしれないコードベースを作成し、維持することの意味についてもっと考えてきました。 私たちはすでにトランスパイラーを使用しているので、Babelの代わりにTSを使用することはそれほど大きな変化ではなく、個人的には、セキュリティと安定性の追加レイヤーを取得するためにJavaの時代に戻っても大丈夫です。 コアコードベースが複数の言語にまたがって断片化されることは絶対にありませんが、チーム全体が決定する必要があります（コア以外のプラグインはどちらの方法でも維持できます）。

私はこの言語に反対することは何もありませんが、 @ eddyystopが指摘したように、TypeScriptコミュニティでの私たちの経験はこれまでのところかなりがっかりしています。 多くのボーカルメンバーがサポートを要求し、それらすべての大きな利点を指摘しました-TSはJavaScriptと完全に互換性があると主張するように、私にはいつも奇妙に思えたものもありましたが、ほぼ同じ段落で、人々はあなたのJavaScriptを使用しないと指摘しましたTSをサポートするまでプロジェクトします。 しかし、_実際に何かをする_ということになると、ほんの一握りの人々（私たちが感謝する貢献と努力）が物事を前進させようとしましたが、何らかの理由でボールが落ち続け、私たちは何について多くの実用的なフィードバックを得ることはありませんでした私たちは物事を動かし続けるためにできることがあります。

@ j2L4eがサービスのミックスインの奇妙な使用法を指摘したような場合、それは次のバージョンで次のようなコアサービスインターフェイスを定義することで修正しようとしています。

interface Service {
  find(params: any),
  get(id: string|number, params: any),
  create(data: any, params: any),
  update(id: string|number|null, data: any, params: any),
  patch(id: string|number|null, data: any, params: any),
  remove(id: string|number|null, params: any),
  setup(app: FeathersApp, path: string)
}

そして、 app.serviceによって返されるラップされたサービスの拡張インターフェース：

interface FeathersService extends Service, EventEmitter {
  hooks(hooks: HooksObject),
  filter(filters: FilterObject)
}

私にとってTSについて明確にするためのいくつかの追加事項は次のとおりです。

1. TSを使用して変更しない場合は、Feathersを使用したくありません。 トランスパイル中に型チェックが行われていると思うので、これはすでに当てはまるはずですが、使用していない場合に、TS固有の奇妙なエラーが発生することは望ましくありません。
2. トランスパイルされたコードサイズとは何ですか？ 現在、クライアント側のすべてのフェザーは、最大2万個の縮小+ gzip圧縮されています。 私はライブラリサイズのマニアックではありませんが、トランスパイラー前の言語が異なるという理由だけで、これを大幅に変更したくありません。 また、どのブラウザと互換性があり、どのような追加のランタイムが必要ですか？
3. 型付きインターフェースをすでに使用している場合は、型付き+インラインドキュメントからAPIドキュメントのマークダウンを生成できるようにしたいと思います。 これを行うための深刻なツールはありますか？

今は少し時間が足りないので、ほんの一言：

TSを使用して変更しない場合は、Feathersを使用したくありません。

RxJSはネイティブTSであり、JSで非常にうまく機能します。 ミックスインスタイルから離れることは、重大な変更を課す可能性がありますが、Typescriptに固有の変更はありません。

トランスパイルされたコードサイズとは何ですか？

TypeScriptは、ES3、ES5、またはES6にコンパイルできます。 TSのES5サポートがそれほど優れていなかったときは、ES6にコンパイルし、Babelを使用してES5にコンパイルするのがしばらくの間一般的でした。 ES3のコンパイルにはいくつかの制限があると思いますが、私自身はこれを使用したことがありません。なぜそうするのでしょうか。
ES6にコンパイルすると、基本的に型注釈が削除され、JSコードが作成されます。 ES6をターゲットにする場合、非同期/待機、インポート、およびデコレータは別として、コンパイルが必要なものはありません。 TypeScriptのコンパイルされたES5コードは、非常に読みやすいことも知られています。

（2年前のコードサンプル、30秒で思いつくすべて）
ES6クラス： https ：//gist.github.com/fariszacina/515e4c81704d839ea490#file -simple-es6-example-js
TS（ターゲットES5）でコンパイル： https ：//gist.github.com/fariszacina/6287b4213ebf6965d05e#file -simple-es6-example-typescript-output-js
Babelでコンパイル： https ：//gist.github.com/fariszacina/dc8d5c7c17c5b2ab01ee#file -simple-es6-example-babel-output-js

コードサイズの観点から：Babelが提供できるものよりも大きいとは思えません。 週末に試してみることができます。

また、どのブラウザと互換性があり、どのような追加のランタイムが必要ですか？

ES5を実行し、ランタイムがないもの。 TSコンパイラから出てくるのはプレーンJSです。

タイピングとインラインドキュメントからAPIドキュメントのマークダウンを生成します。

https://github.com/TypeStrong/typedoc

TS定義からJSDocを生成し、そこから先に進むこともできます。

CoffeeScriptの最高の機能と同じように、入力は最終的にJavaScriptになります。

TSの欠点を含むフローを含む政治を含む複数の理由から、JavaScriptのタイピングがTypeScriptとまったく同じになるとは思えません。 良いアイデアは採用されますが、悪いアイデアは採用されません。

TSを使用するプロジェクトは、CoffeeScriptを使用するプロジェクトと同じ問題に直面します。 彼らは、新しい標準にあまりにも類似しているが、それと完全には互換性がないコードを持っています。

外部化された定義は良い妥協点です。

• TSで書かれているため、人々はフェザーをバイパスしません。 （CoffeeScriptで記述されたnpmパッケージは、JSにトランスパイルされたとしても、ほとんど無視されたことを忘れないでください。）
• 標準が到着したときにTSを削除する必要はありません。

FWIW、私は@eddyystopに同意します

全員が参加していると仮定して、できる限り貢献します。

あなたは素晴らしいものを作り上げました。これにより、より多くの人々がアクセスできるようになると思います。

@ j2L4eミックスインがサポートされています。 継承とはどういう意味かわかりませんが、サブクラスとは、1日目からサポートされています。 ES2015で実行できる場合は、スーパーセットであるため、TypeScriptで実行できるはずです。

@dafflあなたの質問に答えるには：

1. APIを変更しなければならない理由はわかりません。 TSコンパイラエラーがJSユーザーに漏れることはありません。 私の経験では、Trasnspiledのサイズは実際にはBabelよりもわずかに小さくなっていますが、タイプチェックを無効にしない限り、ビルド時間はわずかに長くなります。 20秒のように22秒になります。

2. 必要なのはローダーとTypeScriptコンパイラだけなので、依存関係の数が大幅に減ります。 ブラウザの互換性は、TypeScriptに何をターゲットにするかによって完全に異なります。 必要に応じて、ブラウザ準拠のES3、5、または2015、2017をターゲットにします。 これは、Babelのようなnpmパッケージの形式のプリセットではなく、単なるコンパイラスイッチです。

3. typedocはこれに非常に適しています。 これが例です

継承の例を含めて試してみることができる遊び場です。 ツールのダウンロードに時間を費やすことなく、何が出力されるかを確認できます。

TypeScriptではできないと言っているわけではありません。 現在の動作方法（uberproto）を入力するのは難しいです。 特に羽毛のようなもの-サービスメソッドを置き換える反応性。

CoffeescriptとTypeScriptの比較に関していくつかまとめましたが、誤ってブラウザを閉じてしまいました：/今夜もう一度やり直します。

アム4.舞2017年午前18時49分28秒MESZのschriebマイク・モリソン[email protected] ：

全員が参加していると仮定して、できる限り貢献します。

あなたは素晴らしいものを作りました、そして私はこれがそれを作ると信じています
より多くの人がアクセスできます。

@ j2L4e
Mixinは
サポートされています。 継承とはどういう意味かわかりませんが、
サブクラス、それらは初日AFAIKからサポートされています。 あなたができるなら
ES2015では、TypeScriptで実行できるはずです。
スーパーセット。

1. APIを変更しなければならない理由はわかりません。 TSコンパイラなし
   エラーはJSユーザーに漏れます。 Transnspiledサイズは実際にされています
   私の経験ではバベルより少し小さいですが、あなたがいない限り
   タイプチェックを無効にすると、ビルド時間がわずかに長くなります。 20秒くらい
   22秒になります。

2. 依存関係の数が大幅に減少します。
   必要なのはローダーとTypeScriptコンパイラです。 ブラウザ
   互換性は、TypeScriptに指示する内容に完全に依存します
   目標。 ブラウザに準拠したES3、5、または2015、2017をターゲットにします。
   したい。 これは、フォームのプリセットではなく、単なるコンパイラスイッチです。
   Babelのようなnpmパッケージの

3. typedocはこれに非常に適しています。 ここは
   例

ここにあります
あなたがいる
継承の例を含めて試してみることができます。 それはあなたにビューを与えます
時間を費やすことなく出力されるものに
ツールのダウンロード。

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

-
Diese Nachricht wurde vonmeinemAndroid-GerätmitK-9Mailgesendet。

あなたは皆、外部のTS定義を使用してやりたいことを行う方法に集中する必要があります。

@eddyystopTSコミュニティについて不平を言っている人からのかなり分裂的なコメント。 これがFeathersコミュニティとの最初のやり取りであることを忘れないでください。 チームの他のメンバーも同じになると思いますか？

@ mizzle-mo、それは分裂を感じることを意図したものではないと思います。 そのように出くわしたらごめんなさい。 彼の返事は以前の会話に基づいています。 TypeScript定義は、それを理解している人に支持されていないため、個別に保存することを選択しました。 コアチームがそれを修正することは不可能ですが、問題は引き続き発生し、バックアップされます。 別のリポジトリに保持することは、論理的な選択のように思われました。 定義を分離しておくことの欠点はありますか？

@ j2L4eが行っている素晴らしい作業のおかげで、次のリリースではかなり堅実なTypeScript定義がありますが、Feathersコアは、

@daffl 「いつ」と聞いてもいいですか。 私は羽を使った新しいプロジェクトを始めています、そしてそれはTSを使うことができれば素晴らしいでしょう

やるべきことはあまり残っておらず、ドイツでは2つの休日が予定されているので、来週までにほとんどの作業（つまりタイピング）を行うことができます。

@ j2L4e素晴らしい、ありがとう

これに関する最新情報を入手するには、フェザースラックの#typescriptに参加してください

私もこれを手伝いたいです。 私はいくつかのプロジェクト（Feathers、feathers-plus / cli、feathers-vuex、およびいくつかのNuxtモジュール）のタイピングにいくつかの作業を行ってきました。

2018年11月を過ぎたスラックに関するメッセージを表示することはできません。しかし、これをローリングすることに興味がありますが、移行を開始する前に、移行がどのようになるかについて適切なアイデアが必要だと思います。

コード自体をTSに変換することは、TSの支持者が理解するよりもはるかに政治的な決定です。

考慮すべき他の要因は何でしょうか？ もちろん、他のプロジェクトについて話すことはできませんが、 @feathersjsコアの場合、外部APIサーフェスが変更されない場合、主にコードベースへの通常の貢献者に影響を与えます。

過去1年間、これは@ bertho-zeroであり、私自身と外部のTS定義メンテナー（@ j2L4eが先頭に立っています）です。 個人的には、TSを内部プロジェクトに少し使用していて、Feathersコアのようなプロジェクトにどのように役立つかを確認できます（たとえば、暗黙のドキュメント、下位互換性、クライアント側のビルドに関して）。他の人が助けている限り、この動き。 確かに、TS以外のユーザーが貢献することを思いとどまらせる可能性があります（または、はるかにあいまいなフロータイプを使用しているJestの

@daffl正直なところ、私の羽の学習と内部の仕組みは、typescriptによって大幅に改善できると思います。 Ctrlキーを押しながらクリックするだけで宣言にジャンプできます。 私が掘り下げようとしたいくつかのことは、少し飛び回っています。 私もこの時点でTypescriptに甘やかされているので、おそらくそれが理由です。 また、私はTypescriptに非常に精通していますが、Typescriptの初心者は、考えるのは恐ろしいと思いますが、驚くほど簡単に貢献できると思います。

私はあなたがこの種のものを一粒の塩で服用しなければならないことを知っています、しかし今私は羽に本当に興奮していて、もっと貢献したいと思っています。 私は休日でかなり忙しくて、最近仕事に追いついています。 しかし、私は今後数週間でもっと貢献し始めたいと思います。

フェザーをTSに変換し始め、これまでにフェザー、コモンズ、および構成を完了しました。 進捗状況はhttps://github.com/thavlik/feathersで入手できます

私が遭遇した主な問題は、デフォルト関数のエクスポートに関するものです。 私は、すべてのデフォルトのエクスポートを適切な名前のエクスポートに変更することを提案します。

@daffl
（a）ECMAScriptエコシステムがJSとTSに分岐しているのではないかと懸念していますが、これはエコシステムにとって有利ではないと感じています。

これはあなたや他の人にはささいなことのように聞こえるかもしれませんが、私は1990年代半ばにエグゼクティブレベル近くでマイクロソフトと協力しました。 その時私が知っていた人々は、今日のTSの状況に大喜びするでしょう。 （完全な開示：私は反IBMの取り組みに取り組みました。）

今日のMSの人々が当時の人々と似ていると言っているわけではありませんが（そうではないと言っているわけでもありません）、MSの抱擁-拡張-破壊戦略のこの新時代のバージョンは、当時と同じくらい危険だと感じています。 それはMSがエコシステムのショットを呼び出すことにつながり、あなたは彼らが彼ら自身に有益な方向に動くことは間違いありません。

（b）数十人のソフトウェア開発者を再び実行した場合、つまり通常は多くのジュニアを意味する場合は、TSの使用を検討します。 しかし、私のFeathersの作品はソロであり、最後に型に関するバグがあったのを思い出せません。 したがって、TSを使用すると不要なオーバーヘッドが発生します。

（c）サーバーでプリプロセッサを実行すると、速度が低下します。 また、テストの実行が遅くなります。 羽毛フック-一般的なnpm testは数秒かかっていましたが、今ではかなりの数のTSバージョンでタイピングをチェックし、完全なテストを実行するたびにコーヒーを飲んだり誰かとチャットしたりします。

（d）あなたと私はFeathersの開発者の95％以上をやっています。 1か月の長いバックログがあります。 あなたも同じ状況だと思います。 フェザーの問題の大部分を引き起こすため、認証には書き直しが必要です。 ジェネレーターを使用するためのフックの書き直しがあります。 それでもuberprotoを使用しますか？

TSへの書き直しは優先事項ではないと思います。

（e）Feathers APIを入力することで、TSユーザーに必要なものが提供されると思います。 TSへの書き直しはやり過ぎです。

（f）ECMAScriptがタイピングを導入する日を今でも楽しみにしており、それからそれらを使い始める可能性があります。

@thavlik
これもJSの問題です。 Nicholas Zakasは、ESLintに加えて非常に賢いことをした人です。 https://humanwhocodes.com/blog/2019/01/stop-using-default-exports-javascript-module/

@eddyystopがこれについて言っていることに完全に同意します：

（e）Feathers APIを入力することで、TSユーザーに必要なものが提供されると思います。 TSへの書き換えはやり過ぎです。

以前に@eddyystopと@marshallswainに述べたように、このプロジェクトのどれだけが自分自身に依存しているかに満足していません。新しいことに挑戦して、より多くの人々を巻き込み、貢献しやすくしたいと思っています。 すでにすべての定義があるので、コードベースの変換が克服できないタスクになるとは思わず（ @feathersjsはすべて2k行のコードであることに注意してください）、使用法は変更されません。私が見ている最悪のシナリオは、私がまだすべての作業を行っているが、人々はエディターでより良いコード補完を得るということです。 また、計画されている他の変更のいくつかともうまく一致します。

私は現在、いくつかの内部プロジェクトでTSを使用しています。これがすべてであるとは考えていませんが、（通常のTSファンの洗濯物リスト以外に）Feathersにとって有益だと思うことがいくつかあります。芯：

__長所：__

• 実験的なBabelプラグインに依存することなく、明確に定義された安定した環境で最新のES機能を使用する
• 使用しているランタイムに依存しない統一言語環境（ノード6を壊すasync/awaitやIEで機能しないES機能はもうありません）
• ツリーシェイクを使用してクライアント側のバンドルサイズを最適化できるESモジュールビルド（常に登場し、すぐにノードの一部になる可能性は低いもの）
• コード補完とインラインAPIドキュメント（現在、ほとんどのエディターでサポートされています）
• TS定義の問題はもうありません

__短所：__

• TSを知らない人が貢献するのを思いとどまらせるかもしれません
• コンパイル手順により、テストが遅くなり、追加のメンテナンス作業が発生する可能性があります
• 誰かがしなければならない仕事です
• TypeScriptのものをめぐるバイクシェッド（私の機能提案のいずれかが、TypeScriptの問題についての議論の一部を持っているとしたら、人々が実際にプロジェクトとしてFeathersを気にかけているように感じ、お気に入りのプログラミング言語が何であるかだけではありません）。

@dafflあなたの最後のプロと最後のコンへのクイックコメント。 私が言ったように、私はちょうど羽毛に入っていますが、定義に関するいくつかの問題が私を失望させました。 それが私がコメントしている最初の領域である理由です。 緩和要因は、 as anyスローするだけのtypescriptの柔軟性だと思いますが、私は「noany」コンパイラオプションをオンにするように努めています。 @eddyystopと@marshallswainに関しては、タイプスクリプトコードからタイピングを生成しないと、タイピングに関するコメントは実際には難しくなります。 （主に、oauthベリファイアやハンドラーなどの高度なトピックで）。 また、私は間違いなくtpyedが貢献するのが面倒だと思います。

また。 私は、主にタイプスクリプトのコードベースに貢献することに慣れているという理由で、この作業に参加したいと思っています。 しかし、羽毛を変える必要があるので、決してそれをとらないでください。 昔ながらのJavaScriptでも貢献できてうれしいです。

私は喜んでその仕事をすることを志願します、しかしデフォルトの輸出はいくつかを変える傾向があります。 この作業の例は私のフォークで利用できます。ここでは、基本的に、すでに記述されている宣言ファイルを統合し、明らかに適切であると判断したいくつかの引数タイプを追加しました。

テストはjsにコンパイルして、同じようにすばやく実行できます。 また、デフォルトのエクスポートセマンティクスが使用されていない限り、スクリプトは警告なしでコンパイルするために追加の型アノテーションをほとんど必要としません。

@NickBolles @thavlik Slackの#typescriptチャネルで同期できますか？ ここに要約を置きますが、計画が何であるか（そして、物事がどのように分割される可能性があるか）を理解する方がおそらく簡単です。

大規模なイントラネットを再構築している今、私は実際にこのフレームワークを検討していましたが、タイプ定義さえないのに、es5ミックスインに依存しているのでtypescriptに行きたくないですか？ これはどのような種類のちっぽけなおもちゃ、ミッキーマウスのジョークプロジェクトです。すべてのタイプスクリプトに向かって移動する世界は角度を付け、トップフレームワークは評価されたnr98「es5ミキシング依存フレームワーク」でトルクを生成します。先に、sails.jsでこれを検討しました

@duffmanすごい。 そこの袖口からの反応のようです。

typescriptタイプがあります。https：//github.com/feathersjs-ecosystem/feathers-typescriptを参照して

タイプスクリプトで書かれているフェザーは、タイピングの問題の可能性が高いことを除いて、ライブラリを使用しているユーザー（タイプスクリプトを使用しているかどうかに関係なく）とはほとんど関係がないことに注意してください。 フェザーとフェザーに加えてcli +を使用することを強くお勧めします。これにより、タイプスクリプトのスキャフォールディングが生成されます。問題はほとんどありません。これらの問題は、独自のインターフェイスを宣言するか、任意のインターフェイスにキャストすることで簡単に解決できます。 typscriptIMOのメリットを支払うための少額の価格

会話に建設的なものを追加する場合（羽をタイプスクリプトに変換するのを支援するなど）は、必ず貢献してください。ただし、そのコメントはかなり不正確で厳しいようです。 質問がある場合は、たるんだチャネルの方が適しているかもしれません。

この問題がこれ以上建設的な議論につながるとは思わないので、これを閉じるつもりであり、すでにいくつかの情報に基づいていないコメントと不必要な議論を求めています。 TypeScriptはFeathersv4以降でサポートされています。