Comment tester une modification de turbo-core sans la publier

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106

# Comment tester une modification de turbo-core sans la publier

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.

## Le problème

Les éditeurs dépendent de turbo-core comme n'importe qui d'autre : par chemin de module et par version.

```
require codeberg.org/turbo-editors/turbo-core v0.2.0
```

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.

## Utiliser un espace de travail

Depuis le dossier de l'éditeur :

```bash
cd turbo-go
go work init . ../turbo-core
```

C'est tout. Compilez, testez et lancez comme d'habitude :

```bash
make test
make build
./bin/turbo-go
```

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.

### Vérifier que c'est bien pris en compte

```bash
go list -f '{{.Dir}}' codeberg.org/turbo-editors/turbo-core/app
```

| Réponse | Signification |
| --- | --- |
| `…/turbo-editors/turbo-core/app` | L'espace de travail est actif ; vous testez vos modifications |
| `…/pkg/mod/codeberg.org/…@v0.2.0/app` | Il ne l'est pas ; vous testez la bibliothèque publiée |

C'est la seconde réponse qui coûte un après-midi, parce que tout compile et tout passe quand même.

### Arrêter de l'utiliser

```bash
rm go.work go.work.sum
```

`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é.

## Travailler sur tous les éditeurs à la fois

Un espace de travail peut contenir la bibliothèque et tous les éditeurs bâtis dessus :

```bash
cd turbo-editors
go work init ./turbo-core ./turbo-go ./turbo-rust ./turbo-python ./turbo-moonbit ./turbo-golo ./turbo-js
```

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.

**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.

## L'ancienne méthode : une directive replace

Le `go.mod` de chaque éditeur se termine par la même ligne, en commentaire :

```
// replace codeberg.org/turbo-editors/turbo-core => ../turbo-core
```

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.

Si vous l'employez malgré tout, remettez la ligne `require` sur une version publiée et supprimez le `replace` avant de commiter.

## Tester la forme publiée, pas seulement le code

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.

À 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 :

```bash
./01-release.tag.sh
```

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).

Puis, dans chaque éditeur, **sans** espace de travail et **sans** replace :

```bash
rm -f go.work go.work.sum
go get codeberg.org/turbo-editors/turbo-core@v0.3.0
go mod tidy
make check
```

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.

## Voir aussi

- Faire la release elle-même : [Comment publier la bibliothèque](release-the-library.md)
- Lancer la suite de tests : [Comment lancer les tests](run-the-tests.md)