Lodash _.assignIn() method

Beginner
⏱️ 7 min read
📚 Updated: May 2026
🎯 3 Code examples
🚀 3 Try-it labs
Lodash

What you’ll learn

  • How _.assignIn(object, ...sources) mirrors _.assign but also walks inherited string keys from each source’s prototype chain.
  • Why _.assignIn and _.extend are the same function under two names.
  • Where this matters in practice (class instances, custom prototypes, mixin patterns).
  • Try each example in the editor (?tryit=1, 2, 3) with Lodash from a CDN.

Prerequisites

Read _.assign() first for the shared shallow/mutating semantics; this page focuses on the inherited-key extension.

  • Prototype chain: understand Object.create, constructor prototypes, and the difference between hasOwnProperty and in.
  • Enumerable flag: non-enumerable inherited properties (such as most built-in Object.prototype methods) are still skipped.

Overview

_.assignIn is the “walk-the-chain” cousin of _.assign. Everything else is identical: properties are read from sources left to right, copied into the first argument, and the (mutated) destination is returned.

Inherited keys

Class instances, factory mixins, and prototype-defined shape data all flatten into the destination.

Still shallow

Walking the prototype chain doesn’t deepen the copy—nested values stay shared by reference.

Tree-shakeable

Import lodash/assignIn on its own; lodash/extend resolves to the same module.

Syntax

javascript
_.assignIn(object, [...sources])
// alias: _.extend(object, [...sources])
  • object: destination object; mutated in place.
  • sources: zero or more source objects; own and inherited enumerable string keys are copied left to right.
  • Returns: the (now-mutated) destination object.
  • Skipped: symbol keys, non-enumerable properties, and properties at depth (use _.merge for those).
1

Class instance with prototype keys

An instance carries one own key (own) and inherits one (inherited). _.assignIn copies both; the sibling _.assign keeps only the own key.

javascript
import assignIn from "lodash/assignIn";
import assign from "lodash/assign";

function Source() {
  this.own = "from instance";
}
Source.prototype.inherited = "from prototype";

const src = new Source();

assignIn({}, src);
// => { own: "from instance", inherited: "from prototype" }

assign({}, src);
// => { own: "from instance" }            // inherited key skipped
Try it Yourself
2

Mixin: layer prototype helpers onto a plain object

Define shared behavior on a prototype, then flatten it onto a plain configuration object with one call.

javascript
import assignIn from "lodash/assignIn";

const Greeter = {};
Object.getPrototypeOf(Greeter) === Object.prototype; // true (plain object)

const proto = { greet() { return "hi " + this.name; } };
const instance = Object.create(proto);
instance.name = "Ada";

const flat = assignIn({}, instance);
// flat.name  -> "Ada"
// flat.greet -> function (copied from prototype)
flat.greet();
// => "hi Ada"
Try it Yourself
3

Left-to-right conflict resolution

Same precedence rules as _.assign: the last source to mention a key wins. Pass {} as the destination when you want a brand new object.

javascript
import assignIn from "lodash/assignIn";

const target = { a: 1 };
const source1 = { b: 2 };
const source2 = { a: 3, c: 4 };

assignIn(target, source1, source2);
// target is now { a: 3, b: 2, c: 4 }     (source2 overwrites a)

const merged = assignIn({}, target, source1, source2);
// merged === target ? false              (fresh object)
// merged is also { a: 3, b: 2, c: 4 }
Try it Yourself

📋 _.assignIn vs _.assign vs _.merge

Topic_.assignIn_.assign_.merge
Own keysYesYesYes
Inherited keysYesNoNo
Symbol keysNoNoNo
DepthShallowShallowRecursive
Aliases_.extend
Typical useClass instances, prototype-based mixinsPlain config layeringNested config trees

Reach for _.assignIn when the source has meaningful data on its prototype; stick with _.assign for plain object literals; use _.merge when you need nested combination rather than overwrite.

Pitfalls to avoid

Surprise keys

Unwanted prototype data

Walking the chain also picks up keys you didn’t mean to expose (custom toJSON, framework helpers). Switch to _.assign when you want a strict whitelist.

Mutation

Destination is written in place

Same trap as _.assign—callers sharing the first argument will see the new keys. Pass {} when you want isolation.

Depth

Still shallow

The “In” suffix only changes the key set, not the depth—mutating a nested object after copying still affects the destination.

❓ FAQ

Same shape, broader scope: _.assignIn copies own AND inherited enumerable string keys from each source, while _.assign sticks to own keys only. Pick assignIn when the source is a class instance whose useful data lives on its prototype.
Yes. _.extend is a documented alias of _.assignIn that ships in monolithic Lodash builds. Use whichever name reads better in your codebase—they share an implementation.
Yes. The first argument is written in place and then returned. Pass {} as the destination when you want a fresh object and to leave the inputs untouched.
No. It performs a shallow merge—nested objects and arrays are copied by reference. Use _.merge when you need recursive combination of nested plain objects.
No. Like _.assign, it walks only string keys. If you need symbol keys, fall back to native Object.assign (own only) or copy them manually with Object.getOwnPropertySymbols.
Use import assignIn from "lodash/assignIn"; for ESM or const assignIn = require('lodash/assignIn') in CommonJS. The Lodash module path stays camelCase even though the tutorial URL is kebab-cased.

Summary

Did you know?

_.assignIn and _.extend are the same functionextend is the legacy alias kept for backwards compatibility. Both walk own and inherited enumerable string keys; only the name differs in the Lodash docs.

About the author

Mari Selvan M P
Mari Selvan M P 🔗

Developer, cloud engineer, and technical writer

  • Experience 12 years building web and cloud systems
  • Focus Full Stack Development, AWS, and Developer Education

I write practical tutorials so students and working developers can learn by doing—from databases and APIs to deployment on AWS.

6 people found this page helpful