v<%= releaseVersion %>

I'm sorry. Did you say v2?

Yes. v2! (It's been five years, after all)

Oh dear. How much time is it going to take me to "upgrade" my code?

None. v2 is 100% backwards compatible with v1

Wait, what? Then why did you bump the major version?

Because v2 is Yuge!

This release opens all kinds of exciting doors.

See below for details, but there are three major reasons to upgrade.

You can now create custom protocol implementations in any language of your choice.
The injection interface changed (don't worry, you can still use the old interface if you like. I'm not rude, after all).
I fixed an embarrassing security flaw in all v1 versions using --localOnly and --ipWhitelist CLI flags.

Be sure to keep up with the latest releases by subscribing to the ATOM feed.

New Features

The biggest change is how protocol implementations work. In all v1 versions, they worked, but adding a new one was difficult because of some unfortunate early design decisions. Those decisions have been painstakingly reversed. You can now add a custom protocol in any language with a very simply API to talk back to the mountebank server. The protocol implementation will show in the logs no differently than a built-in protocol implementation like http, but will be out of process to mountebank itself. You tell mountebnak about your custom implementation with the new --protofile command line flag. This is Yuge!
Over time, the injection functions took on new parameters. This was unfortunate because it became difficult to remember the order of the parameters and because there were actually two different types of state parameters passed into the response injection function (I never documented one. The documented one did not share state with predicates; the undocumented one did). While you can continue to use the old interface, the new interface is much cleaner, accepting a single JSON parameter that contains all relevant information. That interface now cleanly shares state between predicate and response injection and allows for much easier evolution of injection functions (including adding async capability to predicate injection and decorate behaviors).

Bug Fixes

Injection is useful but dangerous, and you should ALWAYS take steps to secure yourself from attackers using an injection-enabled mountebank. The easiest way to do that is with the --localOnly CLI flag, which limits all connections to the loopback interface (e.g., localhost). You should ALWAYS do that when running mountebank directly on your developer machine, and use the --ipWhitelist flag in other scenarios. Unfortunately, neither of these flags worked in v1. I'm sorry. That's an embarrassing security vulnerability. They are both verified by a series of automated tests now, and verified to work with both the mountebank server itself and all imposter sockets.
The result from GET /imposters/:port?replayable=true now returns the value of recordRequests.
Setting the --mock CLI flag no longer changes the imposter-level value of recordRequests
The --host command line flag wasn't being reflected in the logs or mountebank URLs, and it wasn't applying to imposters.
The tcp protocol page took way too long to load due to page weight (there is an embedded test on the page that required the page weight). That has been fixed.
The TCP proxy now respects the endOfRequestResolver
HTTP/S servers no longer time out if a wait behavior was set to more than about 2 minutes
JSON bodies with nulls now work with copy behaviors
SMTP now works with an empty text field

Contributors

Many thanks to the following kind folks for help with this release, either through bug reports, suggestions, or direct code contributions:

Aleksandar "Bearclaw" Serifimoski
Santiago Vasquez

Install

npm install -g mountebank@<%= releaseVersion %>

or:

Option	node.js required?	sudo required?	links	Description
Self-contained archives	No	No	osx linux x86 linux x64 win x86^* win x64^*	Simply unpack and run `mb` from inside
OS-specific packages	No	Yes	pkg rpm deb	Puts `mb` at `/usr/local/bin`, which is generally in the `PATH`.
source tarball	Yes	No	mb	source tarball if you roll that way.

Windows path limitations

^*mountebank wishes very much for your Windows experience to be hassle-free, but he is simply not qualified to address a particular constraint of Windows Explorer. For legacy reasons, some Windows applications, including most notably Windows Explorer, have a maximum number of characters allowed in a path of 260 characters. As mountebank writes these words, the longest path he includes in the zip files is around 175 characters. The zip file name, which is likely to represent itself as two nested directories if you use the defaults to unzip it, will be around 25 characters. That gives you very little wiggle room. If you unzip the file in your users directory, you may very likely get an error because of this constraint.

The following solutions will all work:

Unzip to the root of your C: drive (or a similar small path)
Use 7zip to unzip the file instead of Windows Explorer
Use npm to install mountebank instead of the zip file