Monkey Patching in JavaScript

What is Monkey Patching 🐵

The term “monkey patching” is borrowed from the world of software development, where it refers to the practice of modifying or extending code at runtime. In JavaScript, it allows developers to alter or extend the behavior of existing objects or classes without directly modifying their source code.

In simple term's it is : Monkey patching is a technique to add, modify, or suppress the default behavior of a piece of code at runtime without changing its original source code.

Monkey patching involves making changes to existing code, typically by adding new methods or properties to objects or classes, or by modifying existing ones. This can be done at runtime, allowing developers to augment functionality without altering the original code base. Monkey patching is often used to fix bugs, add missing features, or adapt third-party libraries to better suit specific requirements.

Let's see a basic example to understand this concept

Pros of Monkey Patching

1. Monkey patching allows developers to extend or modify existing code without directly altering its source, providing flexibility in adapting libraries or frameworks to specific requirements.

2. Developers can experiment with new features or enhancements without committing to permanent changes in the code base.

3. It enables quick fixes to issues or bugs in third-party code without waiting for official updates or patches.

Cons of Monkey Patching

1. Overuse of monkey patching can lead to code base complexity and reduced readability, making it harder to understand and maintain.

2. Modifying existing code at runtime can introduce unintended side effects or conflicts, especially in large or collaborative projects.

3. Global Scope Pollution: Global scope pollution refers to a situation where too many variables, functions, or objects are introduced into the global scope. This makes it cluttered and can potentially lead to unintended behaviors. Monkey patching can introduce global scope pollution by adding or modifying properties and methods on built-in prototypes or objects. This can lead to naming conflicts and bugs, especially when using multiple libraries or codebases.

Traditional Monkey Patching and Why It Is it is Dangerous

• The author of Array could add a different implementation of logAllMembers, which could break your code which relies on your implementation.
• Elsewhere in your codebase, someone could add a different implementation of logAllMembers, leading to fragile code.
• Elsewhere in your codebase, it will be hard to tell whether Array has been patched or not, so other programmers (or you) could accidentally depend on Array being patched or not-patched.

Conclusion

Monkey patching is a powerful technique for extending or modifying existing code dynamically. However, it comes with considerations like understanding the prototype chain, avoiding global scope pollution. While implementing monkey patching, you must exercise caution, document changes, and thoroughly test patches to mitigate compatibility issues and security risks.

Comments

[Jon Randy 🎖️]

Monkey patching of in-built JS objects like Array can be achieved in a safe manner. I built a whole library to help with doing such things:

Introducing Metho: Safely adding superpowers to JS

Jon Randy 🎖️ ・ Oct 12 '21

#javascript #webdev #react #showdev

[GP]

With new framework & libraries like Angular, React, Vue etc., there is no possibility to practice this technique. I'm not a fan of Monkey patching technique though.

[Michael J. Ryan]

It was much more common prior to ES6/ES2015 in order to normalize functionality between often very infrequent browser updates... IE5, 6 and 8 had very long lifetimes and those using dialup were almost never going to update. Widely availalble broadband and higher speed wireless with continuously updating browsers have largely changed the landscape completely and mitigated most of the reasons to Monkey patch.

There were some very painful issues in various patched browsers earlier on, prior to JQuery, Prototype.js was common, which was relatively close to ES5, but after XmlHttpRequest was relatively common. As much of a mess of spaghetti some modern projects and dependencies can be, it was much worse in those days.