If incompetent it provides a way to be sure?

Could you for laughs explain for which cases these are, why they are needed and why they did it this way?

1) num-num === 0

2) num.trim() !== ''

3) Number.isFinite(+num)

4) isFinite(+num)

5) return false;

6) Why this specific order of testing? Why prefer Number.isFinite over isFinite?

https://www.npmjs.com/package/is-number

   module.exports = function(num) {
     if (typeof num === 'number') {
       return num - num === 0;
     }
     if (typeof num === 'string' && num.trim() !== '') {
       return Number.isFinite ? Number.isFinite(+num) : isFinite(+num);
     }
     return false;
   };

I would have just....

    isNumber = num => isFinite(num+''.trim());

Why is that not precisely the same? (it isn't)

how about...

   function isNumber(num){
     switch(typeof num){
       case "number" : return !isNaN(num);
       case "string" : return isFinite(num) && !!num.trim();
     }
   }

Is there a difference?

IMHO NPM should have a discussion page for this. There are probably interesting answers for all of those looking to copy and paste.

I don't care. The problem in this case is that if you install "isNumber", you use someone else's definition of what a number is. If you ever have to check if something is a number, you should do that according to your own specs, not hope someone else got it right. In this case, strings with all kinds of weirdness seem to be allowed, and perhaps that's not acceptable.

Only the fact that you can write a bunch of slightly different versions because of Javascript's flaws/features should be a sign that you just can't grab an arbitrary implementation and hope it matches your use case, and especially not if you don't/can't pin the version.