Meta("struct:pkg:path", "foo/bar") doesn't work. about goa

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[Albert-Coding]

Poke

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[Albert-Coding]

Poke

[tchssk]

There are two issues:

1. Unneeded package name prefix for a qualified identifier (e.g. payloads.Associations) (resolved by #3469)
2. Missing imports (e.g. data)

The second issue is unclear whether it is a specification or a bug. The Meta DSL's godoc says:

Note: If that meta tag is used more that once in the same design, but with different values in the meta statement (ex. one type has Meta("struct:pkg:path", "types1") and another has Meta("struct:pkg:path", "types2")) then those two types cannot both contain a field of the same user type. For the same reason, you may not set a different custom package in a user type than the one set on a containing user type.

This specification can be reproduced by changing design as follows.

-Field(1, "resources", ArrayOf(Resource))
+Field(1, "resources", Resource)

goa gen outputs the following error:

attribute: type "Resource" has conflicting packages common/data and common/payloads

Should Goa print the same error for Array types?
Or can we improve the specification by resolving the missing imports?

[raphael]

Thank you for looking into this! This limitation was to help keep the implementation simple.

The main use case for struct:pkg:path is to make it possible for the code generated from two different services in the same design to share the same type definitions (by using the same package path in types defined in both). This makes it convenient for user code as the same type can be reused across as opposed to having to instantiate service specific structs. The intent (at least initially) was not to make it possible to define a complex set of packages. At the end of the day the code is generated so creating a modular set of packages has limited benefits.

For example making it possible to define multiple packages for types that are related would mean having to write code that detect circular dependencies. In general the code that deals with external packages is already pretty complex so my vote would be to make sure that the ArrayOf case generates the proper error message.

That being said if there is a strong case for making it possible to create multiple packages with types that have fields defined across the packages and if we can find an easy way to support it then that's great.

[tchssk]

That's nice, but it will take some time to design, so I'll add an error message for now.
Thank you.

[raphael]

Great, thank you for the PR!

[raphael]

Closing this issue, the TL;DR is that there was a bug and a missing validation. The decision is to not allow defining complex package types so as to keep the code simple.