4️⃣ WireMock 4.0

[oleg-nenashev]

Proposal

A placeholder issue for WireMock 4.0. We want to release it within a year or so from WireMock 3.0. The scope is to be decided, and contributions are welcome!

Tentative scope

• Restructuring JAR deliverables, e.g. splitting the CLI client into a separate JAR: https://github.com/wiremock/wiremock/issues/2266
• Key features:
  • Official gRPC extension: https://github.com/wiremock/ecosystem/issues/14
  • Official GraphQL extension: https://github.com/wiremock/ecosystem/issues/13
  • https://github.com/wiremock/wiremock/issues/2167
  • Java 21 support: https://github.com/wiremock/wiremock/issues/2149
• Simplify operations:
  • Configuration-as-code: https://github.com/wiremock/wiremock/issues/1159
  • Built-in configuration validation: https://github.com/wiremock/wiremock/issues/1914
  • Matching to be always done against decoded values: https://github.com/wiremock/wiremock/issues/2152
  • Configuration streamlining: https://github.com/wiremock/wiremock/issues/2151
• Better extensibility:
  • Secrets provider: https://github.com/wiremock/wiremock/issues/2166
  • Better API separation: https://github.com/wiremock/wiremock/issues/2153
• Deprecation removals:
  • Legacy recorder: https://github.com/wiremock/wiremock/issues/2155
  • All deprecated binary and REST APIs from WireMock 3.0

References

• Project board with the backlog: https://github.com/orgs/wiremock/projects/7

[btrautmann]

Not sure how y'all like to prioritize, so feel free to ignore this, but having just gotten my feet wet with WireMock, I've found the biggest pain points to be in the extensions. I think there can be better documentation (I believe I saw an issue for this already Edit: I was thinking of this but it doesn't cover documentation, either inline or in the docs site), but the bigger issue is the API could use some work:

• The existing builder pattern is not fully functional/flexible as pointed out in https://github.com/wiremock/wiremock/issues/2298
• I think there needs to be more builders available such as StubMappingBuilder for things like transforming StubMappings using StubMappingTransformer
• The API as defined is not conducive to working with Kotlin. The biggest issue I see is that nullness annotations are not being used, so when implementing the library's Java types, you can run into sneaky runtime NPEs. One example is again in StubMappingTransformer, the transform method has no nullness annotations so it appears that StubMapping can be null (which I suspect is not true).

I point these things out specifically because a major version change presents the opportunity to make some of these changes in a more future-proof and desirable way, rather than attempting to maintain backwards compat.

[oleg-nenashev]

@btrautmann Thank you! Indeed, the documentation for WireMock 3 is a big gap. Same, not all recent WireMock 2 features are documented. In the next weeks I will be working on closing some of these gaps, as much as my time allows. So any reports here ort in https://github.com/wiremock/wiremock.org/issues would be great.

The biggest issue I see is that nullness annotations are not being used, so when implementing the library's Java types, you can run into sneaky runtime NPEs

Indeed, something on my wishlist too. It does not need to be a major release, but we need to agree on a code style with other maintainers. I am used to setting package level annotations and enforcing nulness checks

[lukematthews]

Hi, Love the framework, been using it at different companies / projects for years.

At the moment, I working on Node projects and whilst I can get it running as part of a Docker Compose script, I'm in a situation where I can't run Docker as part of my CI/CD.

Is there any chance of being able to support generation of Graalvm native images? This gives me the ability to remove my dependency on both Java and Docker

[sebagomez]

I really wish you guys could consider adding this request into the v4 backlog https://github.com/wiremock/wiremock/issues/2802

Thanks