eslint-plugin-extend
ESLint rules for enforcing safe use of Underscore's _.extend(), jQuery's $.extend(), and compatible implementations.
Why Use It
TLDR
If you or someone else on your team (despite being utterly brilliant, knowledgeable, and near-perfect) sometimes gets confused by the signature of _.extend() / $.extend() and accidentally modifies a source object rather than the destination object.
The full, wildly exciting details
The Underscore library's _.extend()
function and jQuery's $.extend()
are both used to copy properties of one or more source objects to a specified destination object; they also return the destination object.
Both extend()
implementations modify the specified destination object. Consider the following statement:
var newObject = _.extend(objectA, objectB);
In this case, the properties of objectB
are copied into objectA
. newObject
is simply a reference to objectA
; both newObject
and objectA
point to the same, modified, object.
It is often the desire of the developer to create a whole new object into which the properties of source objects are copied. To do so, it is necessary to pass an object literal as the first argument to extend()
:
var newObject = _.extend({}, objectA, objectB);
Here, newObject
now points to a third object: the object literal that we passed in, extended with the properties of objectA
and objectB
. And objectA
is unmolested.
Forgetting to pass in an object literal as the first argument is a common mistake that leads to undesired side effects. Consider the following statement from a dinosaur genome management application built on a fictional MVC framework:
var DinosaurCapableOfReproduction = ModelFactory(_.extend(Dinosaur, {
fillGapsWithIffyFrogDNASequence: true
}));
Here, the goal was clearly to create a subset of Dinosaur with the specified fillGapsWithIffyFrogDNASequence
property defined on it, but we inadvertently modified the Dinosaur itself and are in for a nasty surprise.
Getting Started
Documentation for each rule can be found in docs/rules.
Further Reading