Support Code Import Aliases

[bflad]

Description

Currently the specification relies on a single string value to declare a necessary code import for a piece of code. In practice though, package naming can overlap and require using programming language features such as import aliasing. While generators could generally support aliasing within the string itself to match language conventions, it would be more expressive if the specification was more explicit about the correct way to handle this coding issue.

Proposal

In the specification, create a new shared object definitions:

"code_import": {
  "type": "object",
  "properties": {
    "alias": {
      "type": "string",
      "minLength": 1
    },
    "import": {
      "type": "string",
      "minLength": 1
    }
  },
  "required": [
    "import"
  ]
},
"code_imports": {
  "type": "array",
  "items": {
    "$ref": "#/$defs/code_import"
  },
  "minItems": 1
},

In the specification, where an import is defined as single string value, migrate to new definition:

"$ref": "#/$defs/code_import"

In the specification, where import is defined as an array of string values, migrate to new definition:

"$ref": "#/$defs/code_imports"

In the Go bindings, create a new code package and Import type:

package code

type Import struct {
  Import string `json:"import"`

  Alias *string `json:"alias,omitempty"`
}

Update Import/Imports fields in other types to use new code.Import type.

[github-actions[bot]]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.