2. The pursuit of all edge-cases is a form of hubris. Your first version is fine in many cases (it is the algorithm used by the package referenced [edit:] and by both the Python and .NET standard libraries) and can be written inline.

3. At the point you are concerned with specific edge-cases, and need the 'correct' algorithm, you need to have found that algorithm, understood it, and make sure that the package you're importing implements it. It's even worse for a builtin function: there's no guarantee that a language implementation of average does so, or that it has the correct tradeoffs for your code. You'd need to test it, code review it, and so on. Do you do that for every trivial function?

4. If you're really suggesting that you can't be trusted to calculate an average correctly, then how can you have the slightest confidence in anything you do that is more complex?

You examples does not mention the type of variables involved. And dependent on the type and the language your first example may be (a lot more) correct compared to your third example. Ie. negative floating point numbers.

But who says that a library implementation is a lot better than what you as a programmer can come up with?

In particular with all these "micro" libraries written by random people.

Are they actually smarter than you? Do they understand the "edge" cases as you do?

Most people don't bother with looking at the library source code they are importing. And I don't blame them because things are in general a mess and not only for JavaScript.

The solution, for me at least, is to import less and be more conversative with what you import.