Développeurs front, est-ce que ces pratiques sont considérées comme bonnes ?

Bonjour, amis développeurs front.

Au fur et à mesure de mes pérégrinations sur de développement JS et Sass, je découvre tout un tas de pratiques qui ont l’air assez répandues mais qui m’étonnent, moi venant du monde Java. Et je n’arrive pas à savoir si se sont de vraies bonnes pratiques avec une justification derrière – justification que je ne comprends pas et que j’aimerais bien avoir – ou juste un effet de mode bizarre, une mauvaise pratique hélas commune (comme on a les abus de factory et de noms à rallonge en Java).

1. Tout découper en modules indépendants (qu’ils aient leur propre dépôt ou non), y compris ce qui n’est pas réutilisable dans un autre projet. Ça donne souvent des modules où il y a 10x plus de boilerplate code¹ que de code utile.
2. Les modules créés de la façon suivante : nomModule/index.[js|vue|sass]. La nomenclature nomModule.[js|vue|sass] fonctionne parfaitement, pourquoi se retrouver avec un projet dont 80 % des fichiers s’appellent index ?
3. La configuration par import. Le projet utilise le package X qui propose plusieurs élément E1, E2, E3… pour savoir quel module est utilisé, il ne faut pas chercher un fichier de configuration ni un paramétrage à l’initialisation, mais quel élément est importé dans les directives d’import.
4. Le fichier d’import/export : j’ai un module renard qui contient des sous-modules renard/fennec, renard/roux, etc (qui chacun ne contiennent qu’un fichier index.[js|sass], cf plus haut). À la racine du module principal, j’ai un fichier index.[js|sass] qui se contente d’importer tout le reste et, dans le cas du JS, de les exporter.
5. (ajout) Le développement en marche forcée. J’ai des outils dont la version N est officiellement dépréciée alors que la version N+1 n’est pas encore officiellement stable (elle dans les -RC, mais chaque RC a plusieurs dizaines de commits).
6. (ajout) J’ai d’ailleurs l’impression que beaucoup de libs sont très utilisées malgré le fait qu’elles ne passent jamais officiellement en version stable. Je ne sais pas si c’est un problème de numérotation ou d’utilisation précoce massive ?

Je rajouterai probablement d’autres étonnements dans le futur…

Pour le premier, je dirais qu’il y a du bon et du mauvais :

• Tout est compartimenté, du coup moins de risque d’interférences
• Si besoin de réutiliser c’est déjà prêt à être transposé
• Ça devient effectivement plus lourd
• Pas sûr que ça soit vraiment réutilisé et au pire un copier-coller fait généralement le job

Le nommage index.js est je pense hérité du PHP et autres réglages Apache par défaut, du coup c’est le fichier qu’on va chercher en premier car la logique est connue.

Mais si ton composant s’appelle autrement rien ne t’empêche de le nommer autrement (la clé main du package.json permet d’ailleurs de l’indiquer).

Sur les troisième et quatrième points je suis pas sûr de comprendre à quoi tu fais référence ni ce qui t’étonne exactement

Ajout des questions 5 et 6.

OK pour le point 1.

Pour le point 2 je comprends bien d’où ça vient, mais une logique historique n’a jamais fait une « bonne » pratique, ça fait juste une « pratique ». En l’occurrence, je parle du cas ou tu n’as rien à changer dans le package.json. Mes modules (internes au projet, dans des sous-dossiers) sont importés en faisant import Bidule from nomModule, que le fichier soit nomModule/index.js ou nomModule.js.

Pour les points 3 et 4, ben… exactement ce qui est décrit. Je ne sais pas le décrire mieux, en fait. C’est des façons de faire que je trouve complètement louches.

Pour le 2, je sais pas trop si c’est bon ou mal. Disons que ça formalise, ça évite d’être perdu. 🤷‍♂️

Pour le 5 je pense que tu tombes sur des développeur zélés qui veulent pousser à utiliser la toute dernière version coûte que coûte pour leur éviter de maintenir les anciennes.

Pour le 6 c’est — je pense — un mélange de ça et de crainte de la part des développeurs de passer en version stable car c’est prendre le risque d’être (officiellement) responsable en cas de problème. Quand on voit que les versions 0.x de Node.js lui-même ont été utilisées en prod un moment alors que déclarées pas stables…