Lodash _.isNative() method
What you’ll learn
- How
_.isNative(value)fingerprints engine-provided functions. - Why bundled libraries and hand-written callbacks fail the check.
- What breaks detection (core-js masking, aggressive transforms).
- When this helper helps versus misleading security assumptions.
Prerequisites
You know JavaScript builtins live on prototypes (Array.prototype.push) and constructors (Map).
- You treat feature detection as heuristic—not cryptographic proof.
- Try-it labs load lodash from the CDN.
Overview
Use _.isNative when tooling wants to prefer untouched engine implementations—instrumentation guards, capability probes, or documenting whether a reference still points at VM code versus userland replacements.
Engine fingerprints
Compares fn.toString() signatures against native templates.
User code out
Ordinary functions—including lodash itself—fail the native probe.
core-js guard
Throws when masking would lie about native status—see lodash docs.
Syntax
_.isNative(value) - value: any value—typically a function or host constructor.
- Returns:
truewhen lodash believes the value is a pristine native implementation. - Throws: when lodash detects maskable core-js shims (see package notes).
Prototype methods and globals
Built-in methods shipped with the engine usually register as native.
import isNative from "lodash/isNative";
console.log(
"push: " + isNative(Array.prototype.push) + "\n" + // true
"parseInt: " + isNative(parseInt) // true
); User functions and lodash itself
Application code—and the lodash bundle—do not mimic VM-native signatures.
import isNative from "lodash/isNative";
import lodash from "lodash";
console.log(
"userFn: " + isNative(function () {}) + "\n" + // false
"lodashPkg: " + isNative(lodash) // false
); Built-in constructors versus lambdas
Standard constructors can read as native; arrow functions you author do not.
import isNative from "lodash/isNative";
console.log(
"mapCtor: " + isNative(Map) + "\n" + // true (modern engines)
"arrow: " + isNative(() => {}) // false
); 📋 _.isNative vs manual checks
| Approach | Notes |
|---|---|
_.isNative(fn) | Centralizes regex fingerprint logic and masking guards. |
fn.toString() inspection | Manual equivalent—fragile across engines and minifiers. |
typeof fn === "function" | Only proves callability—not engine provenance. |
fn.name / displayName | Metadata hints only; trivially spoofable. |
Pitfalls to avoid
Replaced builtins
Monkey-patched natives may no longer match pristine signatures even though APIs behave similarly.
Not proof of safety
Treat results as telemetry—not an exploit mitigation.
Wrapped helpers
Helpers injected by tooling may wrap natives yet still route to engine code—classification varies.
❓ FAQ
Summary
- Purpose: fingerprint engine-native functions versus userland code.
- Remember: environmental factors can defeat any heuristic.
- Next: explore more on Lodash _.isNil().
_.isNative inspects Function.prototype.toString output against a pattern derived from native code—so spoofed or heavily transformed implementations may not classify as native even when behavior matches.
6 people found this page helpful
