{"action":"created","issue":{"url":"https://api.github.com/repos/mangaki/mangaki/issues/60","labels_url":"https://api.github.com/repos/mangaki/mangaki/issues/60/labels{/name}","comments_url":"https://api.github.com/repos/mangaki/mangaki/issues/60/comments","events_url":"https://api.github.com/repos/mangaki/mangaki/issues/60/events","html_url":"https://github.com/mangaki/mangaki/pull/60","id":126972144,"number":60,"title":"Remet à la mode du NPM le code JavaScript de Mangaki","user":{"login":"RaitoBezarius","id":314564,"avatar_url":"https://avatars.githubusercontent.com/u/314564?v=3","gravatar_id":"","url":"https://api.github.com/users/RaitoBezarius","html_url":"https://github.com/RaitoBezarius","followers_url":"https://api.github.com/users/RaitoBezarius/followers","following_url":"https://api.github.com/users/RaitoBezarius/following{/other_user}","gists_url":"https://api.github.com/users/RaitoBezarius/gists{/gist_id}","starred_url":"https://api.github.com/users/RaitoBezarius/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/RaitoBezarius/subscriptions","organizations_url":"https://api.github.com/users/RaitoBezarius/orgs","repos_url":"https://api.github.com/users/RaitoBezarius/repos","events_url":"https://api.github.com/users/RaitoBezarius/events{/privacy}","received_events_url":"https://api.github.com/users/RaitoBezarius/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":11,"created_at":"2016-01-15T22:34:12Z","updated_at":"2016-01-16T14:13:02Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/mangaki/mangaki/pulls/60","html_url":"https://github.com/mangaki/mangaki/pull/60","diff_url":"https://github.com/mangaki/mangaki/pull/60.diff","patch_url":"https://github.com/mangaki/mangaki/pull/60.patch"},"body":"Il s'avère que les dépendences libres, c'est le mal.\r\nIl s'avère que travailler en ES5, c'est le mal.\r\nIl s'avère que le support IE7, c'est le mal.\r\n\r\nJe vote pour la dictacture du développeur, faisons du ES7 sans protection, minifions notre code et faisons du long-term caching sans lendemain.\r\nUtilisons des outils voués à disparaître dans quelques heures.\r\n\r\nBref.\r\nWebpack + Babel (ES6/ES7) + Hot Module Replacement + SASS + Long-term caching + Minification.\r\nWhat's else?\r\n\r\n(DO NOT MERGE)"},"comment":{"url":"https://api.github.com/repos/mangaki/mangaki/issues/comments/172209660","html_url":"https://github.com/mangaki/mangaki/pull/60#issuecomment-172209660","issue_url":"https://api.github.com/repos/mangaki/mangaki/issues/60","id":172209660,"user":{"login":"RaitoBezarius","id":314564,"avatar_url":"https://avatars.githubusercontent.com/u/314564?v=3","gravatar_id":"","url":"https://api.github.com/users/RaitoBezarius","html_url":"https://github.com/RaitoBezarius","followers_url":"https://api.github.com/users/RaitoBezarius/followers","following_url":"https://api.github.com/users/RaitoBezarius/following{/other_user}","gists_url":"https://api.github.com/users/RaitoBezarius/gists{/gist_id}","starred_url":"https://api.github.com/users/RaitoBezarius/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/RaitoBezarius/subscriptions","organizations_url":"https://api.github.com/users/RaitoBezarius/orgs","repos_url":"https://api.github.com/users/RaitoBezarius/repos","events_url":"https://api.github.com/users/RaitoBezarius/events{/privacy}","received_events_url":"https://api.github.com/users/RaitoBezarius/received_events","type":"User","site_admin":false},"created_at":"2016-01-16T14:13:02Z","updated_at":"2016-01-16T14:13:02Z","body":"> Est-ce que tu pourrais donner un exemple concret de ce que cela signifie ?\r\n\r\nSupposons que ton index.html est généré par Django, cela sous-entend que tu dois écrire du code supplémentaire pour intégrer les scripts de Webpack Dev Server *uniquement* lorsqu'il y a vraiment utilisation du serveur. Ce qui pourrait arriver c'est que par exemple, un contributeur utilise des assets écrits sur le disque dur, il risque de se prendre un erreur dans la tronche à cause de script tags qui ne sont pas disponible (car ils sont destinés à être chargé en mode développement AVEC Webpack Dev Server qui est lancé en même temps).\r\n\r\nEnfin, c'est plus un point de vue d'esthétique, mais quand j'inspecte l'index depuis le browser, je n'aimerais pas voir les détails du tooling, j'aimerais juste voir mes bundles chargés. C'est ça que j'entends par pollution du index.html, quand tu vois des trucs spécifiques à Webpack qui n'ont aucun rapport avec ton code.\r\n\r\nJe sais pas si c'est clair, mais concrètement, iframe ça rime avec CSP, CSP ça rime avec Content Security Policy, ça rime aussi avec des erreurs chiantes à résoudre. ça rime aussi avec trucs galères comme ça: https://github.com/webpack/webpack-dev-server/issues/340 (on est souvent mieux servi par nous-même, il faut trouver le bon milieu).\r\n\r\n> Il y a à mon avis un tradeoff à considérer entre avoir une stack irréprochable et avoir une stack maîtrisée par suffisement de contributeurs. Je comprends ton point de vue, et j'essaye de représenter le but d'avoir une stack facilement maintenable et facile d'accès pour des nouveaux contributeurs - je ne suis pas non plus là pour dire toutes les 5 secondes \"cette techno à moins de 10 ans, elle n'est pas assez mature\" sans réfléchir :-)\r\n\r\nDans le sens où là il ne s'agit pas vraiment de maîtriser la stack, si les contributeurs le veulent, ils peuvent.\r\nCependant, en faisant cela, j'essaye d'apporter un certain automatisme (qui a un coût), mais qui apporte une productivité (j'espère) relativement haute pour que ce coût soit négligeable.\r\nDans le sens aussi où un contributeur n'a pas besoin de modifier la config de Webpack dans 90% des cas, hormis si il:\r\n\r\n- rajoute un nouveau type de fichier: LESS, i18n, etc...\r\n- rajoute un nouveau plugin: PrefetchPlugin, ProvidePlugin, etc...\r\n- fait des trucs assez exotiques (dont je ne vois pas l'usage pour le moment)\r\n\r\nDonc je vois ça comme ça:\r\nLe contributeur est accueilli par des outils qui:\r\n\r\n- l'aide à bosser plus vite\r\n- le laisse se concentrer sur le code plutôt que le workflow\r\n\r\n> Par exemple, quels sont les avantages de l'approche webpack & co par rapport à une passe de babel+minification+etc. statique automatisée lors d'une mise à jour, qui serait probablement plus simple et plus facilement maintenable ?\r\n\r\nDéjà, il faut bien comprendre ce que cette PR permet dans un premier temps:\r\n\r\n- le HMR est irremplacable donc plus d'update à la volée du code en temps-réel (sans l'approche actuelle)\r\n- Il faut obligatoirement Webpack ou Browserify (ou similaire) afin de pouvoir utiliser `require` à destination du navigateur. (supposons une passe simple de Webpack dans la suite des bullets points)\r\n- Il faut écrire des scripts pour gérer le bundling development et production.\r\n- On ne peut plus faire des modules séparés (init, ui, vote, etc...), sinon les scripts deviennent extrêmement complexes et on est en train de réécrire Webpack.\r\n- On ne peut plus réellement séparer les dépendances vendors, on est obligé des les intégrer par CDN ou whatever.\r\n- On perd le long-term caching ([name].[hash].[ext] → app.23141Aaffazfaz.js)\r\n- On perd la génération de manifest pour mapper les assets (mais ça on s'en fout parce qu'on a plus de long-term caching)\r\n- Plus de déduplication du code\r\n- Plus d'optimisation de l'ordre des require des modules\r\n- Plus de linter automatisé à chaque preloading des modules (qui se fait automatiquement avec ESLint).\r\n- Plus de compilation de CSS Modules + PostCSS + SASS avec Source Maps sans réécrire une partie de Webpack\r\n- Plus de autoprefixer (pour les préfixes CSS) et de minification du CSS sans encore un autre outil à intégrer dans les scripts\r\n\r\nEt probablement d'autres choses que j'oublie, je fais ça en lisant le `webpack.config.js`, mais l'idée est là."}}