Pytanie Workflow Webpack skutecznie dzielący dostawców i kod aplikacji


Mam problem ze znalezieniem wystarczającej dokumentacji i przykładowych pakietów Webpack, aby przekonać się o idealnym przepływie pracy dla mojej sytuacji. Oto wszystkie funkcje, które sprawiają, że przepływ pracy jest idealny:

  1. Oglądanie, najlepiej poprzez Gulpa, z wydajnym buforowaniem. (Nie myśl, że potrzebuję wymiany modułu i podejrzewam, że może nie pasować do mojego środowiska programistycznego).

  2. Moduły dostawców (teraz mam tylko pakiety npm, nie wszystkie z nich pokazują globalne UMD w ich głównym pliku, jeśli do tego dojdzie), które są

    za. nie parsowane i ponownie kompilowane podczas oglądania (więc rekompilacja jest szybsza),

    b. nie otrzymuj pliku z kodem sourcemap (aby szybciej devtools przeglądarki reagowało szybciej), oraz

    do. Napisz do odrębnego vendor.js pakiet, który przeglądarki mogą buforować niezależnie od pakietów aplikacji.

  3. Moduły aplikacji, które są

    za. jednoznacznie o wszystkich zależnościach (tj. import React from 'react'; nawet jeśli React jest faktycznie eksponowany globalnie lub coś przez # 2),

    b.  ponownie skompilowany podczas oglądania, i

    do. zrobić otrzymać sourcemap.

Większość z tego, co przeczytałem w dokumentacji lub przykładach, nie zdawała się trafiać w tę pracę na głowie.

Chociaż w dokumentach widzę, jak utworzyć pakiet specyficzny dla dostawcy (odtworzony tutaj: Proste rozwiązanie do udostępniania modułów ładowanych za pośrednictwem NPM w wielu pakietach Browserify lub Webpack), podany prosty przykład nie dotyczy adresów 2a i 2b.

Nie widzę w dokumentach żadnych sposobów określania różnych konfiguracji kompilacji (sourcemaps itp.) Dla różnych części lub tworzenia całkowicie oddzielnych pakietów Webpack z osobnymi plikami konfiguracyjnymi, które mogą się ze sobą nawzajem odnosić, chyba że poprzez globalizację wszystkich bibliotek dostawców i używanie ich jako zewnętrznych (?), co nie jest idealne ...

Jestem też ciekawy, czy używają go użytkownicy Gulp gulp-webpack lub zamiast tego taka konfiguracja przewidziana w http://webpack.github.io/docs/usage-with-gulp.html. (Nie jestem pewien, jak dobrze webpack-dev-server zmieściłoby się w moim środowisku deweloperskim, więc chciałbym się do niego przyłączyć gulp-watch Jeśli to możliwe.)

Czy brakuje mi czegoś, o czym wiedzą inni użytkownicy Webpacka? Jaki jest najlepszy sposób na zrobienie tego?

LUB czy to możliwe, że Webpack nie jest odpowiednim narzędziem do pracy?


11
2017-12-21 18:44


pochodzenie




Odpowiedzi:


Oglądanie, najlepiej poprzez Gulpa, z wydajnym buforowaniem. (Nie myśl, że potrzebuję wymiany modułu i podejrzewam, że może nie pasować do mojego środowiska programistycznego).

Posługiwać się webpack-dev-server.

Naprawdę nie potrzebujesz do tego Gulpa, ale możesz użyć jego API Node z Gulpem (robię to).

Moduły dostawców (teraz mam tylko pakiety npm, nie wszystkie z nich pokazują globalne UMD w ich głównym pliku, jeśli do tego dojdzie), które są

za. nie parsowane i ponownie kompilowane podczas oglądania (więc rekompilacja jest szybsza),

Nie sądzę, aby niezmienione pliki były przetwarzane lub przekompilowane podczas oglądania.

b. nie otrzymuj pliku z kodem sourcemap (aby szybciej devtools przeglądarki reagowało szybciej), oraz

Nie wiem, jak to zrobić. Wydaje mi się, że mapy źródeł są albo w całości, albo w całości. Ale możesz użyć devtool: 'eval' który działa znacznie szybciej niż mapy źródłowe.

do. napisz do odrębnego pakietu vendor.js, że przeglądarki mogą buforować niezależnie od pakietów aplikacji.

Myślę, że szukasz split-by-name-webpack-plugin.

Moduły aplikacji, które są

za. jednoznacznie o wszystkich zależnościach (tj. importuj Reaguj z "reaguj", nawet jeśli React jest faktycznie eksponowany globalnie lub coś przez # 2),

To zadziała. Do require globalnie eksponowane biblioteki, użyj externals opcja konfiguracji.

b. są ponownie kompilowane podczas oglądania, i

To, co się zmieniło, zostanie ponownie skompilowane (jeśli korzystasz z serwera webpack-dev).

To nie odpowiada na wszystkie twoje pytania, ale mam nadzieję, że wystarczy, aby dowiedzieć się, czy to działa dla Ciebie. Nie uważam, że "nie oglądanie bibliotek" jest tak dużym problemem, jak to się mówi (jest bardzo mało kary pieniężnej za przebudowywanie buforowanych modułów) i jeśli porzucisz sourcemaps i użyjesz devtool: 'eval'Powiedziałbym, że jest naprawdę szybki. Wreszcie, w pracach dla Webpacka jest nowe rozwiązanie do oglądania więc możesz chcieć dać mu spin. Powinno mieć jeszcze lepsze wykonanie.


9
2018-01-02 15:50



Masz sugestie dotyczące ważnych punktów - dzięki. Jedyną częścią, która mi przeszkadza, odpowiedzią, którą widziałem wiele od innych użytkowników Webpacka, jest lakoniczne "Użyj Webpack-dev-server". Wydaje mi się, że Gulp jest znacznie bardziej elastycznym i niezawodnym narzędziem do uruchamiania zadań, budowania, oglądania itp. Niż Webpack, więc trzymam się go. Sądzę, że jedną z poważnych wad Webpacka jest to, że chce on stworzyć kolejny "ekosystem", zamiast integrować się z tym, co już istnieje. Dzięki jeszcze raz. - davidtheclark
@davidtheclark Gulp to po prostu biegacz zadań. Powinieneś przynajmniej dać webpack-dev-server to próba, wykorzystuje tryb oglądania Webpack, który oznacza szybkie przyrostowe przebudowy. Jest poważnym minusem próba replikowania tego zachowania za pomocą Gulp i gulp-watch, ponieważ nie mogą powiedzieć Webpackowi, które moduły się zmieniły. Będziesz także tracić możliwość ponownego ładowania modułu (chociaż, jak powiedziałeś, nie jest to dla ciebie priorytetem). Serwer deweloperski Webpacka jest jednak trywialny, aby zawinąć zadanie Gulp. - Dan Abramov
"Wydaje mi się, że Gulp jest znacznie bardziej elastycznym i niezawodnym narzędziem do uruchamiania zadań, budowania, oglądania". Nie sądzę, żeby to było uczciwe porównanie. Jednym z nich jest typowy runner zadań, a inny jest pakietem JS. Rozwiązują różne problemy i mogą ze sobą współpracować. - Dan Abramov