//. 092 Monorepo ou pas ?

[@corentinperroux9530]

Super épisode ! Ça peut être intéressant de faire un workshop pour montrer comment le mettre en place via différentes solutions et expliquer plus en détails les cas de figure ! ✌🏻

[@doubleSlash_dev]

Oui, on va voir si on peut faire ça

[@pmothais]

Les derniers projets sur lesquels j'ai travaillé étaient en mono repo, mono language (TS) et le déploiement en un clic lors du merge sur la branche main est d'un plaisir incroyable 🙂

[@doubleSlash_dev]

turborepo ? ou autre chose ?

[@pmothais]

@@doubleSlash_dev Projets sous Astro qui sont built et deployed sur Netlify. Je ne vois pas encore l'intérêt de changer de tooling pour ces projets.

[@doubleSlash_dev]

@@pmothaisPas de solutions miracles, on est ok avec ca. Si le site internet doit hériter d'un design system, le type des champs pour le formulaire marketings .... autant de données partagées / centralisées Ça dépend aussi du scope du projet.

[@algomax-dev]

Très cool les monorepos ! Partager des schémas Zod, des types et des fonctions pour formatter les dates a été un gros avantage dans mon cas. Pouvoir typer les méthodes du backend (en s'inspirant du schéma Zod), et utiliser le schéma Zod côté front pour valider le formulaire me fait gagner beaucoup de temps. Et puis grâce à Typescript, quand le backend envoie une valeur en moins, le frontend en est informé directement avec une erreur TS. Si on ajoute une propriété par contre, on peut directement bénéficier de l'autocomplétion, sans avoir à changer ou écrire des types, car ils sont inférés depuis le backend ! Par contre je me demande si ce sera pas plus simple à l'avenir de migrer du monorepo vers une app Remix / NextJS fullstack (avec les server actions, et React Router 7, React 19 qui arrivent bientôt ...) Merci pour cet épisode !

[@doubleSlash_dev]

Merci pour ton retour d’expérience 👍

[@olriko]

Super épisode ! Monorepo c'est la vie ! Même pour des petits projets, le monorepo est devenu de plus en plus simple à mettre en place avec les outils que vous avez cités. Notamment avec Turborepo et leur doc super bien faite. C'est un bonheur de partager les types front/back. Un petit outil sympa à conseiller pour linter les dependences dans le packages.json en monorepo: syncpack

[@doubleSlash_dev]

Merci pour l’info et merci d’avoir écouté 🙏

[@frizouilleuh]

Je lui pose une question (j'ai écouté en fond donc ça a sûrement été dit) : mais sur un projet qui a un back et un front différents, c'est sûrement pratique pour avoir une seule issue ou on fait quand même des issues et branches différentes pour une unique facture qui touche aux deux projets ?

[@doubleSlash_dev]

Ça dépend la façon de travailler. Si même développeur front et back, tu peux faire sur la même. Sinon, deux branches. Après chacun fait comme il veut.

[@merkkur]

Merci pour le partage, épisode très intéressant👍 Je n'ai jamais eu l'occasion de bosser sur un monorepo même si ça aurait été bien plus bénéfique à mainte reprise 😅 ...Episode sur les variables d'environnement... 📝😁 PS: Le travail sur le montage est apprécié 👏

[@doubleSlash_dev]

Merci d'avoir notifié le travail sur le montage !!! 🙏 Pour un épisode ENV / Secret et tout le tooling derrière… c'est déjà dans les tuyaux

[@kalist8938]

Google en monorepo? J’en doute vu la demi douzaine de langage différent qu’ils utilisent … Le monorepo c’est facile quand ta stack utilise le même langage. Sinon ça devient vite le bordel entre les différentes stack du même repo, et donc on perd l’avantage du monorepo au final.

[@doubleSlash_dev]

Voici la source research.google/pubs/why-google-stores-billions-of-lines-of-code-in-a-single-repository/ Bonne lecture

[@julienleclercq6809]

aïe, google ont largement communiqué sur le fait qu'ils soient en monorepo et ont développé go juste pour ça. Tu peux dissiper tes doutes :D.

[@karlapple7275]

On peut dire merci a la T3 Stack

[@doubleSlash_dev]

create.t3.gg/

[@AZONSOUemeric]

Ça a plus d'avantage quand c'est un langage

[@doubleSlash_dev]

oui effectivement, c'est mieux avec le même language pour partager les dépendances mais pour le coté dev, c'est aussi intéressant de gérer un seul repository.