[FEATURE] Créé des scripts pour générer des élements Modulix (PIX-11270)

[yannbertrand]

🦄 Problème

La contribution aux Modulix est un peu limitée pour le moment :

• il faut générer des UUID très régulièrement,
• on ne peut pas retenir le format de chaque élément
  • du coup les éléments sont copiés-collés puis modifiés avec des oublis possibles...
• JSON n'aide pas à la contribution pour des personnes moins techniques.

🤖 Proposition

Donner accès à des scripts dans l'API pour générer des éléments :

# Générer un élément "texte"
node ./api/scripts/modulix/get-sample-text-element.js

# Générer un élément "image"
node ./api/scripts/modulix/get-sample-image-element.js

# Générer un élément "vidéo"
node ./api/scripts/modulix/get-sample-video-element.js

# Générer un élément "QCU"
node ./api/scripts/modulix/get-sample-qcu-element.js

# Générer un élément "QROCM"
node ./api/scripts/modulix/get-sample-qrocm-element.js

# Générer un élément "QCM"
node ./api/scripts/modulix/get-sample-qcm-element.js

Chacun de ces scripts renvoie l'élément demandé au format à jour avec un nouvel UUID ✨ .

Il est aussi possible de copier directement en ajoutant | pbcopy (sur Mac). Une ligne complète donne donc :

node ./api/scripts/modulix/get-sample-qcm-element.js | pbcopy

🌈 Remarques

J'avais prévu initialement de permettre l'usage de script directement en bash grâce à l'usage du shebang mais notre linter nous en empêche. À voir une fois que nous seront passé dans la version 17 de n si l'option ignoreUnpublished nous permet de mettre ça en place.

💯 Pour tester

Récupérer la branche en local et vérifier que chaque script génère bien le bon type d'élément !

[pix-bot-github]

Une fois les applications déployées, elles seront accessibles via les liens suivants :

• App (.fr)
• App (.org)
• Orga (.fr)
• Orga (.org)
• Certif (.fr)
• Certif (.org)
• 1D
• Admin
• API
• Audit Logger

Les variables d'environnement seront accessibles via les liens suivants :

• scalingo front
• scalingo api
• scalingo audit-logger

[VincentHardouin]

Est-ce que ce commit est nécessaire ? 🤔

[yannbertrand]

Je trouvais intéressant car à la base je trouvais l'UX meilleure mais le linter m'a embêté. Quand on aura monté de version de "n" on aura peut-être moyen de faire mieux en revertant ce commit.

[VincentHardouin]

En regardant de plus près avec @mariannebost et @mirawlin, nous voyons pas vraiment l'intérêt de nommer l'erreur :
Voici les erreurs pour chaque expect :

expect(result.error).to.equal(undefined, result.error?.details.map((error) => error.message).join('. '));
  // AssertionError: "alt" is required: expected ValidationError: "alt" is required { …(2) } to equal undefined

expect(result.error).to.equal(undefined);
    // AssertionError: expected ValidationError: "alt" is required { …(2) } to equal undefined

expect(result.error).to.be.undefined;
    // AssertionError: expected ValidationError: "alt" is required { …(2) } to be undefined

Comme cela complexifie vachement la lecture des expects : il faut savoir que le deuxième paramètre est un override de l'erreur, et que result.error?.details.map((error) => error.message).join('. ') a pour but d'afficher toutes les erreurs du schéma. Nous proposons plutôt de rester simple avec :

Suggested change

	expect(result.error).to.equal(undefined, result.error?.details.map((error) => error.message).join('. '));
	expect(result.error).to.be.undefined;

[yannbertrand]

Pour info c'est un copié collé de ce qui est fait côté module-datasource_test.

Chaud pour voir ensemble comment faire mieux !