Javascript Node.js库是否同时支持承诺和回调

我正在处理一个Node.js库项目，该项目向用户公开异步API。我在javascript中工作的时间不长，但似乎几年前，回调被用来处理异步结果/错误。然后在ES6中引入了承诺，在ES8中引入了异步等待（这只是使用承诺更方便的方式）

我的问题是，API的典型用户目前会期望什么？我注意到在几个同时支持承诺和回调的项目中有一个习惯用法，即函数将回调作为最后一个参数，如果没有提供回调，则返回承诺

我想知道在当前项目中是应该遵循这个习惯用法，还是应该一起删除回调？还有人会使用回调吗

我注意到async await正在成为主流样式，但Node.js API本身仍然是基于回调的（事实上，API通常返回事件发射器，而不是承诺，以便用户可以在返回值上注册事件）

所以，我只是想从Node.js社区了解一下应该朝哪个方向发展

谢谢

编辑：

谢谢你的回答。我被要求澄清关于该项目的两件事，以防有更多的建议：

（1） API旨在用于访问特定产品

（2） 所有呼叫都涉及网络通信，基本上是请求/响应

我们肯定打算支持承诺（例如，每个请求都会给用户一个可以实现或拒绝的承诺），唯一的问题是是否还应该支持回调

或许我可以将这些问题重新表述为不那么基于观点：

1） 对于最近发布的Node.js库（在该语言支持async await之后），并且具有与上述类似的需求，主要的样式是什么？你能给我举个例子吗

2） 是否存在应用程序希望通过回调而不是承诺来处理异步结果/错误的场景

---

谢谢。

您的预期用户群有多大

如果它是小的-即包含在一个易于定义的组和现代技术堆栈中，扮演独裁者，只选择一种风格

---

如果它很大，必须运行在许多可能的传统平台上，考虑只提供回调，或者提供多种口味。 一系列可能性

如果您的库需要与客户端程序建立同步关系，那么您可能希望使用回调（依赖于I/O的程序）。否则，如果您的API响应时间长且不一致，那么您肯定希望能够处理承诺，这样您就不会成为无法等待每个请求的瓶颈应用程序（路由webtraffic等）

结论

在我个人看来，Node.js之所以伟大，是因为承诺的异步性，让您可以编写灵活的程序。最终，人们会将您的库用于多种用途，您可以为用户提供的选项越多越好。祝你好运