Issue I am having with 'additionalProperties' and TypeSpec

[ADRFranklin]

Hi there,

So I recently found out about https://typespec.io/ and was interested in giving it ago, and so far has been pretty interesting as well as a nice difference to writing it in yaml.

However I just found my first problem since using it, and that is that they don't allow you a way to generate additionalProperties with a yes meaning I am currently unable to use my APIError object as I previously was, and that is due to the EmptyObject that is applied, which essentially forces me to do as any every time I wish to output any metadata.

export type t_APIError = {
  error: string
  message?: string
  metadata?: {
    [key: string]: EmptyObject
  }
  suggested?: string
}

Is there a way to nicely work around this or will I need to wait for some update/change for it? For now I will just override the type checking with as any until a better solution is found.

[mnahkies]

https://typespec.io looks pretty cool - I'll have to look at that more closely.

Yeah additionalProperties hasn't been supported as well as I'd like - #44

I've put a bit more work into it in #126 which I think should largely solve your problems, you should expect to get something like:

export type t_APIError = {
  error: string
  message?: string
  metadata?: {
    [key: string]: unknown | undefined
  }
  suggested?: string
}

Once that is released, and the zod schemas are now aware of additionalProperties

One thing I'm unsure about is forcing the use of unknown - it means the end user must parse/cast the values to use them, which is generally good but can be tedious in some situations, so I'd consider adding a CLI flag to toggle between any and unknown for these.

[ADRFranklin]

Fair enough, will be waiting for that release then.

What about making use of the x-type fields? I've seen a lot of projects make use of them, so what if you could override the type generated such as setting it to unknown, any or some other value? The global options might work, but I probably don't want to make every model that has this become any but only some or in my case just the one.

I think making the default fallback value be unknown makes more sense, which might make more sense if the above was an option, so specific models values could be overridden or provide more information for the generator to make a better decision about the output.

[mnahkies]

I've gone ahead and published the changes from #126 in 0.6.0

The x-type escape hatch sounds interesting - I don't suppose you have any references to where you've seen this been used? Ideally I'd like to align any implementation with the "norm" from other tools

[ADRFranklin]

Alright, I'll give that a try then.

As for the x-type that was just how I have seen some libs refer to it, however I believe it's just called 'Specification Extensions' in openapi docs (https://swagger.io/specification/#specification-extensions).

I'll list a few of the ones I know/found that makes use of them.

• deepmap (https://github.com/deepmap/oapi-codegen?tab=readme-ov-file#extensions) (they use x-go-type to specify the type)
• express-openapi (https://www.npmjs.com/package/express-openapi#vendor-extensions)
• azure-autorest (https://github.com/Azure/azure-rest-api-specs/blob/master/documentation/openapi-authoring-automated-guidelines.md) (this one has lots of uses of the x- type)
• oa-client (https://github.com/ninofiliu/oa-client?tab=readme-ov-file#3-have-somewhere-your-openapi-specs-as-a-js-object) (makes use of a x-type)
• openapi-typescript-codegen (https://github.com/ferdikoomen/openapi-typescript-codegen/wiki/Enum-with-custom-names-and-descriptions)

here are just a few that make use of the x- type, not sure if this was specifically what you were asking or not, but hopefully this benefits you in some way.

I also just wanted to link this (https://tsoa-community.github.io/docs) which I found which you might find useful.