-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Étudier et Benchmark les outils de génération de documentation #17
Comments
Je lis facebook/docusaurus#6113 |
Exemple de sites qui utilisent Docusaurus : https://docusaurus.io/showcase |
Je souhaite dans un premier temps tester les plugins de moteur de recherche local suivants (je ne souhaite pas utiliser Algolia) : |
Je fais mes tests Docusaurus dans le repository suivant : https://github.com/stephane-klein/docusaurus-playground |
Dans ce commit, j'ai réussi à setup docusaurus-lunr-search avec succès. À noter que :
ne fonctionne pas, j'ai dû passer par
|
Je souhaite tester si je peux placer un dossier de
|
Cela a fonctionné, exemple : |
Je souhaite tester la fonctionnalité i18n de Docusaurus. |
Je n'ai pas trouvé dans J'ai trouvé cette issue : |
Je trouve ce point très pénible dans Docusaurus 🙁 |
J'aime bien l'organisation des fichiers pour le support i18n de Nextra : https://nextra.vercel.app/features/i18n Autre intérêt de Nextra : le support SSG qui permet par exemple d'afficher des données dynamiques qui viennent par exemple d'une base de données. |
On m'a répondu : |
En regardant le code source du thème de Nextra : https://github.com/shuding/nextra/tree/core/packages j'ai l'impression que cet outil est plus "minimaliste" et plus facile à customiser que par exemple Docusaurus. |
J'ai créé un playground pour Nextra : https://github.com/stephane-klein/nextra-playground |
Je viens de voir que https://github.com/svelteness/kit-docs n'est pas basé sur |
Quelqu'un se pose la même question que moi : |
@stephane-klein Pour info, une version 2.0 de nextra est sortie il y a quelques jours https://github.com/shuding/nextra/releases/tag/nextra%402.0.0 |
@abordin-spacefill merci 👍, très intéressant. La gestion i18n de Nextra correspond à ce que je cherche : https://nextra.site/docs/guide/i18n#use-add-locale-to-filenames |
@abordin-spacefill Je viens de voir que j'avais noté ceci :
Je ne me souviens plus pourquoi j'avais arrêté de travailler sur https://github.com/stephane-klein/nextra-playground |
@abordin-spacefill je pense que c'était à cause de difficulté en mode mono repos, voire cette branche https://github.com/stephane-klein/nextra-playground/commits/monorepo |
Un autre moteur de recherche static https://github.com/nextapps-de/flexsearch |
La section benchmark de ce repos liste de nombreux moteur de recherches static. |
Je suis en train de créer un spike privé basé sur Docusaurus, pour le moment, ce que je trouve pénible :
|
Sphinx est peut-être le premier générateur de documentation que j'ai utilisé vers 2008.
Sphinx était (et est toujours) très bien : complet, moteur de recherche, stable, énormément d'utilisateurs dans la communauté Python...
Vers 2010, le choix était simple, il n'y avait pas de questions à se poser, étant donné que Sphinx était presque le seul et dominait totalement le "marché".
Depuis la progression spectaculaire de l'écosystème JavaScript, la donne a changé : il existe un large choix et générateurs de documentation. Le choix n'est plus simple.
Je pense que Sphinx est toujours un choix pertinent, mais Sphinx est écrit en Python et Python n'a pas la cote chez les développeurs JavaScript.
D'autre part, les générateurs de documentation, basés sur un moteur JS, permettent pour la plupart d'intégrer des Components riches (ReactJS) dans les pages, ce qui peut-être dans certaines situations très pratiques.
Concernant le dialecte
Markdown
,AsciiDoc
,ReStructuredText
, je pense que je préfère être conservateur, c'est à dire utiliser du Markdown afin que la source des pages soit correctement rendu dans GitHub ou GitLab.Dans mes critères de comparaison, je souhaite étudier :
i18n
du type suivant :Je ne souhaite plus essayer de configurer le générateur de doc sur la structure de fichiers des README.md d'un monorepo.
J'ai perdu trop de temps à faire cela, aucun outil ne le supporte et les hacks que j'ai essayé de mettre en place ont engendré trop de difficultés, problèmes...
Par conséquent, la documentation doit rester une documentation, qui suit une narrative, et à côté de cela, des fichiers
README.md
continuent à exister dans les dossiers des services, outils, environnement... qui fournissent de la documentation contextuelle.Todo :
Tableau de comparaison : https://docs.google.com/spreadsheets/d/1xZlg0nabIUTH54xzsJ62D5hpc-plDUA8SDkJWp1bFDE/edit?usp=sharing
Mon cahier des charges
Playground repositories
The text was updated successfully, but these errors were encountered: