Async: README 太长，无法使用 npm

这与 #859 相关。 一段时间以来，我们一直想重新修改 Async 的文档——创建一个更类似于 Lodash 文档的站点。

那太棒了，你需要任何帮助吗？ 不知道你离#859有多远。

我们还没有最终确定确切的构建策略（等着看对 Lodash 文档的类似推动是如何实现的）。 至少，我们希望将每个方法的文档复制到每个源文件中的 JSDoc 块中（带有完整的标签和类型信息），目的是解析它们并从中构建文档站点。

@hargasinski我们绝对可以在这方面使用帮助。 如果您或其他任何人有兴趣帮助将我们的文档移植到代码中的jsdoc兼容格式，我们将不胜感激。 我建议按方法执行此方法。 如果你有兴趣，我可以创建一个分支来工作，以便多人可以在必要时做出贡献

如果您正在寻找灵感，请查看

如果我们得到的代码处于 JSDoc 中记录的状态，我可以创建一个类似于 ramdas、lazys 或 lodashs 的文档站点

@megavac谢谢！ 我会研究 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 async 肯定没问题。 另外，nit：注意它是memberOf而不是memberof

对于站点，如何最好地记录 iteratee 和回调函数？ 在自述文件中，参数包含名称，例如 iteratee(item, callback)，但我认为这不适用于 jsdoc。

我实际上并不完全确定，有想法@jdalton？ 我知道 ramda 用自定义的@sig标签记录它

也根本不着急，这绝对是一项艰巨的任务，这就是我们一直在努力的原因。 感谢您调查它！

文档解析器通常会处理那一点。 如果不是，他们应该提供解析的输出供您重建。

是否可以轻松地将（例如） mapLimit和mapSeries到map ？ 您只需要说它们是并发限制版本。 否则会有很多重复的文档和示例。 （不过我认为保留签名是可以的）

嘿，只是一个快速更新，因为我在过去几天内无法对拉取请求进行任何提交。 我仍然会继续努力。 我有一点网络经验，所以我也一直在研究 lodash 站点维护问题。 一旦我的进度足够远，我将上传我的存储库。 目标是获得异步也可以使用的东西。

使用@hargasinski的更改（现在在 master 上）在本地生成文档。 我想我喜欢这个模板http://docstrap.github.io/docstrap/。 想法@hargasinski & @aearly

我以前用过 docstrap，我真的很喜欢它！ 这是一个干净的模板。 对主题有什么想法吗？ 我更喜欢蔚蓝或流明。 如果你想要更暗的东西，石板也很好。

另外，这是解决#975 的好时机吗？ 最好有网站的标志

Docstrap 看起来不错。 不过，我觉得搜索功能可以更好地工作。 主题并不重要，因为看起来我们可以轻松更改它。 （而且它们看起来都一样，除了一些颜色差异，或多或少。）

仍然关注https://github.com/lodash/lodash.github.io/issues/8和https://github.com/lodash/lodash.github.io/issues/15——因为这两个项目都是使用 JSDoc，我们可以重用他们采用的任何策略。

徽标可以等待，我们可以在漂亮的字体中使用“Async”，直到出现一个好的徽标创意。 :stuck_out_tongue_closed_eyes:

@megawac最近有没有关于发布我们的 JSDoc 的工作？ 在 2.0 版本发布之前拥有文档站点会很棒。

我在构建它们时运气不佳，并且在尝试在我的机器上正确编译 jsdoc 时遇到了几个问题

@aearly打算什么时候发布 2.0 版本？ @megawac目前，我无法做出时间承诺，但在接下来的 2-3 周内我应该有更多时间来帮助您解决此问题。 如果你能指导我朝着正确的方向前进，或者只是列出一些问题，我可以帮助慢慢解决它们。

我们没有发布日期——“什么时候准备好”。 文档不是硬性要求，只是一个重要的好东西，因为一些新方法只通过 JSDoc 记录。

@hargasinski主要是我以前从未使用过@jsdoc，并且一直在从多个文件中获取它。 我不知道如何让文档活在一页上。 我发现的另一个问题是让typedef实现（ queue和cargo ）正确显示

哦，好的，谢谢，我会分叉 repo 并稍微玩一下，尽管我要到下周晚些时候才能完成很多工作。 如果我有任何可行的方法，我会发布更新。