Code layout #
Many developers may prefer to have the generated code organized in a specific way, so that it is easier to navigate and
maintain. go-asyncapi
supports customizing the generated code layout, i.e. how the generated code will be broken down by
packages and files.
Layout is the list of rules that includes condition and rule parts. During the generation process, every entity is checked against every rule, and if it matches, it’s rendered according to the rule.
Entities that do not match any rule are ignored. This means, for example, if you would have empty rules list, the tool would not generate any code at all.
So, the layout rules may be used for the following purposes:
- Grouping the code by packages and files in any way.
go-asyncapi
automatically recalculates the correct code imports in the generated code once layout has changed. - Reusing the code from the existing modules. Technically, the entities Go definitions matched by this rule are not generated, but instead the tool will add a Go import from the specified module.
- Setting the custom code template specific for a rule. Useful when a particular entity should be rendered in a specific way.
Once you have set a custom layout, it’s recommended to remove old generated code and regenerate it.
For more information see the Configuration page.
Default layout #
By default, the code is generated in a way that every entity type (like channels, servers, schemas, etc.) is put into a separate package, and every single entity is put into a separate file.
Examples #
The following example produces the layout, where everything is put into target directory in one package as separate
files with name <entity_type>_<entity_name>.go
, e.g. channel_channel1.go
, server_server1.go
, etc.
The next example places all protocol-agnostic entities into the common
package, and protocol-specific entities into
packages with the protocol name.
What about to put entities (except for schemas) only with specific name prefix into a separate package, while keep everything else in default layout? More about regex syntax in Go
The following example shows how to generate only the schemas, ignoring all other entities.
Finally, let’s put everything into one file.
Implementations #
Implementations code layout is configured separately, because it is not related to the AsyncAPI entities.
By default, the code is put to impl
package, and each protocol has its own subpackage.
For example, we can change the layout to put implementations into subpackages named after the implementation name instead of protocol name.
To disable the injecting the implementations code, you can use --disable-implementations
CLI flag or enable the
setting in the configuration file:
code:
disableImplementations: true