Feature request: optional "baseName" setting to control artifact naming

[f34nk]

smithy --version
[0.007s][warning][cds] Cannot handle shared archive file version 0xb. Must be at least 0xd.
1.71.0

Context

Smithy code generators derive artifact names (client classes, shared types, protocol helpers etc.) from the Smithy service shape id name (the #Name portion of the configured service shape id).

For many published AWS models, that shape id does not match the product name users expect, which results in sometimes surprising artifact names.

For example:

Configured service	Derived	User-expected
com.amazonaws.lambda#AWSGirApiService	AWSGirApiService	Lambda
com.amazonaws.dynamodb#DynamoDB_20120810	DynamoDB_20120810	DynamoDB

The @aws.api#service trait sdkId and endpoint metadata (endpointPrefix, signingName) describe runtime behavior but are not used for generated artifact names today. Service rename maps in the model can disambiguate shape name conflicts but are impractical for renaming upstream AWS service jars.

Language-specific settings such as Java namespace control the package or directory root only.

There is no cross-language, documented smithy-build.json setting to supply a human-readable service name without editing the model.

Proposal

Add an optional baseName property to the Recommended properties section of "Configuring the Generator".

Semantics

• Optional string. When unset, generators derive the name from the configured service shape id name (honoring the service rename map where applicable).
• When set, replaces the derived stem for all service-scoped generated artifacts (client, server, shared types, protocol helpers, auth helpers), not just the client.
• Value is the name without role suffixes (Client, _client, _types). Generators append suffixes as they do today.
• Validation is language-specific (Java PascalCase, Erlang snake_case)

Example (Java, using existing smithy-java support)

"java-codegen": {
  "service": "com.amazonaws.lambda#AWSGirApiService",
  "namespace": "com.amazonaws.lambda",
  "baseName": "Lambda",
  "modes": ["client"]
}

Would produce com.amazonaws.lambda.client.LambdaClient instead of AWSGirApiServiceClient.

Example (Erlang, using smithy-beam support)

"erlang-client-codegen": {
  "service": "com.amazonaws.lambda#AWSGirApiService",
  "edition": "2026",
  "baseName": "aws_lambda"
}

Would produce Erlang modules such as aws_lambda_client, aws_lambda_types etc. (exact suffix rules remain language-specific).

Why platform-level guidance

• smithy-java already implements "name" in JavaCodegenSettings but it is undocumented in the Smithy guide and in the Java client generation docs.
• Other language generators have no equivalent setting today.
• Documenting name as a recommended property gives users one predictable override across languages.

Out of scope

• Automatically deriving names from AWS sdkId will be inconsistent across services.
• Renaming individual model shapes (already handled by service rename maps).
• Replacing namespace / package settings (those remain package-root concerns).

[kstich]

The @aws.api#service trait sdkId ... describe runtime behavior but are not used for generated artifact names today.

Automatically deriving names from AWS sdkId will be inconsistent across services.

Having a client base name is exactly what this field is for in AWS services that cannot make changes to their service shape names for other reasons. From the spec:

The sdkId property is a required string value that specifies the AWS SDK service ID (e.g., "API Gateway"). This value is used for generating client names in SDKs and for linking between services.

[JordonPhillips]

I could have sworn we used the title trait for this too, but I checked a few generators and it's only used for docs.

[f34nk]

Thank you for pointing this out.
TBH I didn't recognize the sdkId in the JSON AST before.
"sdkId": "DynamoDB"
"sdkId": "Lambda",

Since I build the code using the JSON AST directly, my expectation was that Smithy will pick up the "right name" automagically.

But it doesn't !? At least not with this smithy-build.json.
For service "com.amazonaws.dynamodb#DynamoDB_20120810"

Is there something I should do differently?

[f34nk]

I've tested with the Java codegen following the documentation for service-sdk-id.

See this branch and this model.

As per spec

This value is used for generating client names

My expectation would be that the filename/classname will be something like "SomeValueClient".
But the generated client is: Foo_123Client

[edit]
Overriding "name" property in the build config fixes this.
"name": "Bar",
This correctly generates BarClient.java

[f34nk]

From what I see: sdkId is ignored for naming.
Client names come from JavaCodegenSettings.name()

• JavaCodegenSettings sets name from the optional "name" build property, or falls back to service.getName() (which is the #Name part)
• DirectedJavaCodegen passes that into JavaSymbolProvider as serviceName
• The client is {serviceName}Client