[TECH] Mettre les fichiers css et test au même endroit que les fichiers de composants (PIX-13307)

[mcampourcy]

🦄 Problème

Les fichiers .css sont dans un dossier styles, les fichiers de test dans un dossier tests et les composants dans un dossier components. Retrouver le style et les tests d'un composant précis est laborieux.

🤖 Proposition

Réunir tous ces fichiers au même endroit.

🌈 Remarques

Il y a plusieurs façons de faire, j'ai essayé de toutes les présenter.

Contexte :

• La page d'affichage de détails d'une session
• components/sessions
• La page index.gjs correspondant au composant "parent", celui qui contient toute la logique.
• Il importe les autres composants, qui sont des composants présentationnels, qui ne contiennent aucune logique. Ces composants pourraient, dans l'absolu, être réutilisé n'importe où ailleurs.

Pour ranger tous ces fichiers, on peut :

• mettre tous les fichiers à la racine

• mettre les fichiers enfants dans des dossiers nommés, et là, deux possibilités :
• • nos fichiers gardent un nom explicite et on met un index à la racine de chaque dossier
• • nos fichiers s'appellent tous index

💯 Pour tester

On vérifie que l'affichage est OK et que tous les tests passent

[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)
• Junior
• Admin
• API
• Audit Logger

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

• scalingo front
• scalingo api
• scalingo audit-logger

[dlahaye]

En faisant ainsi, est-ce que les fichiers de tests sont buildés avec le reste ?

[mcampourcy]

@dlahaye Normalement, oui ! Le fichier testem prend déjà comme fichiers src_files: ['*.js', '*.gjs'], autant dire tout, peut importe où c'est rangé

[AndreiaPena]

Le build du front échoue

[build:certif ] Build Error (PackagerRunner) in components/sessions/index_integ_test.js
[build:certif ] 
[build:certif ] Module not found: Error: Can't resolve './tests/helpers/setup-intl-rendering'

[dlahaye]

@dlahaye Normalement, oui ! Le fichier testem prend déjà comme fichiers src_files: ['*.js', '*.gjs'], autant dire tout, peut importe où c'est rangé

Donc ça veut dire qu'on envoi en prod des build assez conséquents, c'est pas gênant ?

[mcampourcy]

@dlahaye Normalement, oui ! Le fichier testem prend déjà comme fichiers src_files: ['*.js', '*.gjs'], autant dire tout, peut importe où c'est rangé

Donc ça veut dire qu'on envoi en prod des build assez conséquents, c'est pas gênant ?

Pas plus que d'habitude ? ça dépasse mes compétences, j'avoue

[frinyvonnick]

@dlahaye Normalement, oui ! Le fichier testem prend déjà comme fichiers src_files: ['*.js', '*.gjs'], autant dire tout, peut importe où c'est rangé

Donc ça veut dire qu'on envoi en prod des build assez conséquents, c'est pas gênant ?

Pas plus que d'habitude ? ça dépasse mes compétences, j'avoue

@dimitrilahaye concrètement cette PR change rien à la configuration actuelle. Il faudrait vérifier si effectivement on embarque les tests dans le build de prod (mais ça n'a rien à voir avec cette PR 😄). On peut changer la configuration de testem pour cibler les fichiers *_test.js ou *_test.gjs.

[frinyvonnick]

Je vois dans le screenshot des TUs sur des composants. J'en profite pour dire que pour faire nos TUs de composants utilise une API interne (cf : @glimmer/component/-private/ember-component-manager c'est littéralement écrit dans le path 😂) de Glimmer. On s'expose donc à des breaking changes non maitrisés (on ne nous avertira pas via une version majeure ça peut arriver même avec une patch). Il n'est pas recommandé de faire des TUs de composants il vaut mieux faire des tests d'intégration. Appelé Rendering tests dans le documentation 😄