Muszę sobie ponarzekać. Postanowiłem pójść z duchem czasu i przejść z #gulp na #webpack. Nie tylko ze względu na to, że webpack jest teraz na topie - po prostu #webpack w porównaniu z browserify kompiluje JS szybciej (tak, znam watchify, tak, testowałem).
TL;DR ` !Webpack jest fajny, ale cholernie trudny w konfiguracji. Gulp jest spoko, ale Gulp + Browserify już nie, a Gulp z Webpackiem używane razem się nie lubią.
Jako, że lubię wiedzieć jak działa narzędzie, którego używam postanowiłem skonfigurować webpacka od podstaw, nie opierając się na żadnym gotowcu. Nie wiem ile dokładnie zajęło mi dopracowanie konfigu, ale myślę, że coś około 3 dni.
Jakie cuda ma mój konfig? W zasadzie to standardowe rzeczy:
- kompilacja ES6 - kompilacja SCSS do CSS - "ekstrakcja" CSS do osobnego pliku (extract-text-webpack-plugin) - kilka pluginów postcss - kopiowanie fontów/obrazków z ./src/ do ./dist/ - budowanie sprite'ów - optymalizacja obrazków - minifikacja
Jak widać, nie ma tutaj żadnych niestandardowych rzeczy i do momentu, gdy webpack zajmował się tylko rzeczami związanymi z JS wszystko szło gładko. Problemy zaczęły się gdy miałem "egzotyczną" zachciankę - chciałem żeby moje pliki CSS nie były ładowane w - chciałem mieć je po ludzku skompilowane do osobnych plików CSS. W momencie gdy do gry wchodzi extract-text-webpack-plugin` wszystko staje się skomplikowane. Webpack nie został do tego stworzony! Cała energia psu w dupę. Webpack zadał sobie wiele trudu, żeby wszystko #!$%@?ć w JS, a my teraz zadajemy sobie drugie tyle trudu, żeby to odkręcić.
Zaraz potem zaczęły się problemy związane z adresami URL do obrazków/fontów i cały szereg zależności (loader, loadera loaderem pogania).
Stwierdziłem więc - #!$%@?ę, będę używał Webpacka do tego w czym jest dobry - do kompilacji JS, a całą resztę będę robił za pomocą Gulpa (optymalizację obrazków, kopiowanie zasobów, kompilacje css, itd). Wszystko super. Gulp robi swoje, Webpack swoje. Ale przecież nie będę #jakzwierzeta uruchamiał osobno Gulpa, osobno Webpacka w 2 oknach konsoli. Będę uruchamiał Webpacka za pomocą Gulpa (w końcu Gulp to task-runner c'nie?)! No i #!$%@? - gulp-webpack nie działa z webpackiem 2.x, webpack-stream też nie (próbowałem też innego rozwiązania, bez gulpowych pluginów, ale niestety nie pamiętam na czym utknąłem, chyba wszystko działało, ale nie miałem logów webpacka w gulpowej konsoli).
--- Nie zrozumcie mnie źle. Ten post nie jest hejtem na webpacka. Webpack to świetne narzędzie, ale moim zdaniem nie nadaje się jeszcze do produkcyjnego użytku. O ile core wydaje się być stabilny i dopracowany, tak cała infrastruktura już nie. Pluginy/loadery są zabugowane, dokumentacji do nich albo nie ma albo jest bardzo zdawkowa.
Dokumentacja samego webpacka też nie jest doskonała. Jest bardzo wyczerpująca, ale żeby móc zrobić z niej użytek trzeba mieć na prawdę dogłębne zrozumienie zasady działania tego narzędzia. Całość opiera się na plikach konfiguracyjnych, w których wcale nie jest jasne jakie jest wzajemne powiązanie między właściwością A i właściwością B. Bardzo często musiałem do różnych rzeczy dochodzić metodą prób i błędów, bo okazywało się, że opcja A działa z opcją B, tylko wtedy gdy opcja C ma wartość Z. Twórcy dokumentacji takie rzeczy uznają za oczywiste, bo wiedzą jak ich tool działa. Zwykły użytkownik niestety nie.
Gulp przy tym to dziecinna zabawka, wszystko tam jest proste. API jest banalne, a cała reszta to zwykły JS. Jedyne co trzeba pojąć to zasadę działania opartą o streamy.
To jest całkiem serio stwierdzenie. Wcale się nie czuję nim obrażony. Jestem słaby :) ... no może nie zupełnie, bo jednak nie wymiękłem i skonfigurowałem #!$%@? (po drodze zgłaszając kilka bugów na githubie), ale czasu na to poświęconego nikt mi nie odda.
@tylkostrimi: A po co ci to? Robisz sobie takie task w gulpie: https://pastebin.com/v14vDHhd i uruchamiasz go w tasku watch przy zmianie w plikach js. I masz wszystko za pomocą jednej komendy i jednego okienka.
@Pesio: Może przekombinowałem? Muszę spróbować tego sposobu, bo jeśli to działa to wracam do Gulpa, a Webpacka będę używał wyłącznie do kompilacji JS - bo w tym jest na prawdę dobry.
Czy używając tego sposobu masz w konsoli zarówno output z gulpa jak i output z webpacka (z kolorowaniem składni, odpowiednim formatowaniem, etc)?
// Edycja:
i uruchamiasz go w tasku watch przy zmianie w plikach js
@tylkostrimi: Jeśli zależy ci na obserwowaniu zmian w plikach przez samego webpacka, to tak średnio, też nie wiem jak by go połączyć z gulpem w ten sposób. Ja go używam tylko do bundlowania. A korzystam z git basha, ale może sprawdzę ten cmder.
TL;DR
`
!Webpack jest fajny, ale cholernie trudny w konfiguracji. Gulp jest spoko, ale Gulp + Browserify już nie, a Gulp z Webpackiem używane razem się nie lubią.
Jako, że lubię wiedzieć jak działa narzędzie, którego używam postanowiłem skonfigurować webpacka od podstaw, nie opierając się na żadnym gotowcu. Nie wiem ile dokładnie zajęło mi dopracowanie konfigu, ale myślę, że coś około 3 dni.
Jakie cuda ma mój konfig? W zasadzie to standardowe rzeczy:
- kompilacja ES6
- kompilacja SCSS do CSS
- "ekstrakcja" CSS do osobnego pliku (extract-text-webpack-plugin)
- kilka pluginów postcss
- kopiowanie fontów/obrazków z ./src/ do ./dist/
- budowanie sprite'ów
- optymalizacja obrazków
- minifikacja
Jak widać, nie ma tutaj żadnych niestandardowych rzeczy i do momentu, gdy webpack zajmował się tylko rzeczami związanymi z JS wszystko szło gładko. Problemy zaczęły się gdy miałem "egzotyczną" zachciankę - chciałem żeby moje pliki CSS nie były ładowane w - chciałem mieć je po ludzku skompilowane do osobnych plików CSS. W momencie gdy do gry wchodzi
Zaraz potem zaczęły się problemy związane z adresami URL do obrazków/fontów i cały szereg zależności (loader, loadera loaderem pogania).
Stwierdziłem więc - #!$%@?ę, będę używał Webpacka do tego w czym jest dobry - do kompilacji JS, a całą resztę będę robił za pomocą Gulpa (optymalizację obrazków, kopiowanie zasobów, kompilacje css, itd). Wszystko super. Gulp robi swoje, Webpack swoje. Ale przecież nie będę #jakzwierzeta uruchamiał osobno Gulpa, osobno Webpacka w 2 oknach konsoli. Będę uruchamiał Webpacka za pomocą Gulpa (w końcu Gulp to task-runner c'nie?)! No i #!$%@? - gulp-webpack nie działa z webpackiem 2.x, webpack-stream też nie (próbowałem też innego rozwiązania, bez gulpowych pluginów, ale niestety nie pamiętam na czym utknąłem, chyba wszystko działało, ale nie miałem logów webpacka w gulpowej konsoli).
---
Nie zrozumcie mnie źle. Ten post nie jest hejtem na webpacka. Webpack to świetne narzędzie, ale moim zdaniem nie nadaje się jeszcze do produkcyjnego użytku. O ile core wydaje się być stabilny i dopracowany, tak cała infrastruktura już nie. Pluginy/loadery są zabugowane, dokumentacji do nich albo nie ma albo jest bardzo zdawkowa.
Dokumentacja samego webpacka też nie jest doskonała. Jest bardzo wyczerpująca, ale żeby móc zrobić z niej użytek trzeba mieć na prawdę dogłębne zrozumienie zasady działania tego narzędzia. Całość opiera się na plikach konfiguracyjnych, w których wcale nie jest jasne jakie jest wzajemne powiązanie między właściwością A i właściwością B. Bardzo często musiałem do różnych rzeczy dochodzić metodą prób i błędów, bo okazywało się, że opcja A działa z opcją B, tylko wtedy gdy opcja C ma wartość Z. Twórcy dokumentacji takie rzeczy uznają za oczywiste, bo wiedzą jak ich tool działa. Zwykły użytkownik niestety nie.
Gulp przy tym to dziecinna zabawka, wszystko tam jest proste. API jest banalne, a cała reszta to zwykły JS. Jedyne co trzeba pojąć to zasadę działania opartą o streamy.
#frontend #webdev #zalesie #programowanie
Ej. Co to za plusy niecałą minutę po opublikowaniu wpisu? Ktoś tu chyba plusuje bez czytania ( ͡° ͜ʖ ͡°)
@szpongiel:
To jest całkiem serio stwierdzenie. Wcale się nie czuję nim obrażony. Jestem słaby :)
... no może nie zupełnie, bo jednak nie wymiękłem i skonfigurowałem #!$%@? (po drodze zgłaszając kilka bugów na githubie), ale czasu na to poświęconego nikt mi nie odda.
źródło: comment_zkqhPzTZwjlqRix9n49cxW28GaWP5W6C.jpg
Pobierz@tylkostrimi: A po co ci to? Robisz sobie takie task w gulpie: https://pastebin.com/v14vDHhd i uruchamiasz go w tasku watch przy zmianie w plikach js. I masz wszystko za pomocą jednej komendy i jednego okienka.
Może przekombinowałem? Muszę spróbować tego sposobu, bo jeśli to działa to wracam do Gulpa, a Webpacka będę używał wyłącznie do kompilacji JS - bo w tym jest na prawdę dobry.
Czy używając tego sposobu masz w konsoli zarówno output z gulpa jak i output z webpacka (z kolorowaniem składni, odpowiednim formatowaniem, etc)?
// Edycja:
Tego bym nie robił, bo
Skoro Ci w końcu wszystko zadziałało, to czemu wracasz do gulpa?
U mnie ostatnio powiększa się niebieskie ;P
@szpongiel:
Nie jest powiedziane, ze wracam. Wrócę jeśli uda mi się go elegancko połączyć z Webpackiem.
Ale rozważam powrót z tego względu, że przy każdej zmianie w konfigu webpacka i każdej aktualizacji modułów (pluginów,