# SourceryTemplates: Stencils for Type Erasure, AutoInterface, and AutoPropertiesProtocol in Swift > This repository offers three Sourcery templates that generate Swift code for type erasure, protocol interfaces, and property-based protocol composition. It is a useful starting point for teams already using Sourcery, but the templates are early drafts with limited real-world testing. **AliSoftware/SourceryTemplates** — Some templates to use for Code Generation in Swift with http://github.com/krzysztofzablocki/Sourcery - Repository: https://github.com/AliSoftware/SourceryTemplates - Stars: 100 · Forks: 10 - Language: HTML - License: MIT - Published: 2026-08-17 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/alisoftware-sourcerytemplates ## What SourceryTemplates Solves SourceryTemplates addresses a specific gap in Swift development: repetitive, boilerplate code around protocols. Swift's type system often forces developers to write manual type erasure wrappers, duplicate protocol declarations, or verbose dependency injection setups. This repository provides three Stencil templates that plug into Sourcery, a code generation tool that parses Swift source and emits new code. The templates are for developers who already use Sourcery and want to automate these patterns. The README targets Swift engineers working on projects with protocols that have associated types, classes that need interface abstractions for testing, and dependency injection via protocol composition. It is not a general-purpose code generator; it is a focused set of templates for three specific use cases. ## How the Templates Work: Annotations and Stencils Each template relies on Sourcery's annotation system. You mark your Swift types with comments like `// sourcery: TypeErase = PokemonType`, and Sourcery reads those annotations along with the type's structure. The Stencil files in the `Templates/` directory then generate Swift code. The mechanism is straightforward: Sourcery parses your source, matches the annotations, and applies the template logic. For the TypeErase template, you annotate a protocol with the associated type you want to erase. The template generates a concrete wrapper class that hides the associated type, following the pattern described in a BigNerdRanch article. For AutoInterface, you conform a class or struct to a phantom protocol named `AutoInterface`, and the template generates a protocol with the same API, prefixing the name with `I` by default. For AutoPropertiesProtocol, you conform a type to another phantom protocol, and the template generates one protocol per property, each exposing a single property. The output is a `.generated.swift` file that you add to your Xcode project. ## Getting Started: Commands and Configuration The README does not provide a command-line invocation for Sourcery, but it describes the workflow. You need Sourcery installed, which you can obtain from its own repository. Then you point Sourcery at your source files and the template. For example, you would run something like `sourcery --sources . --templates Templates/TypeErase.stencil --output TypeErase.generated.swift`. The exact command depends on your Sourcery version, but the README implies this pattern. Configuration is annotation-driven. For AutoInterface, you can customize the generated protocol name using `// sourcery: AutoInterfacePrefix = ...`, `// sourcery: AutoInterfaceSuffix = ...`, or `// sourcery: AutoInterface = ...` to force an exact name. For AutoPropertiesProtocol, you use `PropertiesProtocolPrefix` and `PropertiesProtocolSuffix` annotations, and you can apply them to all properties of a type using `// sourcery:begin` and `// sourcery:end` blocks. The demo project `TemplatesDemo.xcodeproj` contains unit tests that show usage examples, so you can see the templates in action without setting up Sourcery yourself. ## The TypeErase Template: A First Draft with Known Gaps The TypeErase template is the most prominent in the repository, but the author is candid about its maturity. The README says: 'This is a first draft of the template, so please don't hesitate to improve it' and 'I haven't tested a lot of real-world use cases yet so some corner cases are probably missing.' This is a genuine limitation. If your protocols have complex associated type constraints, multiple associated types, or methods that use the associated type in complex positions, the template may generate incorrect or non-compiling code. The examples given are simple: a `Pokemon` protocol with one associated type and one method, and a `Row` protocol with a property and a method. The generated file in `UnitTests/Generated/TypeErase.generated.swift` shows the output for those cases, but it does not cover edge cases like associated types with where clauses or recursive usage. For production code, you would need to test the template against your own protocols and likely modify it. ## AutoInterface and AutoPropertiesProtocol: Useful but Narrow AutoInterface generates a protocol from a class or struct's public API. This is useful for creating mocks in tests or for abstraction. The default naming convention prefixes the type name with `I`, which is a common but opinionated style. The generated protocol includes all properties and methods, as shown in the example where `UserWSClient` becomes `IUserWSClient`. AutoPropertiesProtocol takes a different approach: it generates one protocol per property, each named with a `Has` prefix by default. This enables protocol composition for dependency injection, as described in the linked article by Merowing. The pattern lets you pass a single struct containing all dependencies while only exposing the properties a given consumer needs. Both templates rely on phantom protocols (`AutoInterface` and `AutoPropertiesProtocol`) that you must declare in your code. This is a clean opt-in mechanism, but it means you need to add those empty protocols to your project, which is a small extra step. ## Limitations and When It Is the Wrong Tool The main limitation is the lack of maintenance. The repository has no recent releases, and the last push is unknown, which suggests it may be stale. Sourcery itself evolves, and template syntax may break with newer versions. The TypeErase template is explicitly a draft. AutoInterface and AutoPropertiesProtocol are more stable, but they only handle simple cases. If your types have access control modifiers, generics, or inheritance, the generated protocols may not reflect those correctly. The README does not document how the templates handle private or internal members, so you must verify. This is the wrong tool if you need a fully supported, production-ready code generation solution. It is also wrong if you are not already committed to Sourcery, because the templates add a layer of complexity on top of an already complex tool. For a one-off project, writing manual type erasure might be simpler than integrating Sourcery and debugging template output. ## Alternatives and Maintenance Considerations A direct alternative is to write your own Stencil templates for Sourcery. Sourcery's documentation and community provide examples for AutoMockable and AutoEquatable, which are more widely used and tested. Those built-in templates cover mocking and equality, but not type erasure or interface generation. For type erasure specifically, you could use Swift's `any` keyword (available since Swift 5.7) which provides existential types and may eliminate the need for manual type erasure in many cases. That is a language-level alternative, not a template. For dependency injection, you could use a library like Needle or Dip, but those are heavier solutions. Maintenance cost: the templates are MIT licensed, so you can fork and modify them. The README invites pull requests, but there is no evidence of active maintenance. You should check the templates against your Sourcery version before relying on them. The license permits commercial use, but you are responsible for ensuring the generated code meets your needs. ## Final Assessment: Who Should Adopt and What to Verify SourceryTemplates is a small, focused repository that demonstrates how to use Sourcery for three specific patterns. It is most valuable as a learning resource or a starting point for your own templates. If you adopt it, verify the generated code for your specific types, especially for TypeErase, which is the least tested. Check that the templates work with your Sourcery version, as template syntax can change. Also, inspect the demo project to understand the expected output. The repository's value is in its examples and the patterns it shows, not in being a polished library. The lack of releases and the author's own caveats mean you should treat it as a reference implementation, not a dependency. If you need reliable code generation, invest time in writing and testing your own templates or use Sourcery's built-in ones. The MIT license gives you freedom to adapt, but the burden of correctness is on you. ## Conclusion Adopt SourceryTemplates if you already use Sourcery and need quick, annotation-driven generation for type erasure, interface protocols, or property-based dependency injection. Do not adopt it if you require production-tested templates with broad edge-case coverage, as the author explicitly states the type erasure template is a first draft and not tested on many real-world cases. Before adopting, verify the generated code against your own protocols and associated types, and check that the templates' output matches your Swift version and Sourcery release. For a more maintained alternative, consider writing your own Stencil templates tailored to your codebase or using Sourcery's built-in AutoMockable and AutoEquatable templates, which are more widely documented and tested. ## FAQ ### What are the three types of templates in SourceryTemplates? The repository ships four named ones: TypeErase for type-erasing annotated protocols, AutoInterface for generating a protocol that matches a type's API, AutoPropertiesProtocol for one protocol per property, and AutoCaseName for comparing enums with associated values regardless of their payloads. It also links outward to places where more templates can be found. ### How do you use a Sourcery template in SourceryTemplates? Annotate or conform in your own source, run the Stencil file from Templates/ with Sourcery, then add the generated Swift file to your Xcode project by hand. For example TypeErase produces TypeErase.generated.swift and AutoInterface produces AutoInterface.generated.swift, each already committed under UnitTests/Generated. ### Is sorcery TCG a good investment? That question has nothing to do with this repository. SourceryTemplates is a set of Stencil templates for code generation in Swift, used with the Sourcery generator, and it contains nothing about trading cards, markets or investment. ### How do you play sorcery? There are no game rules here. The only sorcery in this repository is code generation: a phantom protocol such as protocol AutoInterface {} is declared, your types conform to it to opt in, and the template generates the Swift code for the annotated types. ## Sources - [Official README](https://github.com/AliSoftware/SourceryTemplates#readme) - [Project repository](https://github.com/AliSoftware/SourceryTemplates) - [README](https://github.com/AliSoftware/SourceryTemplates/blob/master/README.md) - [Releases](https://github.com/AliSoftware/SourceryTemplates/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/alisoftware-sourcerytemplates