Hello! With the legacy `swiftExport { }` DSL we co...

# swift-export

[Guilherme Delgado]

Hello! With the legacy swiftExport { } DSL we could rename/repackage a directly-exported api project dependency from the consumer side:

swiftExport {
    moduleName = "Composables"
    export(projects.sharedModels) {
        moduleName = "Models"
        flattenPackage = "com.sample.models"
    }
}

With the replacement export { swift { } } DSL (using Kotlin 2.5.0-Beta1-73), SwiftExportConfigurationDsl/xcodeIntegration { } only expose moduleName/rootPackage for the module itself — there’s no export(dependency) { } (or configure(dependency) { }) to override a dependency’s name/package, and self-declaring moduleName/rootPackage in the dependency’s own export { swift { } } block seems to be ignored for same-build project dependencies (logs No name for ‘packageRoot’ and will be ignored). The dependency ends up exported under its auto-derived name (project path → PascalCase).
Is there a supported way to get the old renaming behavior with the new DSL today, or is this still work in progress?

[egorand]

Hey, thanks for trying out the new DSL!

The functionality didn’t fully make it into Beta1, but Beta2 will ship with more options to configure exported modules:

• There will be a configure(...) { ... } API that roughly matches the legacy export in shape and allows overriding configurations on the consumer side.
• Overrides made via export.swift { ... } inside an exported subproject’s build.gradle.kts (projects.sharedModules in your case) will be picked up by the exported module.

[Guilherme Delgado]

Thanks for info! 😊