tl;drSugar will NOT modify Object.prototype!
Quite a bit of confusion exists around this topic. Sugar intentionally chooses to modify native Javascript objects, so it's worth pointing out the dangers that exist here, and the consequences of this choice.
First, it's important to state that Sugar modifies "built-in" Javascript classes like Array, String, Number, etc. It does not modify "host" objects like DOM elements, events, etc. The majority of pitfalls in extending native objects lie with "host" objects but are incorrectly attributed to all Javascript objects.
In this context, "modifying" refers to modifying the prototype object of native JS classes. Once a property is set on the prototype of a class, it will exist for all instances of that class:
String.prototype.name = 'Harry'; 'cat'.name;
What's more, when iterating over the object using a for..in loop, the property will also appear as if it were one of the members of the object itself:
String.prototype.name = 'Harry';
for(var key in 'cat') {
console.log(key);
}
> 0
> 1
> 2
> 'name'
This can cause unintended results, as objects iterated over using for..in will appear to have more members than they actually do, due to prototype inheritance. The Object class is particularly dangerous to modify, as all other classes inherit from it:
Object.prototype.name = 'Harry';
for(var key in 'cat') {
console.log(key);
}
> 0
> 1
> 2
> 'name'
When iterating over an object in this manner, hasOwnProperty should always be used to prevent unintentional traversing of members in the prototype:
var s = 'cat', key;
for(key in s) {
if(s.hasOwnProperty(key)) {
console.log(key);
}
}
> 0
> 1
> 2
This method will return false if the property is inherited, so using this check ensures that only direct members on the instance are being iterated over. for..in loops should always use hasOwnProperty to ensure that they are properly iterating over only direct members.
However, despite being a best practice, use of hasOwnProperty isn't a given, and many developers aren't aware of it or leave it out. Although the standard for loop is the accepted method of looping through arrays, the for..in loop is the accepted way of iterating over object literals (such as JSON objects), which is what makes modifying Object.prototype so dangerous. In a situation where third-party code is being broken by such a method, a fix is essentially impossible.
Because of this inherent danger in modifying the Object prototype, Sugar will never modify it by default. This means that you can continue to use for..in loops without hasOwnProperty (although you shouldn't), and you can be sure that such code in third-party libraries won't break either. Additionally, Sugar provides methods such as Object.each that encapsulates the above pattern and allows you to iterate over direct members of objects without traversing into their prototype chain:
Object.prototype.name = 'Harry';
Object.each('cat', function(key, value){
console.log(key, value);
});
> 0 c
> 1 a
> 2 t
Additionally, ECMAScript introduced a method in the 5th edition called defineProperty that, among other things, allows properties to be defined as "non-enumerable". This means that the property will not appear in for..in loops, making defining properties on native objects even safer. Sugar makes use of this method if it is available.
With the above considerations, Sugar is about as safe as modifying native objects can get. Objects can be iterated over using for..in loops without fear of breakage, and modern browsers that implement defineProperty will prevent any extended method from appearing in a loop. Legacy browsers, most notably IE8 and below, still have array properties appear in for..in loops, so caution must be exercised here. Fortunately, standard for loops are much more common practice for developers working with arrays. And as legacy browsers slowly lose their following, modified native objects will become increasingly safe to use.