JavaScript ES6: Test for arrow function, built-in function, regular function?

Updated

Originally, I implemented Kangax's solution using regex, however, as several pointed out, there were some false positives and gotcha situations, indicating that we need a slightly more thorough approach.

With that in mind, I took a moment to look through the latest ES spec to work out a complete method. In the following exclusionary solution, we detect syntax for all non-arrow functions which have the function JS type. We also ignore comments and line breaks, which accounts for the bulk of the regex.

Provided the JS engine conforms to ES spec, the following should work in all scenarios:

/** Check if function is Arrow Function */
const isArrowFn = (fn) => 
  (typeof fn === 'function') &&
  !/^(?:(?:\/\*[^(?:\*\/)]*\*\/\s*)|(?:\/\/[^\r\n]*))*\s*(?:(?:(?:async\s(?:(?:\/\*[^(?:\*\/)]*\*\/\s*)|(?:\/\/[^\r\n]*))*\s*)?function|class)(?:\s|(?:(?:\/\*[^(?:\*\/)]*\*\/\s*)|(?:\/\/[^\r\n]*))*)|(?:[_$\w][\w0-9_$]*\s*(?:\/\*[^(?:\*\/)]*\*\/\s*)*\s*\()|(?:\[\s*(?:\/\*[^(?:\*\/)]*\*\/\s*)*\s*(?:(?:['][^']+['])|(?:["][^"]+["]))\s*(?:\/\*[^(?:\*\/)]*\*\/\s*)*\s*\]\())/.test(fn.toString());

/* Demo */
const fn = () => {};
const fn2 = function () { return () => 4 }

isArrowFn(fn)  // True
isArrowFn(fn2) // False

Problem?

If you have any issues, leave me a comment, and I'll work out a revised solution. Be sure to leave a comment under this answer, however. I don't monitor this page, so I won't see it if you say something doesn't work as a separate answer.

ECMAScript waives a lot of its guarantees for host objects, and thus by extension, host functions. That makes the properties accessible via reflection mostly implementation-dependent with little guarantees for consistency, at least as far as the ecmascript spec is concerned, W3C specs may be more specific for browser host objects.

E.g. see

8.6.2 Object Internal Properties and Methods

The Table 9 summarises the internal properties used by this specification that are only applicable to some ECMAScript objects. [...] Host objects may support these internal properties with any implementation-dependent behaviour as long as it is consistent with the specific host object restrictions stated in this document.

So built-in functions might be callable but have no prototype (i.e. not inherit from function). Or they could have one.

The spec says they may behave differently. But they also may implement all the standard behavior, making them indistinguishable from normal functions.

Note that I'm quoting the ES5 spec. ES6 is still undergoing revisions, native and host objects are now called exotic objects. But the spec pretty much says the same. It provides some invariants that even they must fulfill, but otherwise only says that they may or may not fulfill all optional behaviors.

I wrote this for Node, should work in Chrome as well.

"Boundness" is detected (apparently, only on ES6) and reported as native && bound. This might or might not be an issue, depending on what you are using that information for.

const flags = {
  function: f instanceof Function,
  name: undefined,
  native: false,
  bound: false,
  plain: false,
  arrow: false
};

if (flags.function) {
  flags.name = f.name || '(anonymous)';
  flags.native = f.toString().trim().endsWith('() { [native code] }');
  flags.bound = flags.native && flags.name.startsWith('bound ');
  flags.plain = !flags.native && f.hasOwnProperty('prototype');
  flags.arrow = !(flags.native || flags.plain);
}

return flags;

Believe it or not...

Testing for presence of "=>" in string representation of a function is likely the most reliable way (but not 100%).

Obviously we can't test against either of 2 conditions you mentioned — lack of prototype property and lack of [[Construct]] as that might give false positives with either host objects or built-in ones that lack [[Construct]] (Math.floor, JSON.parse, etc.)

We could, however, use good old Function.prototype.toString to check if function representation contains "=>".

Now, I've always recommended against using Function.prototype.toString (so-called function decompilation) due to its implementation-dependent and historically unreliable nature (more details in State of function decompilation in Javascript).

But ES6 actually tries to enforce rules on the way (at least) built-in and "user-created" (for the lack of better term) functions are represented.

2. If Type(func) is Object and is either a Built-in function object or has an [[ECMAScriptCode]] internal slot, then

   a. Return an implementation-dependent String source code representation of func. The representation must conform to the rules below.

...

toString Representation Requirements:

• The string representation must have the syntax of a FunctionDeclaration FunctionExpression, GeneratorDeclaration, GeneratorExpession, ClassDeclaration, ClassExpression, ArrowFunction, MethodDefinition, or GeneratorMethod depending upon the actual characteristics of the object.

• The use and placement of white space, line terminators, and semicolons within the representation String is implementation-dependent.

• If the object was defined using ECMAScript code and the returned string representation is not in the form of a MethodDefinition or GeneratorMethod then the representation must be such that if the string is evaluated, using eval in a lexical context that is equivalent to the lexical context used to create the original object, it will result in a new functionally equivalent object. In that case the returned source code must not mention freely any variables that were not mentioned freely by the original function’s source code, even if these “extra” names were originally in scope.

• If the implementation cannot produce a source code string that meets these criteria then it must return a string for which eval will throw a SyntaxError exception.

I highlighted relevant chunks.

Arrow functions have internal [[ECMAScriptCode]] (which you can track from 14.2.17 — evaluation of arrow function - to FunctionCreate to FunctionInitialize).

This means they must conform to ArrowFunction syntax:

ArrowFunction[In, Yield] :
  ArrowParameters[?Yield] [no LineTerminator here] => ConciseBody[?In]

..which means they must have => in Function.prototype.toString's output.

You'll obviously need to ensure "=>" follows ArrowParameters and is not just something present in FunctionBody:

function f() { return "=>" }

As for reliability — remember that this behavior is/might not be supported by any/all engines at the moment and that host objects' representation might lie (despite specs efforts) for whatever reasons.