Jestem pewien, że inni mają swoje powody, ale największym powodem, dlaczego przeniesione do WebPack (dokładniej webpack-dev-server), to dlatego, że serves your bundle from memory (w przeciwieństwie do dysku), a jego Watcher recompile only the files you changed while reusing the rest from cache (w pamięci). Pozwala to na rozwój znacznie szybciej. Mam na myśli to, że gdy aktywnie edytuję kod, mogę ctrl + s w Sublime Text, do czasu, gdy alt + tab do Chrome, jest już zrobione przebudowanie. Miałem wcześniejszą pracę z trybem "gruntowanie + przeglądanie i pomrukanie", a za każdym razem, gdy oszczędzałem, trwało to co najmniej 5 sekund (czyli po tym, jak wykonałem garść specjalistycznych optymalizacji w budowie gruntowej). W związku z powyższym, nadal zintegrowaliśmy webpack z gulpem, więc dostałem zadanie-biegacza dla mojego projektu.
EDIT 1: Chcę też dodać, że stary grunt + LESS/SASS + browserify + zeszpecić + setup grunt-watch nie przeskalować dobrze. Pracowałem nad dużym projektem od zera. Na początku było w porządku, ale potem, gdy projekt rósł, z każdym dniem stawało się coraz gorzej. W końcu stało się niewiarygodnie frustrujące oczekiwanie, aż chrząknięcie zakończy tworzenie każdego ctrl + s. Okazało się również, że czekam na kilka niezmienionych plików.
Kolejną miłą rzeczą jest to, że pakiet webowy pozwala ci wymagać arkuszy stylów w .js, który ustanawia sprzężenie plików źródłowych w tym samym module. Pierwotnie ustaliliśmy zależności arkuszy stylów za pomocą importu do plików .less, ale te odłączone pliki źródłowe w tym samym module i ustanowiono osobny wykres zależności. Znowu wszystkie są wysoce uparte i to tylko moja osobista opinia. Jestem pewien, że inni myślą inaczej.
EDYTOWANIE 2: W porządku po niektórych dyskusjach poniżej, pozwól mi spróbować przedstawić bardziej zwięzłą i mniej upartą odpowiedź. Jedną rzeczą, która naprawdę dobrze działa, jest to, że można oglądać, czytać, przetwarzać i aktualizować pamięć podręczną oraz obsługiwać minimalną ilość operacji we/wy i przetwarzania plików. Gulp pipe działa całkiem nieźle, ale jeśli chodzi o etap wiązania, nieuchronnie kończy się to koniecznością odczytu wszystkich plików z katalogu tymczasowego, w tym niezmienionych. Wraz z rozwojem twojego projektu, czas oczekiwania na ten krok również rośnie. Z drugiej strony, serwer webpack-dev-server utrzymuje wszystko w pamięci podręcznej, więc czas oczekiwania podczas programowania jest minimalny. Jednak aby osiągnąć ten rodzaj buforowania pamięci, pakiet internetowy będzie musiał obejmować od zegarka do serwera, więc będzie musiał znać konfiguracje preprocessingu. Po skonfigurowaniu webpacka, aby to zrobić, możesz równie dobrze użyć tych samych konfiguracji do wypluwania kompilacji innych niż serwer dev. Więc znaleźliśmy się w tej sytuacji. W związku z tym to, co chcesz zrobić, to nadal zależy od twoich osobistych preferencji. Na przykład nie robię przetwarzania obrazu ani linków na moim serwerze dev. W rzeczywistości mój krok lint jest całkowicie oddzielnym celem.
osobiste preferencje. –
Wydaje się, że w świecie node.js/javascript występuje dziwny trend, zgodnie z "najlepszymi praktykami", a za każdym razem, gdy pojawia się coś nowego, grupa programistów/blogerów nazywa to "najlepszą praktyką", a grupa ludzi skacze na pokładzie. –
Dyskusja wydaje się być zamknięta, więc przepraszam za tę niechlujną wiadomość. Dla mnie webpack nie jest osobistą preferencją. Nie używam, ponieważ webpack-dev-server lub wiele ładnych wtyczek sublimetext. chociaż w niektórych przypadkach może zastąpić użycie zadań biegaczy, w moim bieżącym projekcie używam w połączeniu z łykiem i razem są zwycięskim zespołem. Złoto pakietu sieciowego polega na tym, że można myśleć o modułach i zarządzać jego zależnościami. – EricSonaron