Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What this PR does / why we need it:
It's been historically hard to put certain types/logic in a separate package in the SDK if that separate package depends on the backend package which create a cyclic dependency.
With #1019 I really wanted to put the most middleware logic in a separate package, but I couldn't due to cyclic dependencies.
With #1101 adding a new middleware to be shared with both SDK and Grafana would have make sense to put in a separate package, but again I couldn't due to cyclic dependencies. Adding these exported types to the backend package that normally plugin authors shouldn't have to use or care about doesn't feel optimal.
With #1106 we successfully explored/used type aliases to move certain structs, const and functions from the backend package to a separate package while keeping backward compatibility using type aliases for types and const and functions calling the respective const and function in the new package.
In an attempt to make the life easier for SDK maintainers and plugin authors this proposes a way to generate type aliases from a certain package into another package, in this example all "contracts" was moved to a
contracts
package from thebackend
package and then code generation generatescontracts_gen.go
in thebackend
package which is basically a mirror of any exported type in thecontract
package.For SDK maintainers, some changes earlier made in the backend package is now done in the contracts package followed by running codegen.
For plugin authors, there shouldn't be no change.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer: