I'm pretty sure it could work, but this approach doesn't scale. I don't want to (have to) maintain a fork of every library that we adopt that happens to use the package just to be able to use macros without building swift-syntax. Concerns around swift-syntax are already being discussed:
- Macro Adoption Concerns around SwiftSyntax
- How to avoid SwiftSyntax annoyance? · Issue #329 · apple/swift-openapi-generator · GitHub
- How to avoid SwiftSyntax annoyance? · pointfreeco/swift-snapshot-testing · Discussion #794 · GitHub
- Being a good citizen in the land of SwiftSyntax
But that's not the point of this thread.
For now, since aliasing doesn't seem to be working for me (possibly because I'm using it wrong), I'm probably going to try... a different kind of aliasing by renaming parts of the swift-syntax package before building, hopefully eliminating the clash that way...
In case anyone is wondering why I care about building macros fast if the app already depends on swift-syntax, the app is heavily modularized and it is rare devs need to build the whole thing - rather, the typical workflow is opening small feature packages and working on those. And in such cases, building swift-syntax would be the majority of compile time.