Parlons de Gladys V4


#102

Hop PR poussée =>


#103

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 :slight_smile:

J’ai poussé ça sur le repo playground


#104

Salut à tous!

Bon j’ai pas chômé aujourd’hui, j’ai créé tout le projet “backend” :smiley: 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!


#105

Je viens de configurer les tests + le coverage sur TravisCI :


#106

Déjà ça commence mal ^^

Cela dit je trouve pas que ça soit brouillon perso :thinking:


#107

Ok je fix :stuck_out_tongue:

Je vais utiliser ce package pour faire du cross-platform la dessus:


#108

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 :stuck_out_tongue:


#109

Non, c’est bien pour ça qu’il y a un module qui gère différentes plateformes :slight_smile:

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


#110

Effectivement c’est beaucoup mieux d’un coup ^^


#111

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


#112

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 ?


#113

J’ai lu votre échange, 2 fois même, mais toujours rien compris ! Comme quoi, c’est un vrai métier :wink:


#114

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?


#115

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 :thinking:

Je dois rater un truc… c’est bien la première fois qu’il me fais ça…


#116

Ah c’est sûr ça doit être ça! Enquête sur ta conf de VScode…


#117

Non mais c’est bon j’ai trouvé, merci windows :stuck_out_tongue:

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 :triumph:


#118

Salut à tous!

Je viens de finir une première version de la modélisation de base de donnée :slight_smile:

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! :stuck_out_tongue: ç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) :slight_smile:


#119

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.


#120

@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 :wink:


#121

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 :stuck_out_tongue:

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 :stuck_out_tongue:

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 :confused:

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 :sweat_smile: