Swift Package Manager Series 03｜Concepts clés dans Package.swift

Lorsque vous ouvrez Package.swift pour la première fois, votre première impression sera : le fichier n’est pas long et la syntaxe n’est pas compliquée.

Mais il est facile de se tromper une fois que vous démarrez réellement le projet, car la difficulté ne réside pas du tout dans “la syntaxe ressemble-t-elle à Swift”, mais dans le fait que plusieurs concepts de base correspondent en fait à la structure du projet, et non aux éléments de configuration ordinaires.

Si vous le considérez simplement comme une « liste à remplir quelques champs », vous aurez souvent l’impression de connaître chaque mot, mais cela deviendra facilement confus lorsque vous le modifierez. Ce qu’il faut vraiment comprendre, c’est à quelles questions répondent ces concepts.

Le plus important est de commencer par saisir ces rôles essentiels :

• forfait
• produits
• les dépendances
• les cibles

1. Package.swift décrit les relations entre les modules

C’est la première étape pour le comprendre.

Une situation courante est que vous y pensez inconsciemment comme :

-Fichier de configuration du projet

• Dépend des fichiers d’installation
• ou “Podspec pour Swift”

Mais d’un point de vue technique, Package.swift ressemble davantage à une spécification de relation de module. Cela indique à la chaîne d’outils :

• Qu’apporte ce package au monde extérieur ?
• De quels packages externes cela dépend-il ?
• De quelles cibles sont composées les cibles en interne ?
• Comment ces objectifs sont liés les uns aux autres

Il se concentre donc sur “comment ce code doit être organisé en modules et utilisé par d’autres”.

2. products répond : Quelles capacités ce package veut-il offrir au monde extérieur ?

C’est le point le plus facilement négligé lorsqu’on traite initialement ce type de problème.

target est l’unité interne du bâtiment et product est le résultat consommable externe.

En d’autres termes, la question à laquelle répond product est :

Qu’est-ce que ce package est finalement destiné à exposer à ses utilisateurs ?

Il y a un signal de conception très important derrière cela. Si vous n’avez aucune idée de product, il est facile de confondre la structure interne du package avec son utilisation externe.

Bien sûr, il peut y avoir plusieurs cibles à l’intérieur d’un package, mais l’extérieur n’a pas nécessairement besoin de connaître toutes ces divisions internes. Ainsi, product emballe essentiellement l’interface externe.

Si vous le comprenez sous cet angle, vous penserez plus naturellement :

• Quelles cibles internes sont des détails de mise en œuvre
• Quelles capacités doivent vraiment être exposées ?
• Quel niveau les personnes à charge externes doivent-elles voir ?

3. Réponses de dependencies : Quelles capacités ce package emprunte-t-il au monde extérieur ?

Quand j’ai vu cette situation dependencies, j’ai juste pensé à “installer une bibliothèque tierce”.

Mais d’un point de vue technique, sa signification la plus importante est la suivante :

En dehors des limites de ce module, de quel monde extérieur dépend-il.

Cela affectera directement :

• Le module est-il suffisamment léger ?
• Est-ce cher à compiler ?
• Est-il facile de le réutiliser à l’avenir ?
• Cela liera-t-il également le projet hôte à certaines dépendances externes ?

Si un module possède trop de dépendances externes, cela posera souvent deux problèmes :

• Ce n’est plus léger
• Ses limites commencent également à devenir floues

Ainsi, lorsque vous regardez le dependencies, ne pensez pas seulement à « peut-il être installé », mais pensez également à « pourquoi ce module doit-il s’appuyer sur ces éléments ».

4. Réponses targets : Comment le code interne doit-il être organisé et compilé ?

Il s’agit de la partie du Package.swift qui est la plus facilement considérée comme un « mappage de dossiers », mais elle est en réalité bien plus que cela.

target correspond réellement à :

• Un groupe de codes compilés ensemble
• Une unité de dépendance explicite
• une limite de module interne

Lorsque vous définissez la cible, vous décidez :

• Quels codes doivent évoluer ensemble
• Quelles implémentations doivent être placées dans la même unité de compilation
• Quels tests doivent correspondre à cette limite

La cible est donc l’une des plus petites unités de transport de modularité interne.

Si vous divisez la cible en trop de morceaux, le projet deviendra plus lourd. Si la cible est trop grande, les limites seront floues. Cela montre également que Package.swift semble n’être qu’une configuration, mais comporte en réalité de nombreux jugements architecturaux.

5. Confondre product avec target

Car dans des packages simples, ils correspondent souvent un à un.

Par exemple :

• une cible
• un produit de bibliothèque

À l’heure actuelle, il est facile de penser à tort que les deux concepts sont similaires. Mais une fois le projet un peu plus compliqué, vous découvrirez :

• Un package peut avoir plusieurs cibles
• Plusieurs cibles peuvent servir un seul produit
• Certaines cibles ne sont que des implémentations internes et ne doivent pas être exposées directement

Mon expérience est donc la suivante : **Comprenez la cible comme la structure interne et le produit comme le débouché externe. **

De cette façon, la réflexion deviendra immédiatement beaucoup plus claire.

6. L’objectif des tests est également très important

Lorsque vous verrez Package.swift pour la première fois, vous considérerez la cible de test comme une configuration accessoire. Mais du point de vue de la pensée modulaire, c’est en réalité très important.

Parce que la valeur d’un module n’est pas digne d’une existence indépendante, elle se reflète également dans une large mesure dans :

• Peut-il être testé indépendamment
• Si ses limites de dépendance sont suffisamment claires
• S’il peut vérifier le comportement principal sans s’appuyer sur l’application hôte

Si un module doit s’appuyer sur la moitié du projet hôte pour chaque test, alors même s’il s’agit d’un package de nom, les limites peuvent ne pas être indépendantes en fait.

7. Un ordre de lecture plus pratique

Si j’ouvre Package.swift pour un projet inconnu pour la première fois, je le regarde généralement dans cet ordre :

1.products Voyons d’abord ce qu’il expose au monde extérieur. 2. dependencies Regardons ce qu’il a emprunté au monde extérieur 3. targets Voyons enfin comment l’intérieur est démonté.

Les avantages de cette séquence sont : Regardez d’abord les limites, puis regardez à l’intérieur, plutôt que de vous enliser dans les détails de mise en œuvre.

8. Conclusion : La difficulté de Package.swift ne réside pas dans la syntaxe, mais dans le fait qu’il décrit réellement les limites du projet.

Pour le dire sous une forme plus courte, je dirais :

Package.swift La chose la plus importante est de savoir si vous pouvez comprendre la relation de frontière derrière product, dependency et target.

Une fois compris sous cet angle, ce fichier n’est plus seulement une configuration, mais une expression condensée de la conception du module.