| 🛟 Updated. 28d5985 k33g 20h ago | 1 | # Comment tester une modification de turbo-core sans la publier |
| 2 | |
| 3 | Ce guide montre comment faire tourner Turbo Go ou Turbo Rust sur un turbo-core que vous n'avez modifié que localement, afin de voir un changement de bibliothèque fonctionner avant de décider qu'il mérite un numéro de version. Il suppose que les trois dépôts sont côte à côte. |
| 4 | |
| 5 | ## Le problème |
| 6 | |
| 7 | Les éditeurs dépendent de turbo-core comme n'importe qui d'autre : par chemin de module et par version. |
| 8 | |
| 9 | ``` |
| 10 | require codeberg.org/turbo-editors/turbo-core v0.2.0 |
| 11 | ``` |
| 12 | |
| 13 | Cette version vient du proxy de modules, pas du dossier voisin. Une modification faite dans `../turbo-core` est invisible aux éditeurs tant qu'elle n'est pas taguée **et** publiée — soit exactement le mauvais ordre : il faudrait publier pour savoir si le changement marche. |
| 14 | |
| 15 | ## Utiliser un espace de travail |
| 16 | |
| 17 | Depuis le dossier de l'éditeur : |
| 18 | |
| 19 | ```bash |
| 20 | cd turbo-go |
| 21 | go work init . ../turbo-core |
| 22 | ``` |
| 23 | |
| 24 | C'est tout. Compilez, testez et lancez comme d'habitude : |
| 25 | |
| 26 | ```bash |
| 27 | make test |
| 28 | make build |
| 29 | ./bin/turbo-go |
| 30 | ``` |
| 31 | |
| 32 | Chaque import de `codeberg.org/turbo-editors/turbo-core/...` pointe désormais sur votre copie de travail. Ni `go.mod` ni `go.sum` n'ont changé, et c'est tout l'intérêt : il n'y a aucune modification à défaire, donc rien à oublier avant de commiter. |
| 33 | |
| 34 | ### Vérifier que c'est bien pris en compte |
| 35 | |
| 36 | ```bash |
| 37 | go list -f '{{.Dir}}' codeberg.org/turbo-editors/turbo-core/app |
| 38 | ``` |
| 39 | |
| 40 | | Réponse | Signification | |
| 41 | | --- | --- | |
| 42 | | `…/turbo-editors/turbo-core/app` | L'espace de travail est actif ; vous testez vos modifications | |
| 43 | | `…/pkg/mod/codeberg.org/…@v0.2.0/app` | Il ne l'est pas ; vous testez la bibliothèque publiée | |
| 44 | |
| 45 | C'est la seconde réponse qui coûte un après-midi, parce que tout compile et tout passe quand même. |
| 46 | |
| 47 | ### Arrêter de l'utiliser |
| 48 | |
| 49 | ```bash |
| 50 | rm go.work go.work.sum |
| 51 | ``` |
| 52 | |
| 53 | `go.work` est ignoré par git dans chacun de ces dépôts : il ne peut donc pas être commité par accident. C'est le câblage local d'une personne ; commité, il casserait chaque clone qui n'a pas de `../turbo-core` à côté. |
| 54 | |
| 55 | ## Travailler sur tous les éditeurs à la fois |
| 56 | |
| 57 | Un espace de travail peut contenir la bibliothèque et tous les éditeurs bâtis dessus : |
| 58 | |
| 59 | ```bash |
| 60 | cd turbo-editors |
| 61 | go work init ./turbo-core ./turbo-go ./turbo-rust ./turbo-python ./turbo-moonbit ./turbo-golo ./turbo-js |
| 62 | ``` |
| 63 | |
| 64 | Placez ce `go.work` dans le dossier **parent** et toute commande `go` lancée en dessous — dans n'importe lequel des six — utilise le turbo-core local. C'est la forme à employer quand un changement de bibliothèque touche plus d'un éditeur, c'est-à-dire la plupart du temps. |
| 65 | |
| 66 | **Listez tous les modules que l'espace de travail couvre, y compris ceux qui sont imbriqués.** Un espace de travail revendique toute l'arborescence de chaque module qu'il liste : un second `go.mod` sous l'un d'eux — un projet de démonstration, un bac à sable — cesse d'être un module, et toute commande `go` lancée dedans échoue sur *directory prefix . does not contain modules listed in go.work*. Ajoutez-le au bloc `use` et cela remarche. Une entrée `use` pointant vers un dossier **sans** `go.mod` fait au contraire échouer tout le chargement, en nommant ce dossier plutôt que celui où vous travailliez. |
| 67 | |
| 68 | ## L'ancienne méthode : une directive replace |
| 69 | |
| 70 | Le `go.mod` de chaque éditeur se termine par la même ligne, en commentaire : |
| 71 | |
| 72 | ``` |
| 73 | // replace codeberg.org/turbo-editors/turbo-core => ../turbo-core |
| 74 | ``` |
| 75 | |
| 76 | La décommenter fait le même travail. Elle est conservée parce que c'est la forme que la documentation Go propose en premier et celle que vous croiserez dans d'anciennes notes, mais préférez l'espace de travail, pour une raison : **un `replace` est une modification d'un fichier suivi par git, et peut être commité par accident.** Un `replace` commité casse un clone propre sur toute machine sans cette copie, et `01-release.tag.sh` refuse de taguer une release dont le `go.mod` en contient un — ce garde-fou est là parce que l'erreur est assez fréquente pour mériter une vérification. |
| 77 | |
| 78 | Si vous l'employez malgré tout, remettez la ligne `require` sur une version publiée et supprimez le `replace` avant de commiter. |
| 79 | |
| 80 | ## Tester la forme publiée, pas seulement le code |
| 81 | |
| 📦 Turbo Core d662ceb k33g 12h ago | 82 | Un espace de travail prouve que votre code fonctionne. Il ne prouve pas que le *module* fonctionne : il ne dit rien de ce que contient le tag, de la justesse du `go.sum`, ni de la capacité d'un clone propre à compiler. |
| 83 | |
| 84 | À cette dernière question, vous pouvez répondre sans rien publier — `./02-build-releases.sh v0.3.0` archive la source suivie par git, l'extrait ailleurs et l'y compile. Le reste demande un vrai tag : |
| 🛟 Updated. 28d5985 k33g 20h ago | 85 | |
| 86 | ```bash |
| 📦 Turbo Core d662ceb k33g 12h ago | 87 | ./01-release.tag.sh |
| 🛟 Updated. 28d5985 k33g 20h ago | 88 | ``` |
| 89 | |
| 📦 Turbo Core d662ceb k33g 12h ago | 90 | La page de release suit toute seule : le push du tag déclenche le workflow Release, qui met en scène les mêmes artefacts et les publie. Voir [Publier la bibliothèque](release-the-library.md). |
| 91 | |
| 🛟 Updated. 28d5985 k33g 20h ago | 92 | Puis, dans chaque éditeur, **sans** espace de travail et **sans** replace : |
| 93 | |
| 94 | ```bash |
| 95 | rm -f go.work go.work.sum |
| 96 | go get codeberg.org/turbo-editors/turbo-core@v0.3.0 |
| 97 | go mod tidy |
| 98 | make check |
| 99 | ``` |
| 100 | |
| 101 | Un tag publié ne se déplace pas — les consommateurs l'épinglent et le proxy le met en cache — alors faites cela après que l'espace de travail vous a convaincu, jamais à la place. |
| 102 | |
| 103 | ## Voir aussi |
| 104 | |
| 105 | - Faire la release elle-même : [Comment publier la bibliothèque](release-the-library.md) |
| 106 | - Lancer la suite de tests : [Comment lancer les tests](run-the-tests.md) |