When should a WireMock stub server run --global-response-templating rather than per-stub templating?

## Two settings, one instance-wide default WireMock has exactly one knob here and it is set where the server is launched, not where the stubs are written: - `--global-response-templating` — every response this WireMock instance serves is rendered, whether or not the mapping asked for it. - `--local-response-templating` — WireMock's opt-in default, stated explicitly: a response renders only when its `transformers` list names `response-template`. Because the knob lives on the launch command, the same mapping file behaves differently on two instances. That is the single most important consequence of the choice and the reason it belongs in whatever starts the server — a compose file, a container command, a fixture class — rather than in a wiki page. ## Why WireMock defaults to opt-in A stub server's core promise is that a canned reply comes back exactly as written. Rendering every body breaks that promise for any payload that contains braces for its own reasons, and those are more common than they sound: - A fixture that is itself a template for some other system. - A configuration document or a front-end bundle served as a static resource. - A recorded payload from a real upstream whose text happens to contain `{{`. - A body deliberately containing braces because the test asserts the client escapes them. With global templating on, each of these stops being served verbatim. Depending on the content, the caller gets a mangled body, an empty field, or an error marker where the braces were — and the mapping that produced it looks perfectly innocent, because nothing in the file says it is being rendered. ## When global earns its keep Global templating is the right call when the instance's whole reason to exist is dynamic replies. For a standalone WireMock serving a snowplough dispatch API in a shared environment, where every mapping under `/dispatch/v1` echoes a route id, stamps a dispatch time and reflects a depot, the per-mapping opt-in is pure ceremony: 1. It removes a repeated three-word incantation from every file in the set. 2. It removes a whole class of bug report — "my new mapping returns the braces" — because a new file cannot forget to opt in. 3. It makes the instance's behaviour a property of the deployment, which is reviewable in one place, rather than a property of fifty mappings that must each be reviewed. The condition attached to all three is uniformity. The moment the set is mixed, every one of those advantages inverts. ## What global costs | Dimension | `--global-response-templating` | per-stub `response-template` | |---|---|---| | A body that must be served verbatim | not possible on this instance | the default for every mapping that stays quiet | | Intent visible in the mapping file | no — the file looks literal | yes — the transformer name is in the response | | Cost of adding a dynamic mapping | nothing to remember | one call or one array entry | | Blast radius of the decision | the whole instance | one response | | Reviewability | one launch command | every mapping, individually | There is a second cost that is easy to miss. Templating is a reach out of the stub and into its host: a rendered body can pull in values that were never in the request. WireMock ships `--permitted-system-keys` precisely to bound which system properties and environment variables a rendered body may read. On a shared instance that flag is not optional hygiene, it is the thing standing between a templated mapping and whatever else is in that process's environment. Turning rendering on globally turns that surface on for every mapping at once, including mappings nobody reviewed with rendering in mind. ## A policy that survives contact with a team 1. Decide per instance, not per suite. An instance is either a dynamic-reply server or a fixture server; instances that try to be both accumulate exactly the bugs described above. 2. Put the decision in the launch command and treat that command as reviewed code. A flag discovered by reading a container's history is not a decision, it is an accident. 3. If the instance runs globally, say so in the repository holding its mappings, because the files themselves no longer carry the evidence. 4. Bound what a rendered body can read with WireMock's `--permitted-system-keys` before the instance is shared, not after somebody notices what a template can reach. 5. Prefer the per-stub form for anything embedded in a test suite. The mapping and the assertion sit in the same file, so the opt-in costs a line and buys the reader an explanation. ## The other two servers do not have this switch In MockServer the question does not arise in this shape: a reply is either a literal `response()` or a template declared as one with `HttpTemplate.template(TemplateType.VELOCITY, ...)`, so rendering is a property of the response object rather than a server-wide default. In Mountebank it is likewise per response — `decorate`, `copy`, `lookup` and `shellTransform` are entries in that response's `behaviors` array, four of its five behaviors — and there is no launch flag that makes every imposter's replies dynamic at once. WireMock's global flag is a genuine convenience the other two do not offer, and a genuine footgun they cannot fire.