Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

misc: add visibility build setting #951

Merged
merged 18 commits into from
Sep 19, 2023
Merged

misc: add visibility build setting #951

merged 18 commits into from
Sep 19, 2023

Conversation

lauzadis
Copy link
Contributor

@lauzadis lauzadis commented Sep 13, 2023

This PR updates build settings to allow configuring visibility for serviceClient, structure, and error. This corresponds to visibility on the generated service client, Smithy Structure shapes, and Smithy Error shapes, respectively.

Issue #

N/A

Description of changes

This change is required so we can generate internal-only SDK clients with the proper internal visibility, so they don't show up in the public API footprint.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@lauzadis lauzadis marked this pull request as ready for review September 13, 2023 20:47
@lauzadis lauzadis requested a review from a team as a code owner September 13, 2023 20:47
@lauzadis lauzadis changed the title misc: generate internal-only clients with internal visibility misc: add visibility build setting Sep 13, 2023
@@ -160,6 +161,7 @@ data class BuildSettings(
val generateDefaultBuildFiles: Boolean = true,
val optInAnnotations: List<String>? = null,
val generateMultiplatformProject: Boolean = false,
val visibility: VisibilitySettings = VisibilitySettings.Default,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These aren't really "build" settings since this type doc comments explicitly talk about gradle build settings. I think maybe we want a new type like "API" settings?

) {
companion object {
const val SERVICE_CLIENT = "serviceClient"
const val STRUCTURE = "structure"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

correctness

I'm not sure we want to model visibility of structure and error settings separate from the service client. If you set structure or error visibility to internal then the service client isn't going to compile anyway. Do we validate the combination of settings? What other use cases are we thinking about?

From where I'm sitting at the moment I think we can get away with the same visibility for all of these (which is either public (default) or internal because private doesn't make sense and will also not compile). I suggest we collapse these to just visibility and make them all the same from that (also validate fromNode settings in tests).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah this is one thing I expected discussion about. I started with SERVICE_CLIENT and then decided to add STRUCTURE/ERROR to cover the remaining codegenned portions, but I do think collapsing them into one config option makes sense.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I recommend using an enum too instead of a string.

) {
companion object {
const val SERVICE_CLIENT = "serviceClient"
const val STRUCTURE = "structure"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I recommend using an enum too instead of a string.

Comment on lines 73 to 75
writer.write("public const val ServiceId: String = #S", ctx.settings.sdkId)
writer.write("public const val SdkVersion: String = #S", ctx.settings.pkg.version)
writer.write("$visibility const val ServiceId: String = #S", ctx.settings.sdkId)
writer.write("$visibility const val SdkVersion: String = #S", ctx.settings.pkg.version)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: Mix templating styles makes codegen harder to read. I recommend using #L instead of $visibility. Applies to other changes in this PR.

Comment on lines 204 to 215
enum class Visibility(val value: String) {
PUBLIC("public"),
INTERNAL("internal"),
;

companion object {
public fun fromValue(value: String): Visibility = when (value.lowercase()) {
"internal" -> INTERNAL
else -> PUBLIC
}
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion: Consider overriding toString to return value so that you don't have to call .value so many places in codegen.

Comment on lines 210 to 213
public fun fromValue(value: String): Visibility = when (value.lowercase()) {
"internal" -> INTERNAL
else -> PUBLIC
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correctness: This means silently ignoring the caller's intent when we don't understand it, leading to typos like "itnernal" being treated as PUBLIC. I think we should throw an exception if we don't understand the input value.

@sonarqubecloud
Copy link

SonarCloud Quality Gate failed.    Quality Gate failed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 4 Code Smells

No Coverage information No Coverage information
25.4% 25.4% Duplication

idea Catch issues before they fail your Quality Gate with our IDE extension sonarlint SonarLint

@lauzadis lauzadis merged commit d40e71f into main Sep 19, 2023
8 of 9 checks passed
@lauzadis lauzadis deleted the misc-internal-clients branch September 19, 2023 18:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants