Share types between report-schema and mutation-server-protocol

[nicojs]

The report-schema and mutation-server-protocol have some overlap in their defined types—namely the MutantResult type.

I see 2 ways forward.

• DAMP
  Leave it as is. We accept this bit of overlap in favor of readability, portability, and possibly maintainability.
• DRY
  Create a new package, "mutation-testing-schema" (I guess), with all types from both report schema and MSP. Let report-schema and mts use that.

I'm currently leaning toward the DAMP option, maybe, until we have more to share.

[nicojs]

CC @rouke-broersma @hugo-vrijswijk @jaspervdveen @bmesman

[rouke-broersma]

We don't use the schema to generate our types so this decision is not currently relevant to us. I would suggest that you check your json schema type generator to see if this potentially creates conflicting types and if not that it's fine for now.

For the future I would like to see us publish relevant types as separate schema's so they can be reusable and composable: https://json-schema.org/understanding-json-schema/structuring#dollarref

At that point I would also like to publish the schema's so they can be referenced.

[bmesman]

At this time I don't have a preference yet. For go (golang) and Kotlin I don't know yet if I want to generate any models. Maybe only validate the json output, which could be executed by a validator that does not depend on the target languages for implementing the server or plugin.
Maybe we can setup a validation pipeline for the parts of the spec that should be kept in sync?

[nicojs]

For the future I would like to see us publish relevant types as separate schema's so they can be reusable and composable: https://json-schema.org/understanding-json-schema/structuring#dollarref

Sure, or we migrate the whole thing to Zod, so we can use simple schema's using the JS module system and export it to JSON schema as part of our build steps.

Aligning on Zod would be some work for StrykerJS, but would save us on some dependencies (not the end of the world though)

which could be executed by a validator that does not depend on the target languages for implementing the server or plugin.

Which do you prefer? If you prefer json schema than we can use zod-to-json-schema to convert the current Zod schema

Maybe we can setup a validation pipeline for the parts of the spec that should be kept in sync?

Sure. I can do that in a PR after #3

[bmesman]

Which do you prefer? If you prefer json schema than we can use zod-to-json-schema to convert the current Zod schema

I don't have enough experience to have a well founded preference.