Less.js: ES6とロールアップ

いいえ。 私はしばらく同じ方針に沿って考えてきました。 TypeScriptの使用はどうですか？ コードヒント/実際のオブジェクトのリンクを作成すると、開発/貢献が容易になる可能性があります。 これが知識の負担/障壁になるかどうかはわかりませんが。

また、解析/ ASTにes6コレクションを使用し、 https：//github.com/Benvie/harmony-collectionsのようなes5ビルドにポリフィルを使用することを検討する必要があることも同じ考えでした。 es6環境（Node.jsは現在、最新のブラウザーと同様です）では、メモリオーバーヘッドが削減され、AST構築が高速化されるため、理論的には解析/評価が高速化されます。

TypeScriptの使用はどうですか？ コードヒント/実際のオブジェクトのリンクを作成すると、開発/貢献が容易になる可能性があります。 これが知識の負担/障壁になるかどうかはわかりませんが。

ES6の後-typescriptもes6トランスパイラーであるため、es6はtypescriptを排除しないと考えることができます。これはこの後の追加のステップになります。

かなりの余分な作業やリファクタリングが少なくなる場合を除いて、私は個人的にタイプスクリプトをお勧めしません。 IMOタイプスクリプト

• +タイプスクリプトを知っている新しい人々の開発を容易にします
• +保守性が向上します
• 
  
  • 人々が最小限のタイプスクリプトを知っているか学ぶ必要がある
  
  
• 
  
  • タイプされるようにコードを書くのに時間がかかります
  
  

また、解析/ ASTにes6コレクションを使用し、 https：//github.com/Benvie/harmony-collectionsのようなes5ビルドにポリフィルを使用することを検討する必要があることも同じ考えでした。 es6環境（Node.jsは現在、最新のブラウザーと同様です）では、メモリオーバーヘッドが削減され、AST構築が高速化されるため、理論的には解析/評価が高速化されます。

私はそのポリフィルを使用しません、プロジェクトは死んでいるように見えます（おそらく名前の調和が死んでいるためです）。

また、残念ながら、ES6ネイティブの同等のものがより高速であるかどうかはわかりません-https：//jsperf.com/property-access-object-array-map-weakmap/6 。 たとえば、Promiseポリフィルがネイティブ実装よりも高速であるのは悲しいことです:(

：+1：

すべての良い点。 ES6 / Babelで標準化すると、特にプロトタイプの継承を行う場合に、書き込みが簡単になるだけでなく、読み取りも簡単になることがよくあります。

そのjsperfテストに関する限り、それは実際には公正な例ではありません。 その特定のテストでは、Weakmapのパフォーマンスが遅くなると思います。 理論的には、Lessにとっては、さまざまなオブジェクトの形状とタイプを作成し、それらを評価する方がよい場合があります。 でもわからない。 ライブラリに「ベンチマークフック」を配置することなく、個々の関数にフックして詳細なベンチマークを実行できる、最終的にテスト（およびできれば追加）したいいくつかの優れたライブラリを見つけました。 Less.js内の関数に対して一種のjsperfテストを実行できるように、何かを設定したいと思っています（時間があれば、いつになるかはわかりません）が、ローカル開発/ブランチをLessとBranchに変更します。現在のリリースで、いくつかの種類のテスト.lessファイルを使用しています。 前に述べたように、特定のユースケースでどちらが速いかを推測する必要はありません。 理論的には、いくつかの関数レベルと生のオブジェクトでWeakMapをサブインし、その場所でベンチマークを実行し、結果に基づいて決定することができます。

@lukeapageは書いた：
IMOタイプスクリプト

• +タイプスクリプトを知っている新しい人々の開発を容易にします
• +保守性が向上します
• 
  
  • 人々が最小限のタイプスクリプトを知っているか学ぶ必要がある
  
  
• 
  
  • タイプされるようにコードを書くのに時間がかかります
  
  

そして、あなたがスキップしている1つの言及されていない、非常に重要な利点：
TypeScriptの型付きモードでは、安定した変数型を使用する必要があります。これにより、安定した型の形状が適用され、コードを静的および動的に分析するコンパイラの機能が向上し、最適化されたコードが生成され、からのバックアウトが停止（または少なくとも劇的に減少）します。最適化されたコードは、解釈の遅いコードに戻ります。

TypeScriptへの移行は、おそらくES6、imhoへの移行以上の貢献をするでしょう。

タイプモードとは、禁止することを意味しますか？

私は小さなプロジェクトでそれを試しました、そして私はいたるところに注釈を持っていました..それは終わります
トランスパイラーはそれほど賢くないので、たくさんのコードを使ってください。

変数タイプが変異している変数の数については、よくわかりません。 それで..
パフォーマンス上の利点が顕著になるとは確信していません。

@rjgotten TypeScriptを使用したことはありませんが、それは良い点です。 TypeScriptにインテリセンス/オートコンプリート環境を使用している場合は、変更を加えるとタイプ/オブジェクトの形状が完成するため、実際には新しい貢献者に役立つ可能性があります。 適切に設計されていれば、コードの変更に貢献している人にとって、一種の自己文書化/習熟/エラー防止ツールとして機能する可能性があります。 しかし、そこにある鍵はおそらくTypeScriptの設計にあります。

全体として、パフォーマンス上のメリットはありますか？ それを判断するのは難しいです。 それはキャンバスよりもアーティストです。

私は自分のプロジェクトでTypeScriptを使用することを目指していますが、 @ lukeapageに同意する傾向があります。主な理由は、ここにいる私たちのいずれかがTypeScriptの専門家でない限り、効果的に使用できるかどうかわからないためです。最初にそれの。

また、ES6に移行しても、将来TypeScriptを使用できなくなることはありません。 Microsoft / Googleの目標は、TypeScript 2.0をES6スーパーセットにすることです。そのため、いつでもES6 / Babelから始めて、後で適切なタイプを追加し、TypeScriptトランスパイラーに切り替えることができます。 私の疑惑は、コンパイル時/オートコンプリートの利点が型指定されていないJavaScriptよりもはるかに大きいという理由だけで、TypeScriptがトランスパイルされた言語を「勝ち取る」ことになるということです。 だから...それはTypeScriptの使用はおそらく避けられないと思うことを意味すると思いますが、それは私たちがすぐにそれを使用しなければならないという意味ではありません。

ある時点で、Lessに対する別のアーキテクチャのアプローチについて説明したいと思いますが、それはこれに対する接線的な議論です。

タイプモードとは、禁止することを意味しますか？

いいえ。一般的に型変数を使用するだけです。 一般的にAnyの使用を禁止することはできますが、タイピングシステムを満足させるために多くのコードの膨張を引き起こす傾向があるため、（少なくとも実際には）悪い考えです。

ただし、関数で型付きパラメーターを使用するということは、呼び出し元（TypeScriptで記述された少なくとも呼び出し元）が指定された型を尊重する必要があることを意味します。 つまり、型付き関数を使用して、必要に応じてLessコンパイラの内部動作の型の安定性を保護し、特に重要な関数が十分に最適化されることを保証できます。 （忘れないでください。JSエンジンは通常、機能レベルで最適化されます...）

作業が開始されました-https：//github.com/less/less.js/tree/rollup

かなりクールな仕事。 議論へのGermaine、私はコードを見ていました、そしてすぐに出くわしました：

if (typeof index === 'number') {   

TypeScriptでは、このタイプの健全性チェックは必要ありません。 値の型をチェックするために文字列比較を行うために、実行時にインデックス型が毎回文字列に変換されている場合、そのようなことが加算される可能性があります。 TypeScriptでは、インデックスを渡した関数の呼び出しがあったが、そのタイプが数値ではなく、インデックスが数値のみである場合、関数はコンパイル時に、必要ではなく、型の不一致が原因で失敗していました。このようなチェックの費用が高い場合は、実行時にテストする必要があります。

一方、これは孤立したまれな例である可能性があります。 それは私が出くわしたものであり、関連性があるように思われました。

明示的な型の最大の利点は、より強力なツールを使用できることだと思います。 関数を呼び出したり、関数をオーバーライドしたりするすべての（そして唯一の）場所を見つけるには、キーボードショートカットを使用するだけです。 使用可能なオブジェクトの機能を見つけることはゼロ作業であり、コンパイラーがより多くのエラーを生成するため、リファクタリングはより安全です。 また、新しいコードベースの学習も容易になります。全体像を把握したり、コードのどの部分が依存しているかを調べたり、実行せずにコードフローに従うことは、型付きエディターの方が強力であるため、javascriptではjavaよりも難しくなります。

私はまだTypeScriptを使用していなかったので、ツールがそれだけの価値があるほど成熟しているかどうかはわかりません。 javascriptの利点は、誰もがそれを知っていることです。TypeScriptはあまり知られていません。

全体として、TypeScriptへの移行は、ある種のより大きなリファクタリングや巨大な新機能を計画した場合には意味があると思いますが、小さなバグを修正しているだけでは手間がかかりすぎる可能性があります。

TypeScriptへの移行は、ある種のより大きなリファクタリングや巨大な新機能を計画した場合には意味があると思いますが、小さなバグを修正しているだけでは手間がかかりすぎる可能性があります。

これは事実かもしれません、そして実際には、 @ lukeapageはすでに仕事を引き受けているので、私は彼がこの時点で最後の電話をかけるべきだと言いたいです。 :-)

ねえ、これについて：コードベースが変更されていることを人々に知らせるために私たちがすべきことはありますか？ そうしないと、マージの競合が発生すると思います。

いいえ、あまり多くの衝突があってはなりません。 最初のステップはes6モジュールだけです-ではありません
ファイルを移動すると、babelまたはtypescriptを透過的に追加できます。

こんにちは、みんな、今はどうですか？

私はこれに取り組むことができます。 @ matthew-deanプルリクエストを受け入れますか？

@alexlur確かに！ 私の唯一の懸念は、 3.xブランチのリファクタリングであり、マージの競合が発生しないことです。 したがって、そこからフォーク/ブランチする方がよいでしょう。 また、この問題が書かれたので、今ではsrc/とdist/を使用するという確立された規則があります。 ただし、 lib/はsrc/として使用されることがあるため、名前を変更する必要はおそらくありません。

また、Gruntfileを少し書き直して、テストでlib/ではなくビルドを使用するようにします。 （ブラウザのテストでは、 dist/ test/でビルドを実行します。 dist/フォルダは新しいリリース用の特別なGruntタスクです。テストする場合は、次のようにビルドする必要があります。 test/ ）それを行った後、テストに合格する限り、あなたは元気になるはずです。

@ matthew-deanこんにちは。 リファクタリングは完了しましたが、新しくビルドされたファイルでテストを実行するようにGruntfileを構成する方法がわかりません。

たぶん私にできることは、変更を別のブランチにマージして、テストの統合について確認することです。 私はあなたの変更をすぐに調べていました。 私が間違っている場合は訂正してください。ただし、 at-ruleはassignmentノードが間違っていますか？ それとも、Githubがそれをどのように示しているかをめちゃくちゃにしていたのでしょうか？

良いキャッチ、私は間違ったファイルを使用しました。

less.jsがサポートしなければならないブラウザ/Node.jsの最小バージョンはありますか？ Node.jsはPromise （0.12以降）をかなり適切にサポートしていますが、ブラウザーでの使用は通常、とにかく最新のブラウザーバージョンを既に実行している開発者向けです。

編集：

Less.jsは、最新のすべてのブラウザー（Chrome、Firefox、Safari、IE11 +、およびEdgeの最近のバージョン）をサポートします

Internet Explorer 11にのみPromiseが組み込まれていません。

@alexlur
ブラウザー内バージョンのLessの場合、 less.Promiseプロパティを作成し、デフォルトwindow.Promiseに設定することをお勧めします。 そして、Lessにless.Promiseを介してPromiseクラスを消費させます。

このようにして、最新のブラウザのユーザーだけでなく、Lessがロードされる前にPromiseをグローバルにポリフィルしたユーザーも、すべてが魔法のように機能します。 そして、グローバルにポリフィルすることを望まないユーザー、または何らかの理由で許可されていないユーザーは、1つの小さな追加ステップで物事を機能させることができます。 実際にLessを使用する前に、選択したPromise実装をless.Promiseに手動で割り当てるだけで済みます。

@rjgotten @alexlur Less.jsには、すでにPromiseポリフィルが設定されています。 そこで追加の作業を行う必要はありません。 ほとんどのコードはこのパターンを使用しています。

https://github.com/less/less.js/blob/55380d49e96a6ed561cac4d13a774830aa3c17a3/lib/less/import-manager.js#L5

ノード側では、この問題がまだ開いています： https ：//github.com/less/less.js/issues/3121

ただし、フィードバックがなく、貢献者の数もかなり多いので、今のところはノード4+が最適だと言いたくなります。 それを反映するようにドキュメント/テストを更新する必要があります。

@ matthew-dean別のブランチにマージする準備ができている必要があります。

@alexlurありがとう！ すぐに見てみようと思います。 おそらく来週になるでしょう（他の誰かがそれをチェックするための余裕がない限り）。

この問題は、最近のアクティビティがないため、自動的に古いものとしてマークされています。 それ以上のアクティビティが発生しない場合は閉じられます。 貢献していただきありがとうございます。

TypeScriptにリファクタリングされたフォークを作成しました。

TypeScriptにリファクタリングされたフォークを作成しました。

@glixlur😮すごい、そしてすべてのテストに合格しますか？ そして、同じless.jsをdist/でビルドしますか？

@ matthew-dean私はまだ取り組んでいますが、ブラウザ用のビルドでは、毎日のドライバに関しては問題は発生していません。 技術的にロールアップを使用すると、フォークのパフォーマンスが向上しますが、バックアップするデータがありません。

@ less / coreこれを調査して、1回限りの変換でこれを自動化できるかどうかを確認する必要があります-https：//github.com/lebab/lebab

@ matthew-dean完了したら、プルリクエストを送信します。

@glixlurああ！ さて、あなたの以前のPRで、あなたはこれのための時間がなかったと言いました。 あなたがまだこれに取り組んでいるなら、👍

@ matthew-dean ES6に変換するだけに制限し、後でTypeScriptの部分を残します。

@glixlur ES6はおそらく、前進するための最も「コミュニティに優しい」最初のステップだと思うので、それは完璧です。 誰もがTypeScriptに参加しているかどうかはわかりませんが、ES6フローは間違いなく素晴らしいでしょう。

@ matthew-deanサポートされているプラ​​ットフォームの中で最も低いのはノード6とIE11だと思いますか？

@glixlur Appveyorは現在、ノード4をテストするように設定されています。 理想的には、それはBabelになります-ノード/ブラウザー用に配布するために、 src/フォルダーを（置換された） lib/ （およびブラウザーの場合dist/ ）フォルダーに変換します。 したがって、BabelがES5へのトランスパイルのほとんどの作業を行っていると思います。

完了しましたが、テストを機能させる必要があります。 PhantomJSは非推奨であり、ES5以降はサポートされていません。

@glixlurいいね！ Re：PhantomJS、それは本当にChromyのようなものに置き換える必要があります。 参照： https ：//github.com/less/less.js/issues/3240

@glixlurまた、これはChromy /ヘッドレスChrome関連です： https ：//github.com/less/less.js/issues/3262

@glixlur PhantomJSに関して-これらのテストは、バンドルされたブラウザーバージョンに対して実行されています。これは、おそらくES5にトランスパイルすることになるでしょう。 PhantomJSがES5出力バンドルで機能しないのはなぜですか？

@ matthew-deanはい。ただし、Babelでトランスパイルされたファイルを使用してPhantomJSを実行すると、 Symbolが使用されるというバグがあります。

@glixlurトランスパイルされた出力にはbabel-polyfillが必要です。 これは、まだ正しくトランスパイルされていないことを示す良い指標です。 次のような問題を参照してください： https ：//github.com/babel/babel-preset-env/issues/203

@glixlur https://babeljs.io/docs/en/babel-polyfill/

@ matthew-dean babel-polyfillは、87.3KBの縮小を出力ファイルに追加します。 あなたはおそらくそれを望まないでしょう。

@glixlur
babel-polyfillを望まない理由は他にもあります。 つまり、 windowでポリフィルを公開し、 Arrayのようなネイティブ型のプロトタイプを変更することで、グローバル名前空間に影響を与えるという事実。

代わりに、 babel-runtimeとbabel-plugin-transform-runtimeパッケージを調べてください。

また、iirc the Babelチームは、 babel-envプリセットが言語変換を制限するのと同じ行に沿って、 transform-runtimeによってバンドルされるポリフィルを制限することに取り組んでいます。 しかし、それに関する彼らの作業はまだ行われておらず、一般に利用可能です。 とにかくまだベータ版であるため、直接有用ではないBabel7のものになってしまいます。 しかし、将来的には間違いなく望ましい。

@ glixlur @ rjgottenああ。 re：Babelを使用するソリューションが正確にわからないことを明確にすべきでした。 Symbolはポリフィルされていない（ポニーフィルされている？）ために未定義であるためです。これはIE11にもあります。 したがって、ポリフィルではないかもしれませんが、適切なBabel設定を使用すると、スコープ付きのSymbol定義が得られるはずです。 それで、多分それは問題である最小のブラウザバージョンですか？

適切なBabel設定を使用すると、スコープ付きのSymbol定義が得られるはずです。

確かにそうなるでしょう。
これらの設定は、 babel-polyfillに依存する代わりに、 transform-runtimeプラグインと、 Symbolなどの新しいビルトインのエイリアスを挿入する機能を使用することになります。

phantomjsは非推奨にする必要がありますか？

死んだと思って？
多分そう。

@glixlur参照： https ：//github.com/less/less.js/issues/3240

変換が完了し、マージされました！ 参照： https ：//github.com/less/less-meta/issues/32

ウェルプ、今週私はJavaScriptのClassが関数プロトタイプの単なる構文糖衣ではないことを学びました。これがこの問題の原因でした： https ：//github.com/less/less.js/issues/3414

皮肉なことに、私は2週間前のように、Lessに関係のない別のコードでまったく同じことを見つけました。そして、私が思いついた考えをはっきりと思い出します。

ねえ、LessへのES6変換がこのタイプの問題を引き起こすのではないかと思います。

ええと：質問は答えました、私は推測しますか？

@ matthew-deanさん、私はあなたの仕事に不満を注いだユーザーの嵐をうらやましく思いません。 あなたはその状況に対処しなければならない私の同情を持っています。 ：笑顔：
幸いなことに、誰も終末論にならなかったようで、それは整然と扱われました。

@rjgotten lolつまり、どうやってそのようなことを予想できますか？ 最も安全なのは、変換をまったく行わないか、クラスを使用しないことですが、コードベースの冗長性が低くなります（まあ、または潜在的には、さらにクリーンアップする機会がたくさんあります）。 技術的には、Lessとの（歴史的な） less-loader統合はAPIの誤用（APIの文書化されていない/サポートされていない使用法の使用）であったため、それは彼らの側の間違いでしたが、私は不満を持っている人々に同情しますビルドの失敗を引き起こす非メジャーポイントリリース。

たとえば、誰かがライブラリのプロトタイプをハッキングした場合、そのためにどのように防御的にコーディングしますか？

🤷‍♂

@rjgotten

技術的には、変換後に2つのベータバージョンをリリースしましたが、パイプラインにベータが少ない人は誰もいません。 したがって、Lessと統合してテストを実行する800,000のリポジトリをテストする方法はありません。 NPMの依存関係がある場合は、実際にそれを公開して、何が壊れているかを確認する必要があります。

将来私たちができることの1つは、テストに依存度の低いものを追加することです。

私ができたもう1つのことは、メジャーバージョンとしてリリースすることですが、技術的には（意図的な）重大な変更はありません。つまり、サポートされている機能は同じであり、いくつかのバグ修正が含まれています。 ..わからない、これはトリッキーなものだった。

うん。 トリッキーなものでした。

.nextタグなどに何かを入れて、それを使ってビルドパイプラインをテストするように人々に気付かせることもできたと思います。 しかし、過去の経験は、そのようなことは一般的に前代未聞であることを示しています。

いずれにせよ、メジャーバージョンであろうとなかろうと、おそらく「やってみる」だけで何が壊れているかを確認することを余儀なくされることになるでしょう。

ただし、誤解しないでください。リファクタリングは非常に良いことです。 前進することは、一般的に、メンテナンスの負担からかなりの部分を取り除くはずです。

たとえば、誰かがライブラリのプロトタイプをハッキングした場合、そのためにどのように防御的にコーディングしますか？

あなたは文字通りしません。

これは、C＃でプライベートメンバーにアクセスするために慎重に調整されたランタイムから排出されるILが、マイナーリリース間で中断することを不満に思っているようなものです。 内部に干渉する場合は、何を購入しているのかを知っておく必要があります。 ：笑顔：

@rjgottenリファクタリングといえば...

..... Lessコードベースで時間をかけて発見したことの1つは、AST内のオブジェクトにわずかな/微妙な変異がある場所がいくつかあることです。 ここに新しいプロパティ/そこにインスタンスに追加されたメソッド。JavaScriptでは、いつでも好きなときに好きなように変更できるため、マージした機能を使用してこれを行ったことを完全に認めます。そのプロパティを文書化/定義したかどうか。

TypeScriptと最新のJSだけが答えになるかどうかについていくつかの議論がありました。 タイプや明確なオブジェクトインターフェイスがないため、Lessコードベースが、ドキュメントの量が解決できない、またはJSDocsでさえ解決できない方法で推論するのが非常に難しい場合があることに気付きました。

TypeScriptがJSDocで適切な型を使用できるように新しいパイプラインを設定しましたが、入力にJSDocを使用すると、TypeScriptよりも冗長で視覚的にノイズが多くなります。TSがJSDocアノテーションだけではサポートしない入力機能がいくつかあります。 。 TSが無料で提供するこれらの問題のいくつかを解決できるツールのJSDoc / ESLintの組み合わせはありません。

つまり、私が言っているのは、昨年TypeScriptを大幅に使用し、Lessコードベースで何年も過ごした後、Lessがどのように機能するかを理解するための混乱/フラストレーション/学習曲線の95％だと思います。オブジェクトにコンパイル時の型が適用されている場合は回避されています。 ファイルでの定義方法ではなく、ブレークポイントを設定し、オブジェクトのプロパティが実際に何であるかを理解するためだけに、デバッガーで多くの時間を費やしてきました。

たとえば、Lessには、評価中にRulesetノードのpathsプロパティに依存する機能がいくつかあります。 このコンストラクターから、 pathsプロパティとは何か、そしてそれがどのような形になるかを教えてください。 （ヒント：そこにないので、できません。）

TypeScript（一般的なtsconfig設定を使用）では、これは許可されません。 コンパイルすらしません。 pathsの形と、その中にあるものを正確に指定する必要があります。これにより、コードベースを探索している人に明確で具体的なドキュメント（およびコードヒント）が提供されます。

ですから、この時点で、「TypeScriptは考慮すべきものだ」という考えから、「公開プロジェクトがTypeScriptにない場合は、大きな技術的負債がある」という感覚に変わったと思います。 本質的に消費性と保守性を解決するのに役立つので、私はそれなしでオープンソースリポジトリを開始することは決してありません。 それでも明確なドキュメントが必要ですが、少なくともそれは非常に明確でまとまりのあるコーディングを強制します。

それは私がここからどこへ行くべきか、そして将来の問題点を防ぐ方法を考えているだけです。

_（補遺：明確でない場合は、Lessコードベースで誰かの歴史的な仕事を100％バッシングしていません。私が提案し、賛同を得て、コードベースにマージしたものはたくさんあります。 「ああ、そうしなかったらよかったのに」とか、違うやり方でやったらいいのにと思ったのですが、今は保守性に悪影響を及ぼしているかもしれないと気づいたことを確かに追加しました。みんな頑張っています。）_

@ matthew-dean
JSDocに適切な型がある場合にTypeScriptリンティングを許可するように新しいパイプラインを設定しましたが、タイピングにJSDocを使用すると、TypeScriptよりも冗長で視覚的にノイズが多くなります。TSがJSDocアノテーションだけではサポートしないタイピング機能がいくつかあります。 。 TSが無料で提供するこれらの問題のいくつかを解決できるツールのJSDoc / ESLintの組み合わせはありません。

実際; 私はJSDocサポートがまあまあであるという問題に遭遇しました。型推論についてもそうです。
幸いなことに、 .js .d.ts宣言ファイルを使用できます。その場合、TypeScriptを完全に使用したり、コンパイラを要求したりする必要はありません。

以前は宣言ファイルを操作するのが非常に困難でしたが、TypeScriptのコンパイラの最新バージョンでは、両方に名前が付けられている限り、 .d.tsファイルを.jsファイルと並べて自動的に関連付けます。同じ。

それはあなたが探しているものかもしれません。

@rjgottenこれがLessのコードベースでどのようにうまく機能するかについて、もう少し説明できますか（または、優れたリソースを知っている場合はリンクしてください）。 のように、ファイルレベルでこれをどのように行いますか？ .jsモジュールごとに$ .d.tsファイルはありますか？ それともグループ化しますか？

ソースでTypeScriptを使用する場合と比較して、 .d.tsファイルを使用する利点は何ですか？ ファイルでこれらのタイプを定義するだけでなく、なぜ.d.tsファイルの作成に時間を費やすのでしょうか。

@rjgotten今日、私はChevrotainの開発者と話をしていましたが、彼はTS _BUT_で開発していると言っていますが、実際には別の関心事としてapi.d.tsファイルを管理しています。 そうすれば、ソースファイル（ツリーノードなど）でタイプを変更しても、APIタイプファイルを明示的に変更しなくても、パブリックAPIが透過的/不可視に変更されることはありません。

次に、内部タイプとパブリックAPIタイプが一致するというアサーションを使用したテストを使用します-> https://github.com/SAP/chevrotain/blob/master/packages/chevrotain/test_integration/definitions/api_type_checking.ts#L1- L2

Chevrotainの方法は、パブリックAPIが誤って変更されないようにするための優れた方法です。 そのレベルの保護が必要だと思われる場合は、非常に堅牢です。 ただし、オーバーヘッドも発生します。

.js型を保持するための.d.ts宣言ファイルの使用について：
それは実際には両方です。

それらが並んでいる場合、自動提案、リンティングなどのためにTypeScriptコンパイラによってサポートされているIDEは、自動的にタイピングを取得します。 並べて入力するスクリプトがnode_modulesからインポートされた場合は、Afaik_also_です。これは非常に便利です。

型付けをapi.d.tsのような単一の（セットの） .d.tsファイルに入れてから、JSDocを使用して宣言された型を明示的にインポートすることもできます。 TypeScriptでのJSDocサポートには、インポート構文を使用した場合の特別なフレーバー@typedefがあります。 例えば

/**
 * <strong i="17">@typedef</strong> {import("../api.d.ts").MyType } MyType
 */

配布前にパッケージをトランスパイルステップで実行する必要がある場合は、バンドルされた単一のタイピングファイルを使用することをお勧めします。 このような場合、ユーザーが実際にrequire()またはimport {}になるものは、元のソースファイルではなくなります。 つまり、並べて入力してもメリットはありません。