bcherny
Add option to control type naming.
Currently type names are derived as follow:
/**
* Compute a schema name using a series of fallbacks
*/
function standaloneName(
schema: JSONSchema,
keyNameFromDefinition: string | undefined,
usedNames: UsedNames
) {
let name = schema.title || schema.id || keyNameFromDefinition
if (name) {
return generateName(name, usedNames)
}
}
This is not ideal if title is used for other purposes - I would like to rather specify the priority - so for example --typeNames id,title,definition should use either id, and if id is not set use title and then finally fall back to definition.
Hey there! This is a pretty unusual behavior to customize. Could you give more context for why you want a different name resolution algo for your use case?
We are using https://mozilla-services.github.io/react-jsonschema-form/ to generate forms from JSON schema - and this is using title in the output form. This seems to be what title was intended for:
JSON Schema: interactive and non interactive validation draft-fge-json-schema-validation-00
6.1. "title" and "description"
6.1.1. Valid values
The value of both of these keywords MUST be a string.
6.1.2. Purpose
Both of these keywords can be used to decorate a user interface with information about the data produced by this user interface. A title will preferrably be short, whereas a description will provide explanation about the purpose of the instance described by this schema.
Both of these keywords MAY be used in root schemas, and in any subschemas.
Using something which is likely to contain human readable text for type name generation is not ideal. Using id seems more reasonable - but I would much rather prefer for my case to always use keyNameFromDefinition as this will provide overall better consistency from code point of view - if someone adds or changes ID/Title then the type names will remain consistent and it simplifies the heuristics for determining what the name of a type will be.
The reason why this should be configurable is because changing it outright to use id or keyNameFromDefinition instead of title will likely break things for people relying on current behavior.
@iwan-aucamp-cs That sounds fair to me! Feel free to submit a PR introducing a new option for this, customName, which should be a function that takes (id, title, keyNameFromDefinition) and returns a string. If that option is passed in, we can use it when computing the name in the let name line.
Adding my use-case: We use the title for human consumption, and assume that the title is going to change once in a while. The name generated for the type from that schema however should not change, but rather I would like to assign a name based on (in order of preference):
- An attribute in the schema for the name of the generated type
- A command line argument/compile option
- Some reasonable default/automatism as existing right now
I'm surprised this hasn't been touched again for the past three years!
I have just opened up #456 which intends to resolve this in a way that's better for @ankon's use case (and my own, see https://github.com/mdn/browser-compat-data/issues/16494). Rather than add a command line option, my PR intends to provide more granular control and offer a name override in the schema, much like tsType.
