Feature request: Flag to Mark Generated Code as Package Private

[bpholt]

Motivation: allowing libraries to generate smithy4s clients intended for use only within the library, avoiding binary compatibility issues caused by differences in the generated code over time.

Such a feature would remove the need for the Scalafix referenced in #1589.

[Baccata]

I'm not necessarily opposed to it but you'd have to propose semantics (in this issue) and implement them yourself once @kubukoz and I have agreed to it.

[kubukoz]

I finally have a usecase so I want it 😅

We usually configure this kind of thing via traits or metadata. I would use Validated Newtypes as inspiration, and implement both:

• apply the trait explicitly if you want fine-grained control and need only a small number of private shapes
• set metadata if you want a large blast radius.

I wouldn't apply the metadata globally, though.

metadata smithy4sExtraModifiers = [
  {
    "selector": "[id|namespace=foo.bar] ~>"
    "modifiers": "private[foo]" // allow anything here, if it's broken it won't compile, and we'll futureproof ourselves by letting people add `open` or whatever they desire from day 1
  }
]

Selectors are flexible enough that you can choose any number of shapes, filter them by transitive relationships and so on.

---

Implementation-wise, I would have a transformation that adds the trait based on the metadata's selectors, then the codegen can just look for the trait (that's also pretty much how the validated newtypes work).

The big question I have is: do we want to retain that information in the model, for further codegen runs? Validated newtypes are retained in CodegenRecord, but that's because it was necessary to know what to generate on the use-site - we probably don't need that here.

[kubukoz]

TBH I'd like selector-based metadata application in validated newtypes too. Maybe this could be the general pattern for configuring such things.