swag: Doesn't working with import alias for struct fields
Describe the bug When we add import alias for custom type of struct field with this custom type that is not working.
To Reproduce Put the struct with custom type from other package and add alias for this custom type:
package build
import (
domainapp "domain/application"
)
type ListResponse struct {
BuildInfos []domainapp.BuildInfo `json:"data"`
Err error `json:"-"`
}
And some handler with comment
// @Success 200 {object} build.ListResponse
Run yaml:
swag init -g ./main.go --parseDependency --parseVendor
Result:
build.ListResponse:
properties:
data:
type: string
type: object
Expected behavior Expected result yaml:
build.ListResponse:
properties:
data:
items:
$ref: '#/definitions/application.BuildInfo'
type: array
type: object
Your swag version swag version v1.6.2
Your go version go version go1.12.5 linux/amd64
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 5
- Comments: 23 (13 by maintainers)
Commits related to this issue
- fix issue with import aliases (#483) — committed to dsxack/swag by deleted user 5 years ago
- fix issue with import aliases (#483) — committed to dsxack/swag by deleted user 5 years ago
- fix issue with import aliases (#483) (#573) — committed to swaggo/swag by dsxack 5 years ago
@Blquinn #736
I tried to find which swagger spec should be generated when we have go types with the same names in different packages.
I looked to specs some of the big go projects which I worked with: Kubernetes and Ory Hydra.
Authors of these specs put unique names of definitions with package prefix.
I think we should use
@definitionNamecomment above the struct instead of@definitionAliascomment. If we want to import an external package, it should be worrying itself about the unique name of definition by puts@definitionNamewith package prefix. Or we can provide the optional command line flag to generate definitions names with package prefix.@definitionNamecomment is will be like// swagger:model Clientcomment fromgo-swagger@ubogdan, could you respond to it?
@marbar3778, @alexanderbez, fix is merged into master. Could you check it in your project?
@marbar3778 yes, thanks for reminding me, I’m going to make PR for it tomorrow.
I can make PR if this issue will be accepted.