Axios: 项目死了？

并且自 9 月以来没有在 master 中提交。 尚无支持 HTTP2 的计划。

是的，最近有点想知道同样的事情......

它还没有死，我只是最近没能亲自在这个项目上做那么多。 我们在修复配置方面遇到了一个大问题，它引入了破坏性更改，在修复之前停止了工作。

所以是的，如果有人愿意作为维护者挺身而出并提供帮助，我欢迎他们！

@emilyemorehouse也许在 README.md 中做广告是个好主意，我相信有人想提供帮助。

@emilyemorehouse作为

诚然之前没有使用过这个项目，但通常会发现在 github 周围挖掘，很高兴在我的空闲时间阅读一些 PR。

使用 ES 模块的新版本会非常棒🙊

嗨@emilyemorehouse ，我很乐意帮忙。

我认为对问题进行分类或标记将有助于新志愿者知道从哪里开始......

我很乐意提供帮助，无论是分类、积极贡献还是其他任何事情 🤙

@emilyemorehouse我很乐意帮忙！ 为了鼓励贡献者，在问题上有某种标签（例如，“适合初学者”或类似标签）可能会很好！

我使用 axios 一年多了。 我可以帮助修复错误。

我很乐意做出贡献。 到目前为止，我在 4 个项目中使用了 axios，它始终是我的首选。

我可以帮忙，告诉我从什么开始:)

我想我们应该从稳定 1.0.0 版本的路线图开始，然后分成带有“需要帮助”标签的问题。

算我一个。

作为 axios 的重度用户，能帮上忙就好了。 :)

我没有太多的贡献历史，但​​我在项目中使用 axios。 我很乐意提供帮助。

作为 axios 瘾君子，我很乐意提供帮助

@mzabriskie @emilyemorehouse请告诉我我们如何提供帮助！

我很乐意帮忙。

我也很乐意帮忙。

我很乐意协助维护这个项目。 我已经使用它多年了，很乐意帮忙，@emilyemorehouse。 ：心：

我也会帮忙的。 :)

在十几个项目中使用 axios 给我带来了很多乐趣。 我会喜欢帮助一点：sun_with_face：

我也想帮忙😄

我想贡献和维护，让我知道从哪里开始

我一直在使用 axios，并且在多个项目中使用，我很乐意以任何可能的方式提供帮助

很乐意帮忙。

我很高兴为 axios 做出贡献

我也很乐意帮忙。

很想开始贡献，到目前为止我的所有项目都使用它一年了，我想帮助它保持健康。

不过，对于从哪里开始的某种类型的指导将不胜感激！

我很乐意提供帮助，因为我广泛使用了 axios。

😭你们都很棒。

对于任何想提供帮助的人，以下是我的一些想法：

• 分类问题：我最近添加了问题模板来帮助自动标记问题（并过滤掉实际的错误与使用问题）。 这个项目有_很多_噪音，我花了大部分时间试图过滤问题，最后用一个简单的“这似乎不是 Axios 错误（很多我什至无法复制）来关闭大部分问题” ，我认为 X 可能是您的问题，请随时在 Gitter 或 Stack Overflow 上发帖以帮助调试您的代码”。 如果你发现一个没有示例代码的真正错误，提供示例代码是一个巨大的帮助。 如果它像复制/粘贴到Runkit一样简单，并调用示例 API（如JSON Placeholder ），则加分。
• 公关评论：不像问题那么嘈杂，但这仍然有很多事情要做。 我真的很感谢那些在 PR 中标记我的人，这些 PR 具有高优先级/修复已知问题。 如果几天后我没有回复，请随时 ping 我。 目前，重点肯定是在关注新功能或1.0.0之前使事情稳定。
• CI：我们的 CI 很挑剔——我们经常遇到奇怪的边缘情况或问题，导致 CI​​ 中断并减慢整个过程。 如果我们有一个损坏的主分支，我无法发布，简单明了。 因此，如果您曾经看到 master 失败（或者 PR 因非 PR 引起的问题而失败），非常感谢您提供的任何帮助。

我很高兴根据需要为任何人提供访问权限。 我唯一想坚持的是充当发布经理以确保一致性。

我计划将此信息与我的响应模板一起添加到贡献文档中，供其他人使用，以及如何标记问题的指南等。

@emilyemorehouse我在 reddit (https://www.reddit.com/r/javascript/comments/an94xq/axios_needs_maintainers/) 上发布了一个求助请求——如你所见，你的作品有很多粉丝。 我期待着开始贡献并再次-谢谢。

@emilyemorehouse很乐意提供帮助。

@emilyemorehouse我很乐意帮忙

@emilyemorehouse我也很乐意帮忙！

这似乎是一个矛盾。

• 没有贡献， @emilyemorehouse无法区分有用的人并授予权限。
• 没有权限，人们通常不会开始贡献。

我建议大家先尝试订阅代码助手。 如果我们能坚持对问题进行分类或发送拉取请求， @emilyemorehouse会更高兴看到。 总有一天，你会自然而然地成为一名维护者。

我使用 axios 并且目前并不担心缺乏持续的开发（工具通常不会在维护者离开的那一刻爆炸），但是如果有人真的很想走并想开始合并 PR，请注意这是一个开放的源项目，并且没有成本（除了时间）分叉并开始审查并将 PR 合并到您的分叉。 这可能是开源工具生命周期中的一个自然进展，并且这项工作也可以在 Emily（或她的团队）有时间恢复时合并回 axios。

不是说“去 fork 吧”，而是“如果你感到沮丧或感觉这个项目已经‘死了’，你不需要许可就可以让它恢复生机。” 权力是你的！ 🌍

可能在该主题的进一步合作中存在分歧会很好。 此外，这里还没有关于“97 个打开的拉取请求”的任何答案。

@emilyemorehouse @mzabriskie @nickuraltsev @rubennorte - 你对

@Sequoia你说得对，但是当有这么多未解决的问题和 PR 时，这有点困难，甚至很难决定哪些仍然有效。 @emilyemorehouse 2 个月前写了一篇关于我们如何提供帮助的文章——第一件事是解决所有问题并进行一些清理:)

看到这么好的项目慢慢消亡，我很难过。 它确实是我在 nodejs 中使用的最好的 http 客户端。

👍

@emilyemorehouse
我曾经是tldr-pages 的核心团队成员。 当时项目作者有一些家庭问题，我的第二个孩子出生了。 我知道我们不会自己做，我们在核心团队中增加了 3 名新成员来帮助我们审查 PR。

你正在从事一个非常重要的互联网项目。 它不应该被放弃。 上个月提出了8个PR，没有一个被合并。 更重要的是，发布了一个已知的安全漏洞（https://snyk.io/vuln/SNYK-JS-AXIOS-174505），还有 PR #1485 也没有合并。

有了这么多 PR，如果你们开始接受帮助会更好。 有很多人会为成为这样一个项目的维护者而感到自豪。 他们中的一些人已经在这个线程中提出了帮助。 增加贡献者的数量。

祝你好运！

• 分类问题：我最近添加了问题模板来帮助自动标记问题（并过滤掉实际的错误与使用问题）。 这个项目有_很多_噪音，我花了大部分时间试图过滤问题，最后用一个简单的“这看起来不像是 Axios 错误（很多我什至无法复制）来关闭大部分问题” ,

也许你可以采用lodash 风格的问题管理？
（感谢，@zachleat在@ 11ty / eleventy促进这个！）

@emilyemorehouse
我看到您合并了 6 个 PR（其中 3 个用于 README.md）。 这是一个很好的开始。

但老实说，我仍然认为你需要在项目中添加合作者，因为你有很多工作。

1. 当您合并安全修复时，您需要立即发布（类似于 v0.18.1）。
2. 你有 100 多个 PR。 协作者团队需要审查它们并合并/拒绝。
3. Axios 有 500 多个问题。 其中许多是重复的或不相关的。 合作者团队需要定期审查它们，并保持低开放问题的数量，或者至少是可管理的。
4. 更重要的是，您的团队需要定期审查 PR 和问题，这样情况就不会重复。

请开始接受帮助，否则项目将死亡。 最好的祝愿！

我认为我们（社区）可以通过对 PR 进行代码审查来帮助减轻一些工作量。 您不需要为此成为合作者，并且审查是一项耗时的任务。

我们仍然需要人们来合并 PR。

我们还可以通过评论诸如“#x 重复”之类的内容来帮助对问题进行基本分类，并对功能请求发表意见。

我也愿意参与其中，但我不确定我们需要什么来解锁它正在发布的版本（其中包括 DoS 漏洞修复，这是一个重要的发布）。

请，如果我可以在这里提供任何帮助，请联系！

我也愿意参与，我们在一些非常关键的项目中使用 axios。 如果以后不支持 axios，那就太糟糕了。

@emilyemorehouse ，
@mzabriskie ，
@nickuraltsev ，
@鲁本诺特，

您是 Axios 的所有者。

您能否讨论向该项目添加更多合作者以使其畅通无阻？

这个问题已经开放了 4 个月了，我现在倾向于同意这里的抱怨者。 这个项目的良好管理看起来像：

a) 从众多愿意添加更多贡献者的人中挑选，或
b) 将项目标记为已归档以明确维护意图并允许人们继续下一步或
c) 维护者重新介入以继续积极维护

维护者：如果您愿意选择上述选项之一，那么这对用户社区来说将是一项很好的服务，这样那些有兴趣维护这个项目的人就可以继续前进。 存档是完全可以接受的：+1：

我昨天看到@emilyemorehouse合并了一些 PR。 所以似乎还有人在处理这个 repo。 那真是太棒了。

那么你们完成“大配置问题”了吗？ 下一个版本什么时候发布？

感谢您的努力。

我喜欢 axios，热衷于提供帮助

🙏 https://github.com/axios/axios/releases/tag/v0.19.0

向@emilyemorehouse的发布
我希望很快就有可能定期发布。

@emilyemorehouse

我也想帮忙。 在我的工作中，我们经常使用 Axios，我非常愿意花时间在这个项目上

ping @rubennorte @mzabriskie @emilyemorehouse @nickuraltsev

很多人在使用您的惊人包裹，都在等待您采取一些行动来帮助您！

如果您没有时间执行这些操作，那么也许您至少可以将这个包裹标记为已死？

也许建立一个 patreon 可以帮助你有动力重新开始工作？

我也不介意帮助，例如在分类角色中（https://github.blog/changelog/2019-05-23-triage-and-maintain-roles-beta/）:)

我认为这是一个恳求的版本，因为在最新的 0.19.0 版本之后我没有看到任何活动。
对于这么棒的 HTTP 客户端来说真是太可惜了。

是否有计划为 node.js 添加 HTTP/2 支持？ https://github.com/axios/axios/issues/1175

对我来说看起来像是一个非常活跃的项目......

对我来说看起来像是一个非常活跃的项目......

如果你仔细观察，从 5 月到 9 月是一段完全平静的时期。

无论哪种方式，我都很高兴势头再次回升。 :)

报告的使用量为 180 万，您希望此包获得某种财务支持。 我看不到任何地方提到 patreon、opencollective、tidelift 或 [在此处插入收入来源]。 我创建了#2493 进行跟进。

esm版呢？
https://github.com/axios/axios/issues/1879

Googleapis 组织启动了一个名为gaxios的新项目

来自问题googleapis/gaxios#81 的原因：

我们最初使用 axios，但出于以下几个原因创建了它：

• Axios 最近比较没有维护
• 它不支持开箱即用的代理支持
• 它不支持开箱即用的重试
• 它复制了很多我们在这里不需要的客户端逻辑

Axios 是一个很棒的库，但我们想要一些构建在更轻量级的 node-fetch 上的东西。 希望这可以帮助！

Googleapis 团队背后的动机是可以理解的，尽管我觉得创建一个与 {insert xkcd 漫画} 如此相似的新库并不是一个好主意。 我们可以在这里找到共同点，让它成为一个“Axios”吗？ 抄送@JustinBeckwith

在此线程中为用户分享个人故事和一些新闻，

• 我在 2019 年 2 月注意到像你们一样的 axios 情况，并分类了大约 30 个问题+拉取。
• 没有得到维护者的回应，感到有点失望。 但还是一直关注着。
• 幸运的是，我在 2019 年 12 月被邀请作为合作者。那开始了我的问题杀手时间。 现在总问题从约 600 减少到不到 300。

我为下一个版本制定了计划。 请参阅https://github.com/axios/axios/projects/4。 我知道 axios 仍然存在一些问题，但我希望我们能先修复那些最热的。

我不需要你的话来花太多时间，但是有人介意在你有空的时候帮助审查这些功能，以使下一个版本更好吗？

@chineseedfan这是个好消息，很高兴听到事情正在发生变化！ 问题，既然您现在是合作者 - 是否有围绕 1.0 版本合并的计划/时间表？ 或者即将发布的版本暂时都是 0.x？

如果这已在不同的线程中得到回答，请提前道歉。

你好，

我认为目前固定的 v1.0 版本与它试图实现的目标已经过时了，我几乎想说它的技术债务。 v1.0 的目标应该清楚地列出并评估什么对社区最重要。

我认为我们应该通过适当的回归测试来寻求稳定性，而不是其他任何事情。 Axios 还需要有一个稳定的发布策略，该策略应该锁定在 v1.0 中，并具有更结构化的预发布测试策略。

我将努力尽快尝试建立一个新的 v1.0 项目，其中包含问题等。

鉴于维护问题现在似乎已经解决了……我们可以关闭这个问题/锁定它吗？

暂时关闭，请观看项目以查看 axios 的新版本和拟议路线图。