Hop PR poussée =>
Parlons de Gladys V4
J’ai commencé à faire un repo “playground” pour Gladys 4, qui sera probablement vers le repo de développement jusqu’au merge sur le repo principal.
J’ai fais le boulot chiant ce matin, à savoir faire une configuration ESlint hyper solide et strict.
Pour être sur que ce soit super strict mais réaliste, j’ai essayé de faire ça sur la configuration du Gladys Gateway. J’ai étendu la configuration Airbnb basic + en ajoutant mes règles à moi.
Sur le Gateway, ça a trouvé 2 500 erreurs (alors que j’avais déjà une configuration plutôt strict), je suis plutôt content du résultat
J’ai poussé ça sur le repo playground
Salut à tous!
Bon j’ai pas chômé aujourd’hui, j’ai créé tout le projet “backend” C’est un premier POC, rien de final. L’objectif c’est de voir est-ce que la structure des dossiers/du code nous plait. Le coding style aussi.
Tout est dispo ici =>
J’ai activé ESlint en mode hyper strict comme je disais plus haut.
J’ai activé APIDoc + JSDoc + un plugin ESlint qui valide les commentaires et refuse le code sans commentaires, et qui vérifie que le code et les commentaires sont synchro (et ça c’est magique!)
Démonstration:
Dites moi ce que vous en pensez.
Je suis pas encore fan de tout je vous avoue, j’ai l’impression que le projet fait un peu “brouillon” pour l’instant…
ça doit être compréhensible pour n’importe qui qui arrive sur le projet!
J’ai fixé le truc juste en mettant ‘SET’ devant le NODE_ENV ^^
Mais je sais pas si après ça va fonctionné sur les autres plateformes
Edit: rajoute un script de start et npm i aussi au package root ça serais pratique
Non, c’est bien pour ça qu’il y a un module qui gère différentes plateformes
J’ai pushé, ça devrait fixer chez toi!
Btw, quand c’est devDependencies c’est pas trop grave d’installer des petites dépendances pour ce genre de chose, faudra juste s’assurer que ces dépendances ne soient pas dans le build de prod sinon ça va vite être lourd
Je sais pas, je me tâte à mettre le dossier “controllers” et “middlewares” dans un dossier “api”… Après enfouir dans des sous dossiers c’est pas toujours la meilleure idée…
Yes! Après je configurerais le package root quand il y a aura le front.
Il faut que tout soit transparent pour le dev et l’utilisateur.
En dev ça lancera le serveur hot reload du front et du back
En prod ça lancera juste le server qui exposera la SPA buildée
Oui effectivement c’est pas forcément la meilleur idée, c’est comme ça qu’on se perd vite dans les montagnes de sous dossier ^^
Petite question, tu as passé le test eslint avec succès je suppose ?
J’ai lu votre échange, 2 fois même, mais toujours rien compris ! Comme quoi, c’est un vrai métier
Oui pourquoi ça marche pas chez toi?
ça passe pourtant en local + sur Travis!
Tiens du coup ton avis sur le repo peut être intéressant! Pour toi ça fait clean?
Nope, je me prend 416 erreurs à la figure !
Mais je soupçonne VSCode de ne pas prendre la bonne config eslint… alors qu’il me semble qu’il prend automatiquement la config du projet
Je dois rater un truc… c’est bien la première fois qu’il me fais ça…
Non mais c’est bon j’ai trouvé, merci windows
C’est une histoire de saut de ligne, windows utilise le type CRLF par défaut alors que MAC et Linux seulement un LF, du coup comme les fichiers ont tous été créé sur MAC mon VsCode interprète mal les règles eslint et me sort des erreurs de saut de lignes partout
Salut à tous!
Je viens de finir une première version de la modélisation de base de donnée
Dites moi ce que vous en pensez, il y a peut-être des choses à changer/des oublis. Dites moi!
Je t’ai répondu à ta PR, c’est pas ce qu’on veut de désactiver la règle! ça va être le bordel sinon. Il faut que tu configures ton IDE pour qu’il gère le LF sans problème (c’est dans les paramètres de VSCode)
Autre nouveautés, j’ai défini la structure des package.json
des services internes dans Gladys 4.
Voilà un exemple:
{
"name": "gladys-example",
"main": "index.js",
"os": [
"darwin",
"linux",
"win32"
],
"cpu": [
"x64",
"arm",
"arm64"
],
"scripts": {},
"dependencies": {
"axios": "^0.18.0"
}
}
Le module doit désormais spécifier 2 attributs supplémentaires: “os” et “cpu”, afin d’indiquer les plateformes sur lequel marche le service.
Quand on fera un build de Gladys pour une plateforme, NPM fera les vérifications nécessaires si il est possible ou pas d’installer le service.
- Si oui, le service sera installé
- Si non, le service ne sera pas installé et sera désactivé avec un code d’erreur spécial (type “platform_not_compatible”), et donc non chargé au démarrage de Gladys
Ces règles:
- Avoir un package.json valide
- Avoir un attribut “os” et “cpu” dans le package.json
Sont vérifiés par une batterie de tests afin qu’on soit certain que tous les modules soient stricts à ce propos.
@MathieuA Bon j’ai changé un peut l’architecture et la façon d’instancier la librairie Gladys et les dépendances.
Les controllers ressemblent à ça:
Je trouve ça plus clair, et avoir tous les controllers d’une entités dans un même fichier je vois pas le problème, c’est tellement fin les controllers… Et je préfère faire de l’injection de dépendances plutôt que du require pour ici.
Ensuite, autre changement, la lib Gladys doit aussi être instanciée, afin qu’on puisse gérer les “states” plus facilement.
Je m’explique, avant j’avais l’habitude faire des fichiers “shared.js” pour stocker des états partagé entre plusieurs fichiers. ça faisait le boulot, mais bon c’est pas super, en gros je me servais de require() comme fournisseur de singleton ^^
Proposition: De la même manière que les modules, chaque service est une fonction qui renvoie des fonctions (en gros, c’est comme une classe qu’il faut instancier)
Donc pour lancer Gladys, on fait:
Je pense qu’on aura un lifecycle de l’app plus clair du coup et un management des états plus propre.
PS: j’ai mis “controllers” et “middleware” et “routes.js” dans un dossier “api”, je trouve ça plus clair
Si quelqu’un a des retours, je suis preneur
Ahah je me doutais que t’allais me repondre ça ! ^^
Sauf que ça va être le bordel si tu désactive pas cette règle plutôt
Parce que du coup j’ai cherché et on peut pas configurer VSCode pour qu’il prene en compte automatiquement le type saut de ligne. La seule configuration qu’on peut faire c’est de spécifier le saut de ligne quand on crée un nouveau fichier. Sauf que pour les fichier existant le seul moyen c’est de modifier manuellement mais ça entraîne de fauses modifs pour Git qu’il faudrait que je commit… mais c’est un peu con.
D’autant plus que je suis pas le seul a dev sur Windows donc il y aura forcément des conflits avec d’autres. Et quand eux ou moi vont te faire des PR pour des nouveaux fichiers avec des saut de ligne Windows ça va entraîné des erreurs certainement lors des tests auto ou même que quand ça sera chez toi !
Et honnêtement avec le peu de fichiers qu’il y a dans le projet j’ai déjà plus de 400 erreur lors du test chez moi donc quand le dev sera plus avancé j’abandonnerais l’idée de lancer le test
J’ai cherché si on pouvais faire quelque chose avec la conf eslint mais rien n’est prévu apparemment, c’est soit l’un soit l’autre
Donc je me suis dit que le mieux était de désactiver cette règle, c’est pas comme si je désactivais la verif des coms