living-documentation 7.18.0 → 7.19.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/src/frontend/index.html +20 -0
- package/dist/starting-doc/.living-doc.json +5 -1
- package/dist/starting-doc/1_tutorial/2026_04_11_13_25_[General]_crer_vos_dossiers.md +4 -4
- package/dist/starting-doc/1_tutorial/2026_04_11_18_58_[General]_creer_un_document_dans_un_dossier.md +2 -3
- package/dist/starting-doc/3_concept/2026_04_08_20_58_[DOCUMENTING]_ADRS.md +2 -2
- package/dist/starting-doc/4_reference/2026_04_11_17_31_[FUNDAMENTALS]_architecturer_une_documentation.md +1 -1
- package/package.json +1 -1
|
@@ -227,6 +227,26 @@
|
|
|
227
227
|
color: #9ca3af;
|
|
228
228
|
}
|
|
229
229
|
|
|
230
|
+
/* Image margins — inline images (in lists, after <br>, mixed with text)
|
|
231
|
+
collapse to zero vertical margin; only images that sit alone in their
|
|
232
|
+
own paragraph keep a visual breathing room. */
|
|
233
|
+
.prose img {
|
|
234
|
+
margin-top: 0;
|
|
235
|
+
margin-bottom: 0;
|
|
236
|
+
}
|
|
237
|
+
.prose p > img:only-child,
|
|
238
|
+
.prose p > a:only-child > img {
|
|
239
|
+
margin-top: 1em;
|
|
240
|
+
margin-bottom: 1em;
|
|
241
|
+
}
|
|
242
|
+
|
|
243
|
+
/* Horizontal rules — tame Tailwind Typography's 3em default + bump contrast */
|
|
244
|
+
.prose hr {
|
|
245
|
+
margin-top: 2em;
|
|
246
|
+
margin-bottom: 2em;
|
|
247
|
+
border-color: #d1d5db;
|
|
248
|
+
}
|
|
249
|
+
|
|
230
250
|
/* File attachment pills — links pointing to /files/ */
|
|
231
251
|
.prose a.ld-file-attachment,
|
|
232
252
|
a.ld-file-attachment {
|
|
@@ -1,16 +1,16 @@
|
|
|
1
1
|
## Introduction
|
|
2
2
|
|
|
3
|
-
Les dossiers constituent l'architecture de votre documentation
|
|
4
|
-
Cette architecture doit répondre à une question simple : **où cherchera-t-on cette information dans six mois
|
|
3
|
+
Les dossiers constituent l'architecture de votre documentation.
|
|
4
|
+
Cette architecture doit répondre à une question simple : **où cherchera-t-on cette information dans six mois ?**
|
|
5
5
|
Pour en savoir plus sur les façons d'architecturer votre documentation, [suivez ce lien](?doc=4_reference%252F2026_04_11_17_31_%255BFUNDAMENTALS%255D_architecturer_une_documentation)
|
|
6
6
|
|
|
7
7
|
## Passons à la pratique
|
|
8
8
|
|
|
9
|
-
1. Dans un nouveau projet, vous pouvez créer des dossiers avec le bouton correspondant en haut, dans le Menu latéral de gauche
|
|
9
|
+
1. Dans un nouveau projet, vous pouvez créer des dossiers avec le bouton correspondant en haut, dans le Menu latéral de gauche.
|
|
10
10
|
`Shift+CLIC pour agrandir l'image`
|
|
11
11
|
|
|
12
12
|
[](/diagram?id=d1775917727566)
|
|
13
13
|
|
|
14
|
-
2. Créer un second dossier **2_GUIDE** puis **3_CONCEPT** et enfin **4_REFERENCE
|
|
14
|
+
2. Créer un second dossier **2_GUIDE** puis **3_CONCEPT** et enfin **4_REFERENCE**
|
|
15
15
|
💡 Vos dossier apparaissent ordonnée car ils utilisent un **préfix** "1_", "2_", "3_", ..., mais ce dernier est invisible en affichage
|
|
16
16
|
💚
|
package/dist/starting-doc/1_tutorial/2026_04_11_18_58_[General]_creer_un_document_dans_un_dossier.md
CHANGED
|
@@ -2,8 +2,7 @@
|
|
|
2
2
|
[](/diagram?id=d1776024969304)
|
|
3
3
|
|
|
4
4
|
2. Créer un document dans un dossier contenant déjà un document
|
|
5
|
-
|
|
6
|
-
Vous constaterez que les champs `Category`et `Location` sont **préremplis**, vous pouvez ainsi facilement et rapidement ajouter un ensemble de documents dans un dossier et/ou une catégorie donnés
|
|
5
|
+
Pour cela sélectionnez d'abord **un document existant dans le Menu latéral de gauche** puis cliquez sur le bouton en haut.
|
|
6
|
+
Vous constaterez que les champs `Category`et `Location` sont **préremplis**, vous pouvez ainsi facilement et rapidement ajouter un ensemble de documents dans un dossier et/ou une catégorie donnés.
|
|
7
7
|
Pour en savoir plus sur les notions de **dossiers** et de **catégories**, [suivez ce lien](?doc=4_reference%252F2026_04_12_14_07_%255BFUNDAMENTALS%255D_dossiers_et_catgories)
|
|
8
|
-
|
|
9
8
|
[](/diagram?id=d1775937972731)
|
|
@@ -1,12 +1,12 @@
|
|
|
1
1
|
|
|
2
2
|
## Les ADR : une bonne idée, des limites réelles
|
|
3
3
|
|
|
4
|
-
Les **Architecture Decision Records**, ces petits documents Markdown versionnés dans le dépôt, au plus près du code, sont une des meilleures pratiques que j'aie adoptées dans ma longue carrière de développeur et elle le reste encore aujourd'hui
|
|
4
|
+
Les **Architecture Decision Records**, ces petits documents Markdown versionnés dans le dépôt, au plus près du code, sont une des meilleures pratiques que j'aie adoptées dans ma longue carrière de développeur et elle le reste encore aujourd'hui.
|
|
5
5
|
Pas besoin d'outil externe, pas de synchronisation à gérer, l'historique des décisions **vit** avec le code.
|
|
6
6
|
|
|
7
7
|
Mais certains problèmes subsistent :
|
|
8
8
|
|
|
9
|
-
- Les **diagrammes** : l'ADR affiche un beau PNG généré depuis un outil visuel (parce que mermaid ca va un moment !!)
|
|
9
|
+
- Les **diagrammes** : l'ADR affiche un beau PNG généré depuis un outil visuel (parce que mermaid ca va un moment !!)
|
|
10
10
|
Mais le fichier source du diagramme a disparu depuis longtemps ➔ Le PNG ne sera jamais mis à jour ➔ Documentation obsolete ➔ C'est dommage car moi perso je suis un visuel
|
|
11
11
|
- L'**ordre** des ADRs : laborieux à maintenir, des dossiers, des sous-dossiers, des conventions *superseded / not superseded*, tout ca tiens mal dans la durée.
|
|
12
12
|
- Les **markdowns** : C'est bien mais les outils pour les visualiser sont plutôt limités et pas très pratiques.
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
Il existe plusieurs approches pour organiser une documentation : par équipe, par produit, par date, par type de contenu…, chacune ayant ses avantages.
|
|
2
2
|
[](/diagram?id=d1775924007206)
|
|
3
3
|
|
|
4
|
-
Personnellement j'utilise l'approche `Dàtaxis` que je trouve excellente pour structurer de documentations
|
|
4
|
+
Personnellement j'utilise l'approche `Dàtaxis` que je trouve excellente pour structurer de documentations.
|
|
5
5
|
Et je trouve que cela donne d'excellents résultats que ce soit chez mes clients, ou sur mes projets open source personnels.
|
|
6
6
|
|
|
7
7
|
`Diataxis` distingue quatre types de contenus, chacun dans son dossier :
|