Async: READMEが長すぎてnpmになりません

作成日 2016年03月24日  ·  21コメント  ·  ソース: caolan/async

READMEの最後の4つの関数(log、dir、noConflict、timeout)は、npmWebサイトには表示されません。

https://www.npmjs.com/package/async

bug docs

最も参考になるコメント

それは素晴らしいことです。何か助けが必要ですか? あなたが #859 のどこまで進んでいるのかわかりません。

全てのコメント21件

これは、接線方向に#859に関連しています。 しばらくの間、Asyncのドキュメントを刷新したいと思っていました。Lodashのドキュメントに似たサイトを作成してください。

それは素晴らしいことです。何か助けが必要ですか? あなたが #859 のどこまで進んでいるのかわかりません。

正確な構築戦略はまだ確定していません(Lodashのドキュメントに対する同様のプッシュがどのように機能するかを確認するのを待っています)。 少なくとも、各メソッドのドキュメントを各ソース ファイルの JSDoc ブロックに (完全なタグと型情報とともに) コピーし、それらを解析してドキュメント サイトを構築することを目的としています。

@hargasinski私たちは間違いなくこれで助けを使うことができます。 私たちのドキュメントをコード内のjsdoc互換のフォーマットに移植することに関心がある場合は、大変助かります。 この方法を方法ごとに行うことをお勧めします。 興味があれば、必要に応じて複数の人が貢献できるように、作業用のブランチを作成できます

インスピレーションを探している場合は、 https: //github.com/lodash/lodash/blob/master/lodash.js#L8428-L8470を

JSDocに文書化されている状態のコードを取得すると、ramdas、lazys、またはlodashsに似たドキュメントサイトを作成できます。

@megawacありがとうございます! lodashがどのようにそれを行うかを調べます。 明日は休みなので、かなりの時間を費やすことができそうです。 どこまで到達したかについてコメントを投稿します。

これにかかる時間を過小評価していたかもしれませんが、収集方法のドキュメントを完成させることができました。 明日は仕事が終わって残りを終えられるはずです。 プルリクエストを作成したので、これまでに行ったことと、何か変更が必要かどうかを確認できます。 簡単な質問がいくつかあります。

  1. 実際のasyncコンストラクターがないので、 @ memberOfタグを含め続ける必要がありますか?
  2. @megawacこのサイトの場合、 iteratee callback関数とiteratee(item, callback)などの名前が含まれていますが、これはjsdocでは機能しないと思います。 私は次のように何かやってきたlodashのように、あなたがリンクされている例を、そしてちょうど@paramの説明の最後の行として署名を含むInvoked with (item, callback) 。 jsdocサイトは次のようなものを推奨しています:
/**
 * Send a request.
 * <strong i="19">@param</strong> {requestCallback} cb - The callback that handles the response.
 */
Requester.prototype.send = function(cb) {
    // code
};

/**
 * This callback is displayed as a global member.
 * <strong i="20">@callback</strong> requestCallback
 * <strong i="21">@param</strong> {number} responseCode
 * <strong i="22">@param</strong> {string} responseMessage
 */

実際の非同期コンストラクターがないので、 @ memberOfタグを含め続ける必要がありますか?

memberOf非同期は確かに問題ありません。 また、nit: memberofではなくmemberOfあることに注意してください

このサイトの場合、iteratee関数とcallback関数を文書化するのが最善でしょうか? readmeには、iteratee(item、callback)などの名前がパラメーターに含まれていますが、これはjsdocでは機能しないと思います。

私は実際には完全にはわかりません、@ jdaltonについて考えましたか? ramdaがカスタムの@sigタグでそれを文書化していることを私は知っています

また、これを急ぐ必要はありません。これは間違いなく大きなタスクであり、それが私たちがそれをパントし続けている理由です。 調べてくれてありがとう!

Docパーサーは通常そのビットを処理します。 そうでない場合は、再構築するための解析済み出力を提供する必要があります。

(たとえば) mapLimitmapSeriesmapに簡単にリンクすることは可能ですか? あなたが言わなければならないのは、それらが同時実行制限バージョンであるということだけです。 そうしないと、多くの重複したドキュメントと例が発生することになります。 (ただし、署名を保持することは問題ないと思います)

ねえ、私は過去数日間プルリクエストにコミットすることができなかったので、ちょっとしたアップデートです。 私はまだそれに取り組んでいくつもりです。 私は少しウェブの経験があるので、lodashサイトのメンテナンスの問題も調べています。 リポジトリが十分に進んだら、進捗状況とともにリポジトリをアップロードします。 目標は、asyncでも使用できるものを取得することです。

@hargasinskiの変更(現在はマスター上)をいじりまわします。 私はこのテンプレートhttp://docstrap.github.io/docstrap/が好きだと思い@ hargasinski@ aearlyの考え

私は以前にdocstrapを使用したことがあります、私はそれが本当に好きです! きれいなテンプレートです。 テーマについて何かアイデアはありますか? 私の好みはセルリアンまたはルーメンでしょう。 もっと暗いものを探したいなら、スレートもいいです。

また、これは#975に対処する良い機会でしょうか? サイトのロゴがあるといいでしょう

Docstrapはかなりよさそうだ。 ただし、検索機能はもっとうまく機能すると思います。 テーマは簡単に変更できるように見えるので、あまり重要ではありません。 (そして、それらはすべて同じように見えますが、多少の色の違いを除いて、多かれ少なかれです。)

それでも目を保つhttps://github.com/lodash/lodash.github.io/issues/8https://github.com/lodash/lodash.github.io/issues/15 -両方のプロジェクトであるため、 JSDocを使用すると、採用した戦略を再利用できます。

ロゴは待つことができます。良いロゴのアイデアが浮かぶまで、素敵な書体で「Async」を使用できます。 :stuck_out_tongue_closed_eyes:

@megawac JSDocの公開に関する最近の作業はありますか? 2.0リリースの前にドキュメントサイトを設置しておくと便利です。

私はそれらをビルドするのに不運があり、私のマシンでjsdocsを適切にコンパイルしようとしていくつかの問題に遭遇しました

@aearly 2.0リリースを計画しているのはいつですか? @megawac現在、私は時間の約束をすることはできませんが、あなたがこれに取り組むのを助けるために、次の2〜3週間でもう少し時間が必要です。 あなたが私を正しい方向に導くことができるか、またはいくつかの問題のリストだけを教えてくれるなら、私はそれらをゆっくりと削り取るのを手伝うことができます。

リリース日はありません-「準備ができたら」。 一部の新しいメソッドはJSDocを介してのみ文書化されているため、ドキュメントは難しい要件ではなく、非常に便利なものです。

@hargasinskiは主に、これまで@jsdocを使用したことがなく、複数のファイルからの調達に問題がありました。 ドキュメントを 1 ページに表示する方法がわかりませんでした。 私が見つけたもう1つの問題は、 typedef実装( queuecargo )が正しく表示されること

ああ、ありがとう。レポをフォークして少し遊んでみますが、来週の終わりまで多くのことを成し遂げることはできません。 実行可能なことがあれば、更新を投稿します。

このページは役に立ちましたか?
0 / 5 - 0 評価