Is it still called monkey patching if you are only adding new methods instead of changing existing method behavior? What is this called?


String.prototype.contains = function(needle) { return false; }

That may not be the best example, but it shows how you can achieve this.

What are some pitfalls of this technique and what are some attempts to get around them?

  • It's called "adding a method to an existing class in Javascript." This post uses the phrase "dynamically creating properties and methods of existing objects through simple assignment." Commented Aug 9, 2016 at 16:14
  • 3
    JavaScript doesn't have classes, so it's called "impossible".
    – gardenhead
    Commented Aug 9, 2016 at 16:21
  • Object prototyping? Array.prototype.newMethod = function() {}. It's unclear what you're asking... Commented Aug 9, 2016 at 16:40
  • @gardenhead - ES2015 introduces a concept called class in javascript - it's syntactic sugar, but, technically, javascript now has something that is called classes Commented Aug 15, 2016 at 3:59

1 Answer 1


It's still called monkey patching. Any modification of the class itself that happens far from it's official declaration is monkey patching.

Monkey patching IMO has two main pitfalls:

  1. Method definition become harder to search. When one wants to look at a method's definition they usually go to the class' definition. When the method is monkey patched, the method's code and comments won't be there - or even worse, if the method is replace then the original method will be there, with no indication that it was replaced with something else.

  2. You now depend on hidden module loading. Yes, you were always depending on module loading, but now the dependency becomes more implicit.

    Usually you know that if you are creating a new Foo you need to load foo.js first(or whatever module Foo is defined in). Or, if you received a Foo from somewhere else, you know that foo.js was loaded there. Even if you somehow created a Foo without loading foo.js because someone else loaded it for you, and that someone else removed the command that loads foo.js, when your code breaks it's usually vert easy to solve - you get an error that Foo is an unknown identifier, so you look where it's defined and load it.

    Monkey patching is not so easy. unrelated.js may add Foo.bar, and you may be using it without loading unrelated.js yourself. Then someone removes it's dependency on unrelated.js, or maybe you created a new script and just loaded foo.js, and suddenly your Foo objects no longer have bar. You are going to bang your head against the wall several times before you'll realize that you need to load unrelated.js.

My solution? If you need to use monkey patching, try to limit it to framework and infrastructure code, and not use it in library or application code. This greatly reduces the risks, because:

  • Framework and infrastructures are already allowed to redefine the rules of the language. Ruby on Rails is a notable example: you are already deeply aware that you are no longer programming Ruby - you are programming RoR - so the monkey patched classes are just another modification you need to be aware of.

  • Frameworks and infrastructures usually handle their own module loading to guarantee they work properly, so they can guarantee that all the monkey patching code is loaded.

  • Frameworks and infrastructures have their own conventions, and if you are aware of those you can easily find the definitions of monkey patched methods.

P.S.: Some compiled static languages have some facilities that resemble monkey patching - like extension methods in C# or Rust's struct/impl separation. These facilities do not have those pitfalls, because the methods you define do not become part of the class. They are only using the class' namespace, and are still belong to the module/scope they are defined in.

  • Aren't name important to being able to do further research? If I don't know what it is called, how do I google it or recognize when other people are talking about it? Commented Aug 9, 2016 at 16:53
  • 2
    @still_dreaming_1: Most questions like this assume that there's a name for everything, and that everything has a name. It doesn't quite work that way. Commented Aug 9, 2016 at 16:55
  • @RobertHarvey But wouldn't it be good to know if a name for it does exist? If no name exists for it yet, that is good to know too. Basically you are saying we should limit our vocabulary to only a few words and then have to use many of them to express any idea and then ignore anything we hear that uses an expanded vocabulary. Commented Aug 9, 2016 at 17:05
  • 1
    @still_dreaming_1: What I am actually saying is that the learning process encompasses far more than vocabulary lessons. Commented Aug 9, 2016 at 17:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.