@typespec/json-schema does not support versioning

[mligtenberg]

When using the new @typespec/json-schema package together with the @typespec/versioning package the json schemes outputted will not output versioned models. This is unfortunate since it is really easy to generate models in a variety of languages.

I think this is more of a feature request then an actual issue, but it might point to something more structural. As the the versioning library is more of an middle-ware that should do some sort of multiplexing with the emitter. In other words, I find it odd that the emitters have to know about the versioning library.

[mligtenberg]

For some context, I've also seen this issue with something like "@azure-tools/typespec-ts"

[bterlson]

In general, the versioning decorators aren't handled as middleware as the strategy of "output separate assets per version" may not be the best option. For example, consider a scenario where you want to emit a marshalling layer for a service that takes a particular version off the wire and normalizes it such that your business logic doesn't need to worry about versions. In such cases, the emitter will need to reason about the versioning decorators in order to generate the marshalling code. Even the "output separate assets per version" strategy can have different implementations that make sense depending on scenario, e.g. separate folders per version or each emitted file gets a suffix with the version.

For JSON Schema, when emitting to individual files (not bundled) I suspect that a version suffix for each file makes a lot of sense. For the bundled output, putting all versions in the same bundle is probably the correct approach, as opposed to one bundle per version. What do you think?

[mligtenberg]

I think you are right about the middle-ware thing. Though it would be nice if you would at-least get some basic file path logic. As seen for the OpenAPI emitter, https://microsoft.github.io/typespec/standard-library/openapi3/reference/emitter Over here you could configure it to generate an openapi per service, per version. Basically, it would be nice if you could provide the version to the output file of an emitter, and by doing that, that you would have some sort of basic versioning.

That said, I can understand the arguments against that.

Specifically for JSON Schema, I would say it depends. And over here the way the OpenAPI service deals with it would fit nicely.

In configuration could still keep the bundled switch if necessary. But an extra field for an output file template would be added. This way you would be able to configure all schemas in one bundle file (aka no {version} in the template) or a bundle file per version (aka {version} in the template).

It really depends on the usecase if you would need a bundle per version, but for the once I could come up with (validation of json objects, generation of classes) I think it would make sense.