Mountebank Studio — a browser UI for an existing mountebank instance

[gokhanibrikci]

Hi @mattherman @jarl-dk — thanks for keeping this project going.

I have been using mountebank for service virtualisation in a payments team, and
the part that slowed us down was never the engine — it was writing and re-reading
the JSON. So I built a panel for it and have been using it daily:

https://github.com/gokhanibrikci/mountebank-studio

npx mountebank-studio

That starts a mountebank, serves the panel, and forwards to the instance from the
same origin, so no --origin flag is involved. It also connects to an instance you
already run (--mb-url), including one you cannot add a flag to: the panel asks the
host serving it to fetch that instance instead.

It talks only to the public admin API — imposters, stubs, predicates, responses,
proxies, behaviors, faults, saved requests. Two things I was careful about:

• It does not lose what it cannot draw. A proxy's injectHeaders, a tcp
  imposter's mode, a behavior it has no field for — all carried through and written
  back byte-identically, with round-trip tests over real instance output. Two silent
  data-loss bugs were found that way.
• It does not present a guess as a fact. mountebank reports the matched stub only
  with --debug, so the panel evaluates the predicates itself and labels the result
  as computed rather than implying the instance said so.

Apache-2.0, no telemetry, no account, environments live in the browser only.
What it covers feature by feature, and how that was verified against 2.9.1, is in
COVERAGE.md.

Two things I would like your view on.

1. The name. I called it mountebank-studio because it is the plainest
description of what it is, but the name is yours, not mine. If you would rather it
were named differently, say so and I will rename the repo and the npm package — it is
early enough that this costs me nothing. I have kept "unofficial, not affiliated with
or endorsed by the mountebank project" in the README, the NOTICE and inside the panel
itself, and mountebank is a normal dependency rather than redistributed code.

2. Something I noticed that may be useful. npm's latest for mountebank is
still 2.9.1, published 2023-08-23, while this org has released v2.9.2, v2.9.3 and
v2.9.4 on GitHub. So npm i mountebank — and therefore my package, which depends on
it — installs the 2023 build, which I think is what the dependency CVEs in #947 are
actually about.

I saw the Trusted Publishing discussion, so the workflow side is clearly done. If
publishing is still failing, the wall I hit on my own package this week may be the same
one: the trusted publisher has to be recorded on npmjs.com, per package, by someone
with access to that package — the registry answers 404 on the OIDC token exchange
until that record exists, which reads like "package not found" rather than "not
configured". npm's maintainer list for mountebank shows only bbyars, so that record
may need him even though the CI is ready.

Happy to help with any of that, and happy to be listed — or not — as you prefer.