Si vous observez l'évolution de Symfony au cours du temps, vous vous demandez peut-être comment la core-team décide qu'un sujet donné ferait un bon composant ? Il y a déjà des librairies existantes pour presque tout, alors pourquoi en créer de nouvelles ? Comment Symfony s'inspire des autres projets et est-ce que ça arrive souvent ? Est-ce que le fait que les composants Symfony soient utilisés un peu partout leur apporte des fonctionnalités additionnelles ? Comment sont choisies les dépendances de Symfony ? Ou de façon plus générale : comment le projet Symfony interagit-il avec les autres frameworks et librairies ?
Lors de cette conférence, je vous propose d'étudier ces questions, pour vous permettre de comprendre les raisonnements sous-jacents. Ce sera l'occasion d'illustrer les fameux "package principles" et peut-être de vous donner matière à mieux choisir la façon dont vous-même décidez d'adopter (ou de réécrire) telle ou telle dépendance.
_ Allô ? C'est mieux. Nous allons commencer cette nouvelle journée de conférences. Nicolas Grekas est un des membres de Symfony SAS. Il participe activement à l'Open Source et au cœur du langage PHP. C'est toujours un honneur de le recevoir et de le compter parmi nos habitués du forum. Vous pourrez le rencontrer plus tard dans la journée pour l'atelier Open Source. Il va nous donner des éléments de ressources à comment décide-t-on de créer un composant Symfony ?
(applaudissements)
_ Bonjour à tous. La présentation est faite. Je vais me lancer directement dans le sujet. Comment on crée un nouveau composant Symfony ? Beaucoup de gens sont venus me voir. Des discussions sur Twitter sur cette question. Quelqu'un m'a suggéré un jour de faire ce sujet au forum. Je me suis dit : Allons-y. C'est risqué de temps en temps, c'est glissant. Mais c'est intéressant.
Un peu rappel rapide pour le contexte, vous le savez déjà, mais Symfony, c'est quelque chose d'Open Source. En MIT. Ça a été publié en 2011. Symfony V1. Celui dont nous parlons, ça fait plus de 10 ans. Il sert à répondre à la problématique du Web. Des API beaucoup aujourd'hui, et ce que les navigateurs vont afficher. C'est l'ensemble des composants les plus utilisés aujourd'hui dans l'écosystème PHP. C'est le plus téléchargé. Tout le monde utilise une brique Symfony dans un projet à un moment ou un autre.
C'est à peu près 4000 contributeurs uniques sur ces 10 années cumulées. Nous en comptons 500 chaque année. Il y a beaucoup de nouveaux entrants. C'est comme cela que nous en avons 4000 aujourd'hui. C'est quelque chose de significatif, donc je suis fier pour la communauté de réussir à permettre à autant de personnes de contribuer sur le code. Beaucoup de téléchargements cumulés à ce jour. Ça fait un nombre qui ne représente pas grand-chose. Mais on peut peut-être le comparer à d'autres téléchargements dans l'écosystème. On se rend compte que ça fait beaucoup. Ça a de l'impact. Quand Symfony fait quelque chose, ça impacte beaucoup de monde. Ça crée des discussions.
C'est 60 composants cœur. L'endroit où toutes les commissions se passent, c'est coupé en plein de morceaux automatiquement, plein de repository que vous pouvez télécharger. Plus de 200 packages. On peut compter les bridges, j'ai mis le Twig dans le 200.
Pour nous, en tant que mainteneurs du projet Symfony, nous avons 200 packages à coordonner. 200 readies à faire au minimum tous les ans.
Une petite frise chronologique pour vous remettre les idées en place et poser le sujet. en 2011, plusieurs composants arrivent en même temps. Tous ensemble sont hérités de l'expérience de Symfony 11, on se retrouve à avoir une approche par composante. Ça répond au problème du Web. Un début de réponse. Très sérieux. C'est grâce à cela que Symfony a commencé son histoire. La version deux. Je ne suis pas né dans l'écosystème Symfony à l'époque. En 2011, c'est Fabien, William Durand. Ce que j'ai fait pour préparer la présentation, j'ai regardé les auteurs qui ont créé le composant. Ce n'est pas parce que quelqu'un a créé un composant que l'historique des contributions lui revient. Bernhard Schussek, William Durand.
2012, ça continue. Nous améliorons les choses sur les bases. Sur les formulaires et la sécurité. 2011, 2012, 2013. Pour faire une expérience de debugging sympathique. Nous sommes en train de montrer un Framework et une existence. C'est à ce moment que j'arrive, 2014. Je fais le composant VarDumper. C'est du code que j'ai réécrit de mon expérience passée. Je suis né avant Symfony. J'ai écrit du code avant. Dans cette expérience précédente, j'avais écrit un dumper. Je l'ai montré à Fabien. Je venais d'arriver. J'ai tout réécrit. Vardumper est arrivé, vous utilisez Dump aujourd'hui.
2015, Polyfill, c'est quelque chose que j'apporte à l'époque. Il y a mon travail dans Unicode. J'ai découpé Patchwork en deux.
Sur la slide, vous voyez la frise chronologique, les contributeurs qui ont amené de nouveaux composants, Kévin. Grégoire Pineau pour le composant workflow. À la droite, vous avez des choses qui existent ou qui préexistent et qui couvrent des domaines similaires. Chaque fois que nous créons en composant Symfony. Quelqu'un a forcément travaillé sur un sujet similaire. Pour Ladybug, on utilisait pour dumper les choses de manière sympathique. Ça n'existe plus. On dit d'utiliser VarDumper à la place. Ça permet d'accumuler une expérience sur un paquet que tout le monde utilise. Qui semble bien marcher.
Pareil pour le composant cache. C'est quelque chose que nous avons attendu longtemps avant de publier. Depuis le début, dans une application Web, il y a besoin d'un cache storage. Nous savions que le PHP FIG était en train de travailler sur une PSR. Fin 2014, on a publié le composant cache. De façon native, dans Symfony, nous avons besoin d'un composant cache. Il arrive, il y a déjà des choses qui arrivent, il y a doctrine cache qui existait déjà, nous avons une proposition dans Symfony cache pour implémenter PH6.
2017, 2018, 2019. Dotenv arrive. Nous réorganisation les projets Symfony, il y a Flex qui arrive. Nous sommes dans les applications 12 Factor. Nous regardons les solutions existantes, il y a le truc que Laravel utilise aujourd'hui. On dit : C'est trop long. C'est une librairie qui a un domaine fonctionnel beaucoup trop lourd et large pour un composant qui va être essentiel. C'est un des premiers que vous allez utiliser quand vous avez Symfony. Un skeleton tout petit, vous avez ce composant.
Je ne vais pas vous faire l'historique de chacun des composants. Mais pourtant, il y a une histoire derrière chacun d'eux. Quelqu'un arrive souvent, on ne l'attend pas, il fait une pool request : le composant lock, j'en ai besoin en pleine application, je prends le temps d'organiser tout cela dans quelques classes et quelques interfaces. S'ensuit une discussion jusqu'au moment où on dit : Tout le monde a compris le sujet et on sait que c'est intéressant. On prend le code aussi. On le merge. Ça arrive plusieurs fois dans l'histoire.
Les composants vont arriver parce que des keynotes se préparent pour des Symfony live. C'est le Conference... ** je pense à Kévin qui a sa conférence cet après-midi. Il a FrankenPHP. Il bosse dessus. Il va faire un sujet dans un mois sur un truc qu'il n'a pas encore écrit. Je lui dis : Ce serait chouette que je l'aie dans Symfony. Nous prenons ton sujet, tu feras le composant.
Je rigole, mais c'est la réalité des choses. Le composant Mailer, Swift Mailer, c'est un projet récupéré. Il ne l'a pas écrit. Nous l'utilisions avant Symfony Meller. Ça date de PHP 5.1 environ. Ce truc, Fabien l'a porté le plus loin possible dans le temps. Chaque fois que nous ouvrions ce code, nous pleurions, parce qu'il y a un Framework dans le Framework. Le composant Mailer a besoin d'un composant de Q. Une injection de dépendances. Quand nous avons plein de choses à coordonner et des services, nous avons besoin d'un conteneur pour configurer le système compliqué de gestion des mails. Je ne vais pas tous vous faire l'architecture de Swift Mailer. Mais nous avons déjà résolu ces composants. Nous avons déjà un composant Messenger un an après. Après, Meller. Nous avons l'injection de dépendances, on se dit : J'ai une conférence qui arrive, j'ai un sujet qui est celui des mails. Il faut réécrire ce truc. On va réutiliser les composants Symfony qui sont déjà prouvés. Messenger.
Je fais le lien avec un autre composant qu'on a introduit. Ils sont à créer. Mailer a besoin de faire des appels HTTP pour envoyer des mails. Aujourd'hui, nous avons fait des API et on passe par HTTP. Un client HTTP en Symfony, lequel ? file get content. Ce n'est peut-être pas suffisant. Il y a Guzzle. Si vous avez suivi l'historique de Guzzle, il y a plusieurs versions majeures, ils ont changé le name space, 3, 4, 5, 6, ça change chaque fois. Nous avons un goût amer de ces pratiques de développements qui sont liés à Guzzle. Ce n'est pas possible de lier l'écosystème Symfony à ce morceau que nous ne maîtrisons pas. Nous ne pouvons pas garantir quoi que ce soit en termes d'évolution future. Peut-être qu'ils ont appris. Mais nous n'en savons rien. Nous avons des process et nous pouvons être fidèles à ces principes. Ça fait 10 ans que nous le suivons et que nous y arrivons. On se dit : Il nous faut un nouveau composant HTTP client. C'est parti. Je fais plein de protos jusqu'au moment où je propose un composant en 2019. En même temps que Symfony Mailer quelque part. C'était juste avant la conférence de Paris où Fabien a parlé de Mailer.
Je continue, il y a toujours plein de librairies qui existent et qui font des choses comparables. Aussi bien sur Messenger que Mailer, etc.
Nous arrivons aux temps modernes. En 2020, 2021, 2022. RateLimiter, Wouter nous a fait un composant. Pour les logins, on demandait régulièrement dans la couche de sécurité un système pour limiter le nombre de tentatives erronées de login. Plutôt que de faire un sous-système du composant sécurité, ça sortait sous forme de composants. Le code était indépendant du système de sécurité. Runtime, je l'ai créé pour répondre à des besoins de mainteneur. Vous installez des projets Symfony, c'est Flex qui met des codes pour lancer les applications. Un index.php qui est dans le public. Je ne peux pas le mettre à jour en tant que mainteneur. Mais ce que je peux publier avec une nouvelle version, c'est ce qui se trouve dans vendor. Mais quand on vous donne une recette et que dans ce code, il y a 10 lignes de code et que je veux les changer, je ne peux pas. Comment faire pour que ce code dont nous avons besoin aujourd'hui, j'arrive à en déplacer le plus possible dans vendor ? Que ces trois lignes soient juste les pointeurs dont j'ai besoin pour bénéficier du code généré ? Le composant Runtime est donné pour cette raison. Ensuite, parce que ça permet aussi d'ouvrir à une histoire qu'on entend dans la communauté. Nous avons du mal à concrétiser de façon stable. Les process PHP, plutôt que d'avoir PHP qui s'allume et qui s'éteint à chaque requête, il y a quand même des cas où nous avons besoin de réutiliser toutes les classes déjà chargées plusieurs fois, ou le kernel Symfony. Ne pas avoir à le charger plusieurs fois. Il ne change pas de requête à l'autre. Runtime ouvre ces runcases. Kévin l'utilise pour son FrankenPHP.
HtmlSanitizer... il y a un composant qui est un peu trop gros. Il y a un sous-name space dans ses composants. Ce serait bien qu'il soit indépendant. Ça fait partie des réorganisations de code qu'on fait régulièrement. Il y a les principes de packaging. Je vais en parler un petit tout à l'heure : Dans un composant, on ne doit pas mettre que des classes qui couvrent le même domaine. C'est une évidence, mais parfois, on ne sait pas quand nous créons un truc trop gros qu'il faudrait qu'on coupe en deux. PasswordHasher, c'est son histoire. C'était dans security corps.
Clock recoupe le sujet d'hier d'Andreas Heigl si vous l'avez vu. Il anticipe la PSR 20 qui sera utilisée dès qu'elle sera utilisée. C'était une introduction, un filtre chronologique.
Quand nous introduisons une nouvelle fonction, ça crée une controverse. Quelques années plus tard, la controverse n'est plus là. Les composants ont prouvé leur intérêt. La communauté a compris que ça n'enlevait rien aux solutions existantes. Ça crée une alternative.
J'ai les petits extraits sur certains composants que les commentaires que les gens ont pu faire sur les pool requests. Sur HTTP client, pour soutenir la proposition, la critique étant : Il y a déjà Guzzle, pourquoi vous créez cela ?
(lecture du PowerPoint)
Ça, je vous en ai parlé pour le process. PSR, 7, 18, etc. Ils sont censés répondre à la problématique de : J'ai besoin d'un Mailer. On code pour l'abstraction. Mais la promesse des abstractions s'arrête très vite. Vous voulez dire : Je require symfony mailer et j'envoie des mails. Mais il faut choisir une implémentation d'une abstraction. Que vous allez brancher avec Mailer. C'est la promesse. Vous pourrez ensuite commencer à l'utiliser. Ça fait trop d'étapes en termes d'expérience de développement.
Ce qui se passe, c'est que tous les SDK, Mailer, Microsoft, Amazon, etc., même s'ils codent contre une abstraction, ils ont un require, mais aussi un autre de Symfony. Pour avoir quelque chose qui marche out of the box. dans le dossier vendors, on se retrouve avec plein de choses qui font la même chose. On a décidé que les abstractions, c'était bien, mais il faut que ça marche.
Il y a ce sujet-là. Il faut que ça marche. Je vous ai parlé de l'impact de Symfony tout à l'heure. On ne peut pas avec l'impact que Symfony a imposé une solution qui pourrait créer des problèmes de millions de personnes à la fois. Il y a une responsabilité à un moment à pousser des choses sur lesquelles nous pourrions dire... on ne nous reprochera pas d'avoir poussé quelque chose qui pourrait devenir problématique.
Il y a aussi ça. Un commentaire de Ryan qui dit : Après avoir joué avec ce nouveau composant, ce nouveau pool request, pendant une journée, c'est trop bien, j'adore. C'est chouette qu'il ait pris le temps de le faire. Guzzle, c'est une façon de faire. Http client, c'est une autre façon de faire. D'abord deux façons de faire différentes avec des niveaux de qualité comparables, ça permet d'avoir une discussion pour savoir comment ça pourrait être amélioré. Vous n'êtes pas forcés de suivre la préférence de la solution. Vous avez le choix de vos préférences. C'est très important. Pouvoir discuter des choses et les comparer.
Aujourd'hui, Guzzle est toujours le même. Il est toujours aussi téléchargé et utilisé. Il a beaucoup appris de ses expériences passées en termes de rétrocompatibilité. C'est très stable. Ça n'a pas vocation à bouger. Le client http, le client aime bien sa façon, son API. Je vois le composer qui dit : C'est bien... ** le client HTTP de Symfony, quand je dis que c'est de Symfony, ça veut dire que ce serait dans un univers fermé. Ce n'est pas le cas. Vous pouvez l'utiliser avec la PSR qui va bien ou avec Httplug qui a été créé pour prototyper PSR 18. Il y a d'autres façons de faire de l'asynchrone. C'est un style que vous pouvez préférer.
Il y a vraiment le choix. Chacun peut choisir sa couleur préférée dans cette façon de faire.
Autres composantes qui créent la polémique, nous les produisions avec Grégoire Pineau à l'époque. UUID arrive dans un univers où Ramsey UUID existe déjà. Il y a deux façons de faire des UUID. Vous utilisez une librairie avec des objets. Comme Ramsey. Vous utilisez l'extension UUID. Nous n'avons pas d'abstraction de concepts et d'objets. Nous avons des chaînes et nous manipulons. C'est le point de départ du composant. Avec Grégoire, on se dit : cette extension, c'est pas mal. C'est une approche valable. Son problème, c'est qu'il faut qu'elle soit installée. Ce n'est pas portable. Quand nous écrivons un code Open Source, on ne peut pas se baser sur l'extension. Le fait d'avoir une extension en prérequis, c'est bloquant pour un projet Open Source. Il sera incernable sans complexité additionnelle.
Nous créons un polyfil. Par-dessus cela, nous allons faire une librairie objet qui va wrapper tout cela dans des objets pour ceux qui veulent faire de la vente d'objets pour value objects. Le composant est très simple.
C'est aussi le contrepoint de Ramsey UUID à l'époque. Je trouve que c'est beaucoup compliqué. La proposition, ce n'est pas exactement... "Quels sont les bénéfices par rapport à Ramsey UUID ?" C'est beaucoup plus simple Symfony UUID en termes de code. Ce n'est pas comme si Ramsey est trop complexe. Oui, il est complexe, vous pouvez changer les méthodes de calcul pour générer les UUID. On peut générer des petites chaînes de caractères. S'il y a beaucoup de complexité qui peut être utile si vous avez besoin de contrôler des UUID de façon très précise. Il y a des Bytes là-dedans qui peuvent avoir du sens. Mais si vous n'avez pas ces Use Cases, vous êtes en train de prendre un marteau pour écraser des mouches. Nous sommes dans la loi de délétère.
L'ambition, c'est de dire : nous voulons un truc qui fait le job. Que ça marche dans 95 % des cas. Si vous êtes dans les autres 5%. Il y a la librairie. Utilisez-la. Ça crée la polémique.
On entre dans le subjectif et il y a des choses qui sont implicites dans ces messages qui suggèrent des intentions néfastes de la part de Symfony. Comme si Symfony était un cerveau avec une ambition de contrôler le monde. Ce n'est pas le cas. C'est un projet auquel les gens contribuent. C'est tout : j'aimerais que Symfony pousse à un écosystème plus divers et plus accueillant que ça embrasse la coopération. Moi aussi. Que Symfony n'utilise pas sa popularité pour s'approprier des choses. Je ne suis pas d'accord. Tout est Open Source. Personne s'approprie quoi que ce soit. "Qu'il crée de la friction", mais c'est le principe d'avancer et de faire des choses. Ce sont ces choses qui sont difficiles à gérer en tant que mainteneur.
J'aime faire une petite rétrospective là-dessus. Ramsey UUID est encore très utilisé. On a proposé des ULID qui arrivent. Ce sont des choses qui sont utiles. C'est bien intégré à Symfony avec des catégories. Ramsey Identifier est né. Il simplifie son code, on lui a ouvert une porte. Il était tout seul sur un sujet. Symfony l'a déstabilisé et il a pu avancer. Symfony a montré qu'on pouvait faire les choses différemment. Il s'est dit : Je vais me bouger. Plutôt que de m'asseoir sur mon statu quo. Je suis forcé. C'est hyper important et intéressant comme mouvement.
Le composant clock est ce dernier. Sur Twitter, il y a des gens prévisibles qui font des commentaires comme cela. Il accuse les Frameworks comme Symfony de faire de l'impérialisme. Ça ne veut pas dire grand-chose. Symfony, c'est Open Source. On y contribue. À partir de ce moment, c'est compliqué d'imaginer qu'il y ait un projet hégémonique de la part de Framework qui ne soit que désagrégation de contribution. Ça ne veut pas dire grand-chose. Il y a toute une discussion intéressante qui s'ensuit. "Je ne voulais attaquer personne". Mais la difficulté, c'est que le mal est fait. Je tape d'abord et après je doute. C'est une attitude sur Twitter qui est compliquée à gérer.
Sur le même sujet, Frank nous dit que ça l'a rendu triste de voir que Symfony créait un nouveau composant clock. Il souffre du syndrome du pas inventéisme avec une appropriation de sujet. Ça m'embête. C'est une blague. Frank fait la même chose. Il a fly system... il y a un truc qui détecte le type min de fichiers. Frank, tu nous accueilles un truc et tu fais la même chose. Tu vas me répondre si tu es dans la salle, tu vas me dire : Ça ne fait pas la même chose. Je vais te dire qu'il y a aussi la différence entre UUID et UID. C'est à ce moment qu'il y a des choses intéressantes qui se passent.
Les détails comptent. Nous avons le droit de faire les choses différemment et de les envisager différemment. Il n'y a pas de problème d'appropriation.
Taylor arrive. Il est mis dans la discussion : ce n'est pas compliqué, je n'ai pas regardé le code et je n'ai pas discuté avec qui que ce soit des Symfony. C'est trivial. Il y a une méthode, l'implémentation, c'était une ligne. Quand il y a des problèmes, nous n'avons pas envie d'embêter qui que ce soit qui n'est pas dans le processus Symfony avec les process Symfony. Puisque c'est simple, on ne s'embête pas. On crée le composant. Il y a un bénéfice, c'est moi qui le dis, Symfony étant très visible, en publiant un nouveau composant Symfony sur le sujet clock, ça permet de dire à des tas de gens : Vous avez un truc à apprendre. Si vous ne connaissez pas le service de clock, vous pourrez le découvrir et vous en servir. Ça peut rendre service à des tas de projets.
C'était ma motivation, mais il y en a sûrement d'autres pour vous.
Dans Symfony, il y a des principes auxquels on ne peut pas déroger. On les met en place et on s'assure qu'ils restent vrais dans le temps. Le principe de publication à date réductible. Tous les six mois, une nouvelle version. Le repository. 60 packages en même temps. Pour moderniser le code. Si j'ai un repository à moderniser pour passer à huit c'est facile. Mais si j'ai 60 auteurs différents dans repository à moderniser, c'est impossible. C'est la promesse de rétrocompatibilité. La promesse de compatibilité avant. De dire que Symfony 4.4, ça tourne aussi en PHP 8.2. C'est la promesse de compatibilité avant avec les prochaines versions de PHP. C'est une politique de dépréciation. Une Core Team qui s'assure que tout cela fonctionne bien. Ce sont des process de sécurité. Ce sont des espaces accueillants. De contributions accueillantes. Ce n'est pas facile à créer. Accueillir les contributions, c'est compliqué. Tout le monde vient et se fait critiquer quand il propose quelque chose. C'est compliqué émotionnellement de gérer tout cela. De donner un commentaire de façon constructive sans que l'autre le prenne mal. Et ne pas prendre mal les commentaires constructifs. Vous le savez, beaucoup de gens sont freinés à la contribution cause de cela. Symfony essaye de créer des espaces accueillants. C'est une CARE team qui s'occupe du code de conduite au sein des conférences et en ligne.
C'est une petite anecdote, mais c'est une intégration continue qui n'est pas ennuyante. Elle ne nous casse pas les pieds. Il y a des projets auxquels je contribue, et quand j'y contribue, je passe mon temps à faire des allers-retours dans l'amélioration continue. Dans Symfony, on essaie de ne pas mettre ce genre de barrière dans les pattes.
Quand j'ai présenté cette conf une précédente fois, on m'a dit : C'est un speech de vente pour Symfony. Ce n'est pas ça. Je suis du côté du mainteneur. "Tous ces trucs, c'est un truc auquel je tiens. Je veux que ce soient des promesses concrètes. Il faut qu'à un moment, j'aie le contrôle sur le code." Je sais que c'est difficile et que c'est un engagement permanent. La seule façon de le faire, c'est d'avoir les mains sur le code.
Un exemple de choses qu'on coordonne dans repository, c'est que vous pouvez utiliser la librairie en question avec n'importe quelle version. Y compris PHP 12. Les gens disent que ça ne marchera pas. Je rappelle la phrase licenciée : "Le logiciel est fourni tel quel sans aucune garantie, inclus, mais pas limité à l'adéquation." Je vous dirai de ne pas vous attendre à ce que marche le logiciel. Imaginez-vous qui s'engagerait à cela. Il faudrait être fou. Personne ne promet cela. Que ça marchera dans le futur. C'est une possibilité pour vous de voir si ça marche le futur. Je veux vous permettre de le faire.
Des gens ne sont pas d'accord. Avoir la conversation avec 12 vendeurs, ce n'est pas possible.
Moderniser le corps. Nous avons 2000 pool requests. Nous pouvons le faire dans une pool request sur 200 projets en même temps. Imaginez s'il faudrait qu'on fasse cela sur Guzzle. C'est impossible.
Donc, il y a des petits principes théoriques, vous connaissez solide, il y a les principaux, le packaging, il y en a trois qui m'intéressent. Les principes de couplage. Il y a un principe qui dit que les dépendances entre paquets doivent être assez clic. Le paquet B ne doit pas dépendre du paquet A. La doctrine common ne doit pas dépendre de l'autre. C'est compliqué. PHP Unit utilisait PHP YAML. Ça ne fonctionnait pas.
Le principe des dépendances stables dit que vous devriez pouvoir modifier les dépendances si elles ont une stabilité moindre que le truc que vous voulez créer. Si j'ai un composant Symfony, quand il est jeune, il va évoluer. S'il évolue et que la librairie sur laquelle il se base évolue elle aussi ou a besoin d'évoluer pour satisfaire les besoins du nouveau composant, le principe : choisissez les dépendances que vous allez pouvoir modifier. Sur lesquelles vous allez pouvoir avoir un impact. Ce n'est pas toujours le cas quand nous prenons des dépendances d'auteurs que l'on ne connaît pas. Parce qu'ils ont leurs visions du projet. Ces discussions peuvent créer de la friction.
La troisième, c'est une composante de stabilité. Il faut qu'un composant soit basé sur des dépendances plus stables que lui.
Pour Symfony, doctrine, c'est une dépendance qui crée des problèmes. Ils ont des process de release qui sont différents. Ils ont des cycles de modernités qui sont différents. Ça crée des problèmes. On ne va pas refaire doctrine. C'est une tâche incroyable. On accepte les conséquences.
Il y a plein de vendors. Ceux qui sont de Symfony qui sont dans les recettes ou les vendors officiels, nous les avons sélectionnés pour être stables. Vous pouvez les utiliser aussi. Ce sont de nouveaux composants Symfony. C'est le principe de dire : Lesquels on doit choisir dans l'écosystème ?
J'espère que j'ai répondu à vos questions. J'avais des slides récapitulatives. Mais je pense que je les ai toutes fait passer. Si vous avez des questions, je crois que vous n'avez pas le temps, mais je suis disponible tout au long de la conférence.
(applaudissements)
_ Merci beaucoup n'hésitez pas à laisser vos remarques sur Open Feedback. C'est important pour les speakers d'avoir vos retours. Merci.
Tweets