Agreed 100%. As a library author I'd also recommend if you create functions to make way for this specific case. It's just very useful to be able to `.map()` so

Agreed 100%. As a library author I'd also recommend if you create functions to make way for this specific case. It's just very useful to be able to `.map()` so allowing people to do it is a net gain, I've done so in my library `files` (https://documentation.page/github/franciscop/files https://documentation.page/github/franciscop/files): > Ignores the second parameter if it's not an object so you can work with arrays better like .map(read) It's also pretty simple to implement: // Assuming we are taking an options object {} export const myFunc(arg1, arg2 = {}) => { if (typeof arg2 === 'number') arg2 = {}; // ... rest of the code as usual }; So, library authors, do a favour to users and in those functions that could be used as a callback, add this option. Some other tips/niceties I've learned over the years: - For highly async libraries, allow to accept an unresolved promise. It's pretty safe and easy to do on the library-side, and will probably remove a bug or two on your users' side. - Export default and named so the users don't need to worry about whether to `import * as files from` or `import files from` (assuming the library is small and there's no concern about tree-shaking). - I also use a higher-order promise abstraction I created, Swear (https://documentation.page/github/franciscop/swear https://documentation.page/github/franciscop/swear), but that's totally optional and you can treat any of my async libraries as normal Promises.