Feature: Handle Type.Literal

[AshotN]

Is your feature request related to a problem? Please describe. Type.Literal from TypeBox gets treated as the underlying type of the value.

Describe the solution you'd like Type.Literal should show up as the value

A property defined like this type: Type.Literal('company') shows up as "type": "string" instead of what I would expect as "type": "company"

[Mairu]

Hi, I don't know what you expect but TypeBox is creating the json schema, not feathers-swagger.

Also there is nothing like a type "company", there is a very limited set of types: https://spec.openapis.org/oas/latest.html#data-types.

Please check https://github.com/sinclairzx81/typebox#standard-types to see what JsonSchema output you can expect when using TypeBox.

If you describe your goal, I can perhaps guide you into the right direction.

[AshotN]

company in this example is not a type, Type.Literal is like allows you to define a static value for the property. Perhaps the names I chose for the variables were confusing.

Hopefully this is a more clear example of usage of Type.Literal

const myObject: TObject<{myLiteralValue: TLiteral<"aRandomString!">}> = Type.Object({
  myLiteralValue: Type.Literal('aRandomString!'),
})

[daffl]

JSON schema does not have custom types, type can only be the ones from the list here.

So Type.Literal will have the type the literal you passed (string, number or boolean). Another example can be found at https://dove.feathersjs.com/api/schema/typebox.html#literal

[AshotN]

My suggestion is to use the const value instead of the type in the example schema.

[Mairu]

You could add the example to the options parameter of the typebox types -> https://github.com/sinclairzx81/typebox#options

type: Type.Literal('company', { example: 'company' })

If you want to automate this somehow you could use the sanitizeSchema option of createSwaggerServiceOptions function to adjust schemas as you like.

But I would not want to add such customizations to the library. What are your thoughts @daffl?

[daffl]

I agree. We learned from experience that adding non-standard customisations like this can often cause other unforeseen problems with things not behaving like people (or other plugins) would expect.

[AshotN]

Fair enough.