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: Split WireMock Java into more JAR deliverables #2266
• Key features:
  • Official gRPC extension: Official extension: gRPC Request Matching ecosystem#14
  • Official GraphQL extension: Official Extension: GraphQL API Mocking ecosystem#13
  • Support for client certificates when proxying requests #2167
  • Java 21 support: Java 21 support #2149
• Simplify operations:
  • Configuration-as-code: Allow WireMock defaults to be configured using a configuration file #1159
  • Built-in configuration validation: Validate stubs (without starting up) #1914
  • Matching to be always done against decoded values: Do matching against decoded request values by default #2152
  • Configuration streamlining: Unify configuration file bodies #2151
• Better extensibility:
  • Secrets provider: Secrets Provider Extension point #2166
  • Better API separation: Improve separation between really public APIs and "Java public ones" #2153
• Deprecation removals:
  • Legacy recorder: Remove the legacy Recorder #2155
  • All deprecated binary and REST APIs from WireMock 3.0

References

• Project board with the backlog: 4️⃣ WireMock Java 4.0

[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 RequestPatternBuilder has ability to clear/replace underlying Collection types. #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 #2802

Thanks