 Donc en fait, j'ai utilisé Webpack dans un thème WordPress, je m'appelle Léa Kirsten Cassidy et j'ai développé Front and WordPress depuis assez longtemps et donc j'utilise, je ne travaillais pas énormément avec WordPress en ce moment mais je travaillais beaucoup avec Webpack donc j'ai pris des connaissances de Webpack pour l'utiliser dans les thèmes WordPress. Donc c'est qui dans cette salle qui connaît Webpack, qui a utilisé Webpack, ce que les autres sont chez Gutenberg. Alors Webpack, on peut penser que c'est, qu'est-ce que c'est Webpack ? En fait Webpack c'est un bon de l'or de module, donc ça concerne les assets, ça concerne le CSS, le JS, les images et en fait ça utilise des loader pour tester des types de fichiers et les bonnes les ensembles de créer les modules. Il est utilisé dans le corps de WordPress, il a remplacé Browser file l'année dernière. Alors je l'ai rentré dans une petite explication des modules JS mais ce que je conseille au lieu de ça, c'est un très bon article d'adfus de Adia Osmani que je l'ai dans mes slides qui explique mieux que moi et en fait c'est le problématique des JS, c'est des variables globales et de les scoper, de les avoir de manière modulaire de faire un structure HTML qui a son propre CSS et son propre JS qui n'a pas de impact et de conflit avec d'autres modules. Donc quand utiliser Webpack pour un thème WordPress, alors Webpack c'est pas pour tout le monde, il est idéal pour les applications, pour ceux qui veulent utiliser ES6 sans se soucier des autres navigateurs d'utilisant en passant par Babel et pour des applications Web donc React et autres. En fait le React app, il utilise Webpack, si on fait l'extract on voit très bien ce que c'est Webpack. Alors il est aussi utile pour le CSS modulaire de pouvoir avoir un CSS qui est compact et très visible et qui correspond uniquement au code affiché. Alors ce qu'il faut prendre en considération avant de choisir Webpack c'est que c'est en JavaScript donc il faut avoir certaines connaissances JavaScript ou être très très bon copier-collé et recherche Google. Il y a un Webpack config qui fait peur à beaucoup de gens, qui fait moins peur après l'avoir utilisé, notamment les chemins sont un peu compliqués, ils sont tous relatifs au package.json. Et c'est pas mal de mettre le chemin en variable pour pouvoir re-utiliser et ne pas devoir trouver le chemin à chaque fois dans le config. Il y a aussi comme tout outil il y a des versions de Webpack donc notamment la version 1 de Webpack assez différente de la version 2, après c'est des changements beaucoup plus minors et il y avait des façons plus simples de changer de version après. Mais c'est problématique qu'on cherche de code sur Internet et c'est écrit pour la version 1 et on est maintenant en Webpack 4. Il y a aussi un sacrément de tuto, notamment si on cherche Webpack et WordPress, il y a très peu d'informations là-dessus. Il y a des alternatives à Webpack, il y a Gulp, il va y avoir une conférence de Maxime tout à l'heure sur le Gulp, ce qui est beaucoup plus simple à utiliser, c'est pas la même chose, c'est un task runner au lieu de vendre de module et grant que tu es là depuis longtemps, qui est également un task runner. On utilise plusieurs choses dont Webpack, NPM, on peut utiliser Yarn, NPM, on s'applique beaucoup sur NPM et sur les scripts NPM dont le pack est un point gizane. Si vous êtes toujours là, si je ne vous ai pas dissuadé d'utiliser Webpack, on va poursuivre. Un frontend idéal, plus de frontend idéal. Alors les raisons pour lesquelles j'utilise Webpack, on a des modules autonomes d'un seul objet, c'est petit, rapide et pas de code gaspillé. Mon code est réutilisable et maintenable, j'ai pas d'engagement, je peux choisir la meilleure de la catégorie et j'ai pas de variable globale. J'ai aussi, je peux ignorer dans le meilleur dément de les anciens navigateurs parce que c'est un point gizane. Je vais juste sortir comme ça. Après, ceux qui voient peuvent regarder. Donc les modules autonomes d'un seul objet, j'aurais préféré vous montrer ton code, mais en fait j'ai fait un exemple sur GitHub qui s'appelle Gridpack qui prend un thème WordPress et découpe un module. Donc là, les modules par exemple peuvent être dans le cadre de WordPress, Comments, Main Navigation, Search Form, je les regroupe en micro-modules. Après, je fais des regroupements de modules, donc the content, l'exert, footer, header, site bar et j'ai fait un small header. Et ensuite, il y a des templates qui correspondent pour moi au single.php, au template php. Donc comme ça quand j'ai la page en question, j'ai le code qui va avec. Petit, rapide, pas de code gaspillé. Là, j'ai un config dont chaque module me permet de préciser le CSS et le JS de chaque module. Donc dans les micros, j'ai que celui qu'il y a appartient. Dans les modules qui sont regroupés, j'importe les autres composants là-dedans. Alors on a un principe dans Webpack qui s'appelle le code speaking. En fait, ce qu'il fait Webpack, il prend tout le code qui est en commun. On utilise un plugin pour faire ça, dont le config que j'allais vous montrer. Et il l'appelle par exemple Comments.js, ce fichier. Il est laudé sur chaque page. Il est caché entre les pages. Donc là, c'est tout le code qui est en commun. Ensuite, on peut avoir un deuxième fichier qui est la page en question. Donc le home.js, le post.js, la catégorie.js. Donc ce qui permet de ne pas mettre tout le code dans un seul fichier qui doit être laudé à chaque fois. C'est moi qui décide dont le config il y a ce qu'on appelle des points d'entrée. Et c'est là où j'ai défini qu'est-ce qui va être dans le commun ou qu'est-ce qui va être considéré pour le commun et les différentes fichiers que je veux créer. Et lui, il va me créer selon ce que je dis dans le config. Le home.js, le home.js, par exemple. Et ensuite, j'aurai mon commun.js et mon commun.css qui se balade entre de tout mon site. Alors pas d'engagement. C'est choisir le meilleur de sa catégorie. Là, j'ai un système de loader que j'aurais bien voulu vous montrer parce que je pense, merci. C'est là que beaucoup de gens ont du mal à comprendre. En fait, les loaders, peut-être... Voilà, ça revient. Alors, bon, pourquoi que je retourne ? Alors, les loaders, ils fait un regex. Donc je peux l'appeler, ils test tous les.js. Et là, par exemple, ils utilisent Babel. Et tout le monde a une idée de ce que c'est, si c'est Babel dans cette salle, plus ou moins. Donc je peux lui passer des presets Babel pour le.js. Je peux aussi, si je voulais que mon home.js soit autrement, j'utilise home.js et je peux passer à notre loader. Pareil pour le CSS, je peux utiliser tout ce qui est sas, stylus, tous les pré-processeurs. Je préfère post-css personnellement. Là, ce qui est utile pour WordPress. Excusez-moi. 15 minutes à tenir la voix. C'est un plugin qui s'appelle ExtricText Plugin. Et lui, il va m'extraire le fichu CSS que je peux utiliser. Je peux faire le NQ dans mon fonction première PHP sur mon template et uniquement dans le template en question. Alors, j'ai pas de variable globale. Donc dans mes modules, je peux déclarer un const. Là, vous voyez, il y a Work in Paris qui est const. Si je fais le console.log, il s'affiche bien. Si je la paie de la console, il n'est pas défini. Donc je peux vraiment scoper tous mes variables au module et j'ai pas de problème de nom. Je sais pas que j'ai de mettre des noms pré-précis. Alors, dernier point, c'est ignorer les anciens navigateurs. Je pense qu'on aimerait tous le faire à 100%. Mais avec, on a Babel par exemple. Donc, Babel, j'espère que vous connaissez ou si vous connaissez pas, demandez-moi après, mais qui permet d'utiliser des modules ES6 qui sont plutôt indispensables qu'on travaille dans JS modular. On peut utiliser des importers au lieu des require et on peut décider quel navigateur on veut supporter et quelle version. Alors, ça augmente le taille du code. Évidemment, il est en train de faire des polyfiles. On peut aussi, j'aime bien CSS Next. Donc là, on peut utiliser ça dans le config d'un loader. Donc à la fin, on se retrouve avec un frontaine de réalistes. On a des modules autonomes sur l'objet. Il est petit, rapide, pas de code gaspillé. Mon code est re-utilisable et maintenable. Il n'y a pas d'engagement. Je peux choisir la meilleure de sa catégorie. Pas de variables globales et on peut presque ignorer les anciens navigateurs. Donc, c'est là qui que lien est-il. Il compris l'exemple de thèmes que j'ai fait sur GitHub. Si vous voulez essayer, attendez demain parce que j'ai un grand push à faire ce soir. En fait, ça découpe, ça montre en couleur un petit peu là où ils sont les modules. Et je pense que ça explique mieux que je peux comment il est découpé. Bien entendu, c'est juste une façon de découper. Le thème, c'était pris de underscore S. Donc il est très simple. Il est classique. Pour l'instant, il n'a pas beaucoup de GIS. Il y a aussi un lien pour un liste de l'odor. Il y a vraiment beaucoup de l'odor. On peut trouver son bonheur. Il y a aussi beaucoup de plugins qui sont très puissants. Il permet d'utiliser de, il y a un qui s'appelle HTML manifest plugins si je me souviens bien. Et il permet de utiliser le manifest.json pour avoir un cache aux images et aux fsgs selon le build on question. Un autre point que je n'ai pas mentionné, c'est qu'on peut aussi avoir un config qui est Dev qui va injecter le code que je suis en train de faire. Après, je vais essayer de montrer le démo et ce qu'il arrive à voir peut venir. Il injecte avec l'HMR qui est hot module replacement qui permet d'avoir vraiment en live. Ce n'est pas un reload. C'est une injection. Donc si je travaille sur les commentaires par exemple comme module, il injecte que ce que je suis en train de faire sur les commentaires. Donc je peux utiliser ça dans mon Dev et je peux faire autre chose comme l'extrack text plugin sur prod. Je vais faire le démo ici. Oui, aussi on peut utiliser, moi je préfère, il y a Webpack Dev Server mais je trouve que dans le cadre de WordPress où on a un site en PHP, on a aussi le front de notre site en JS. Je préfère Browserify et donc là il y a un config pour avoir une version du site en local. Donc je vais essayer de montrer. Donc là j'ai un local.wapprest.test et ici j'ai le même sous localhost 3000 qui marche un peu pareil tout à l'heure. Je fais NPM Run Start et je lance le serveur et là j'ai mon site en local. Donc les couleurs ça signifie des autres templates. Donc je peux aussi, je trouve, je pense, vous voyez pas, mais j'ai un source et un dist. Le source c'est où je travaille, le dist c'est là où il est buildé. J'ai les composants. Donc là je change la couleur des commentaires. Donc là vous n'allez pas le voir du tout. Alors ce que je voulais vous montrer c'est le hot module replacement qui est assez sympa. Donc là je suis dans content, donc le CSS. Donc je change le background et ça se fait automatiquement. Donc je passe au rebond, merci. C'est parce que je vais enlever l'aspect. Donc là je fais, il va le faire et il va faire l'injection directement qui est beaucoup plus rapide qu'un live reload. Donc voilà. Je vais peut-être plutôt reprendre aux questions parce que je ne vois pas trop l'utilité de continuer un demo avec un petit écran. Il y a quelqu'un qui a des questions et en PHP. C'est dans le fonction point PHP. Quand je fais le npm run build, là il va dans mon dossier build, dans mon fonction point PHP, le fichier est relié. Donc j'appelle ma fonction qui vient de build. Donc comme je ferai avec toute autre asset. En faisant build, on gêne juste le dossier build qui a que les assets. Donc on reste dans le thème. Il y a source, c'est là où on travaille. On peut travailler uniquement dans le source et si on est en localhost, on voit bien les résultats. Une fois qu'on veut que ce soit dans la version point PHP, je ne sais pas si vous allez voir. Il va falloir réussir la page, il faut la voir. Mais on aura les modifications là. C'est assez puissant. On peut faire plein de choses en build qui ne s'agit que pour le prod. On peut faire le ramification que dans le prod. En fait là, on peut utiliser un server express. On a l'environnement node qui on peut utiliser les variables pour savoir si on est en dev ou en prod pour faire ce qu'on veut. Est-ce qu'il y a quelqu'un ici qui a déjà essayé de faire un thème avec WAPAC ? Oui. Et il y en a qui ont fait avec grind to golf. Ça vous tente d'essayer ? Le problème que j'ai rencontré c'est qu'en fait, c'est du tuto de WAPAC et vous allez pourdrer à l'exemple. Et vous, étant donné qu'il y avait un bon source PHP à l'arrivée, ça t'emmènerait tout de suite un gros bazar et on pouvait... ça n'est pas comment on réalisait ça. En contre, la documentation de WAPAC bien évolue et en suivant juste la documentation de WAPAC, on peut s'y retrouver quand même. Dans le build, réplique d'HP, générez directement un dossier, le bon dossier thème, on dit à la place de 600, en fait, il me dépend de tout ça. Et donc, c'est assez complexe, ça va être aussi complexe. Et ça, il est justement autant avoir un dossier thème pour toute l'automidité, ce serait idéal, en fait. Oui, et en fait, sur Chrome, par exemple, il y a un outil de coverage, on envoie, par exemple, le JS qui est utilisé sur la page et le CSS utilisé sur la page et on peut comparer de ce qu'on peut faire avec grind, c'est ce qui fait WAPAC qui réduit à beaucoup le code mort. Donc, on peut avoir, avec un peu d'effort ainsi qu'il est très optimisé. Bon, c'est peut-être tout. Voilà.