Package.swift: declarar objetivos, dependencias y fronteras

El manifiesto es el único archivo del proyecto que no puede mentir sobre la arquitectura, porque el sistema de compilación lo obedece literalmente. Un diagrama en la wiki describe intenciones; Package.swift describe hechos, y esos hechos se comprueban en cada compilación. La consecuencia práctica es que aprender a leer un manifiesto ajeno es aprender a leer el diseño de esa app en dos minutos, y que escribir el tuyo con cuidado equivale a escribir las reglas de acoplamiento en un lenguaje que la máquina entiende. Esta lección lo recorre entero, no como referencia de sintaxis, sino como el sitio donde se toman las decisiones que las lecciones anteriores solo podían recomendar.

Las cuatro secciones y qué decide cada una

Un manifiesto es código Swift que se ejecuta para producir una descripción del paquete. platforms fija la versión mínima de cada sistema y determina qué API puedes usar sin comprobaciones de disponibilidad. products declara qué bibliotecas ve el mundo exterior, es decir, qué puede importar el objetivo de app del proyecto de Xcode. dependencies lista los paquetes externos con su rango de versiones. Y targets describe el grafo interno, que es donde vive la arquitectura de verdad.

// swift-tools-version: 6.0
import PackageDescription

let package = Package(
  name: "MiAppKit",
  platforms: [.iOS(.v17), .macOS(.v14)],
  products: [
    .library(name: "AppFeature", targets: ["AppFeature"]),
    .library(name: "PerfilFeature", targets: ["PerfilFeature"]),
  ],
  dependencies: [
    .package(
      url: "https://github.com/pointfreeco/swift-composable-architecture",
      from: "1.15.0"
    ),
  ],
  targets: [
    .target(name: "Modelos"),
    .target(name: "APIClient", dependencies: ["Modelos", .tca]),
    .target(name: "APIClientLive", dependencies: ["APIClient"]),
    .target(name: "PerfilFeature", dependencies: ["APIClient", "Modelos", .tca]),
    .target(name: "AjustesFeature", dependencies: ["Modelos", .tca]),
    .target(
      name: "AppFeature",
      dependencies: ["PerfilFeature", "AjustesFeature", "APIClientLive", .tca]
    ),
    .testTarget(name: "PerfilFeatureTests", dependencies: ["PerfilFeature"]),
  ]
)

Dos cosas merecen atención inmediata. La primera es que solo declaro como producto lo que el proyecto de Xcode necesita importar; los objetivos internos no publicados siguen siendo perfectamente utilizables entre ellos, y no publicarlos evita que alguien los importe desde fuera por accidente. La segunda es que PerfilFeature depende de APIClient y no de APIClientLive: esa única línea es la que impide que compilar la feature arrastre URLSession, credenciales, reintentos y el resto de la implementación real.

Azúcar para que el grafo se lea de un vistazo

Escribir la forma larga de una dependencia externa en cada objetivo hace el manifiesto ilegible justo donde más importa que se lea. La convención que Point-Free popularizó es declarar una extensión al final del archivo y usar nombres cortos arriba.

extension Target.Dependency {
  static var tca: Self {
    .product(name: "ComposableArchitecture", package: "swift-composable-architecture")
  }
  static var dependencias: Self {
    .product(name: "Dependencies", package: "swift-dependencies")
  }
}

El beneficio inmediato es cosmético, pero el importante es de mantenimiento: cuando un paquete externo cambia de nombre de repositorio o de módulo, editas una línea en lugar de cuarenta. El beneficio real, sin embargo, es que la sección targets queda tan compacta que el grafo se percibe como una figura. Si al mirarla no puedes decir en diez segundos quién depende de quién, el problema no es el formato: es que el grafo está mal.

Lo que la lista de dependencias hace imposible

Aquí está el núcleo de la lección. La lista de dependencias de un objetivo define exactamente el conjunto de módulos que sus archivos pueden importar; cualquier otro import produce un error de módulo no encontrado. Eso convierte tres reglas de arquitectura, que en un monolito solo podías pedir por favor, en propiedades verificadas.

La primera es la no vecindad entre features hermanas. PerfilFeature no lista AjustesFeature, luego no puede importarla, luego no puede llamarla, luego cualquier coordinación entre ambas tiene que subir al padre en forma de acción delegate. La segunda es el corte entre interfaz e implementación: como ninguna feature lista APIClientLive, ninguna feature puede construir el cliente real ni siquiera por accidente, y la inyección queda forzosamente en el objetivo raíz. La tercera es la ausencia de ciclos: el resolutor de SPM rechaza un grafo cíclico con un error explícito, de modo que la clase de acoplamiento más tóxica —dos módulos que se necesitan mutuamente— es directamente inexpresable.

Vale la pena insistir en la asimetría que produce el corte del cliente, porque es el patrón que más se copia mal. La interfaz debe ser tan liviana que dependa solo del dominio y de la librería de dependencias: un struct de closures, sus valores de test y de preview y nada más. La implementación viva puede ser tan pesada como haga falta, porque solo la enlaza quien construye la app. Cuando alguien mete en la interfaz una constante que necesita el SDK real, o un tipo que viene del framework de red, la frontera sigue declarada pero ya no separa nada, y el síntoma aparece semanas después en forma de previews que tardan un minuto.

Ajustes por objetivo, y por qué desde el primer día

Cada objetivo acepta swiftSettings, y hay dos ajustes que conviene fijar antes de que el código crezca. El modo de lenguaje determina si la concurrencia estricta es un aviso o un error, y las funcionalidades futuras permiten adoptar de forma gradual comportamientos que serán obligatorios en versiones posteriores.

extension SwiftSetting {
  static let estricto: [SwiftSetting] = [
    .swiftLanguageMode(.v6),
    .enableUpcomingFeature("ExistentialAny"),
  ]
}

.target(name: "PerfilFeature", dependencies: ["APIClient", .tca], swiftSettings: .estricto)

Que el ajuste sea por objetivo es exactamente lo que hace viable una migración: puedes poner en modo estricto los módulos nuevos y las capas bajas, que casi no tienen concurrencia, y dejar en modo permisivo los objetivos heredados mientras los conviertes uno a uno. En un monolito esa gradualidad no existe; el cambio es global y por eso se pospone para siempre.

flowchart TD
App[AppFeature] --> P[PerfilFeature]
App --> A[AjustesFeature]
App --> L[APIClientLive]
P --> I[APIClient interfaz]
A --> M[Modelos]
P --> M
I --> M
L --> I
P -. no declarada .-x A
style I fill:#a6e3a1,color:#11111b
style L fill:#fab387,color:#11111b