Seeking Feedback on Implementing format password Support

[baobaopandas]

Describe the problem:

When developing with cue, my backend converts the schema defined with cue into jsonschema. Based on this jsonschema, the system will automatically generate a front-end interface for users to input data. After the user has finished entering the data, the backend will verify it, thus completing the automated data verification process. During this process, I noticed that cue does not support the format password property. As a result, in some cases, the automatically generated OpenAPI documentation is not as complete or intuitive as expected. More importantly, due to the lack of format password support, the front end cannot know that an input should be encrypted, which may lead to security risks.

Describe the Solution:

To address the aforementioned issue, I experimented with the code to enable it to automatically append the format password when converting the schema.

Initially, within the types.go file, I located the comment //Todo: password in the cueToOpenapi function's type mapping. My plan was to introduce a format in the vein of // ""password"": "password". Although I gave this method a shot, it did not yield success.

Consequently, I pivoted to the extractFormat function within types.go and implemented the following code enhancement:

attrs := v.Attributes(cue.ValueAttr)
for _, attr := range attrs {
    if attr.Name() == "password" {
        return "password"
    }
}

With this modification, when we define a type as follows:

#Params: {
    pd: string @password()
}

It can now successfully auto-append format: password.

Provide background:

In OpenAPI, format password can be used to mark certain fields as passwords, which makes it possible to provide special treatment for them in UI or other tools, such as hiding input. Without this feature, we may need to manually modify the generated OpenAPI document or use other methods to mark these fields.

Need help：

I would like to ask whether this kind of thinking is correct or there are other simpler and more convenient ways that I have overlooked. This is not a functional requirement but a need help

[mvdan]

I would like to ask whether this kind of thinking is correct or there are other simpler and more convenient ways that I have overlooked. This is not a functional requirement but a need help

I've moved your issue to a Q&A discussion thread, hope that's okay.