Jak prosto skonfigurować webpacka do bundlowania pojedynczego pliku html?

W wątku odpowiem na pytanie @andrzejlisek zadanego w mikroblogu.

Konfiguracja webpacka

Potrzebujesz mieć zainstalowany node (najlepiej jakiś nowy), i package manager, np npm albo yarn. Ja użyję yarn, ale działają podobnie.

Zaczynam od dodania package.json,

{
  "private": true,
  "type": "module"
}

Potem instaluję webpacka

yarn add webpack
yarn add webpack-cli

Potem tworzę webpack.config.js:

export default {
  entry: './src/index.js',
  mode: 'production', // or 'development
};

Teraz muszę stworzyć index.js który siedzi w katalogu src/. Teraz gdybym odpalił webpack build to by mi zbundowało sam tylko ten skrypt. A my chcemy też html.
Instaluję więc plugin do webpacka html-webpack-plugin:

yarn add html-webpack-plugin

I dodaję go do webpack.config.js:

import HtmlWebpackPlugin from "html-webpack-plugin";

export default {
  entry: './src/index.js',
  mode: 'production', // or 'development
  plugins: [
    new HtmlWebpackPlugin({template: 'src/index.html'}),
  ]
};

Muszę też stworzyć plik src/index.html który będzie tym plikiem HTML. To prawie zadziała, tylko że teraz masz osobne pliki JS i HTML, a Ty chciałes żeby script był w HTML. Instaluję więc plugin html-inline-script-webpack-plugin:

yarn add html-inline-script-webpack-plugin

I dodaję go do webpack.config.js:

import HtmlWebpackPlugin from "html-webpack-plugin";
import HtmlInlineScriptPlugin from 'html-inline-script-webpack-plugin';

export default {
  entry: './src/index.js',
  mode: 'production', // or 'development
  plugins: [
    new HtmlWebpackPlugin({template: 'src/index.html'}),
    new HtmlInlineScriptPlugin(),
  ]
};

Teraz odpalam komende webpack build (albo yarn run webpack build albo npm run webpack build), i w katalogu dist/ mam mój zbudowany HTML.

W załączniku masz .zip z przykładowym projektem (jeśli chcesz z niego skorzystać, to wystarczy że odpalisz yarn install albo npm install, i możesz budować)..

webpack-inline.zip

OK, sprawdzę w wolnej chwili. Jak będę miał dalsze pytania odnośnie WebPack, to w tym wątku będziemy dyskutować.

Będę dążyć do tego, żeby WebPack zbudował jeden plik z tego przykładu: https://github.com/andrzejlisek/SingleHtmlAppBundler/tree/main/Samples/Multimedia

Oczywiście inne warianty, czyli osobno HTML, osobno jeden plik JS też możliwe.

Jest to wymyślony przeze mnie przykład służący do tesotwania prymitywnego autosrskiego bundlera, który radzi sobie z tym bez problemu, a i zasada jego działania jest bardzo prosta.

Chcesz wsadzić png, mp4, mp3 oraz vtt do .html? ;|

A mogę spytać czemu chcesz to zrobić w taki sposób?

Riddle napisał(a):

Chcesz wsadzić png, mp4, mp3 oraz vtt do .html? ;|

A mogę spytać czemu chcesz to zrobić w taki sposób?

Teraz to jest tak bardziej "sztuka dla sztuki", ale zmotywowane jest to problemami, jakie faktycznie miałem jakiś czas temu:

1. Kilka razy musiałem zbudować aplikację .NET WinForms zawierającą osadzony browser w formatce, w którym miał się wyświetlać wczytany HTML zawierający obrazki. Bywały problemy z obrazkami, raz działało, raz nie działało, a po wsadzeniu obrazków do HTMLa jako BASE64 (jedna z pierwszych odpowiedzi Google, czy w ogóle jest to możliwe i jak to zrobić) problem został rozwiązany raz na zawsze. Sam HTML miał się z czegoś generować, więc nie miało znaczenia, czy obrazki będą osobno, czy wbudowane. Nie szkodzi, że taki HTML ma więcej kilobajtów niż przed połączeniem.

2. Testowałem jakiś HTML wgrany do telefonu z Androidem. W rękach to już miałem trzy różne telefony (HTC WildFire S, potem chyba jakiś Samsung, tera Huawei Mate 10 S), na którymś z nich jak próbowałem odpalać HTMLa z menedżera plików, to telefon najpierw kopiował ten plik do jakiegoś folderu tymczasowego, a potem uruchamiał w przeglądarce. Dlaczego telefon tak robił, nie wiem, w ustawieniach niczego nie znalazłem, żeby tak nie robił. Z drugiej strony, zamiast kombinować z telefonem, to mając taki telefon, najprościej wydaje się mieć jeden plik zawierający wszystko w sobie, a przygotować taki plik, to jak widać, żaden problem. Nie przeszkadza, że połączony plik będzie znacznie większy niż pliki składowe przed połączeniem razem wzięte.

Jak widać, wsadzanie obrazków to jest akurat najprostsza czynność przy bundlowaniu, wsadzanie innych multimediów działa na identycznej zasadzie, inna jest tylko nazwa tagu. Od wsadzania obrazków, CSS i JS do HTML w ogóle zacząłem tworzenie swojego bundlera, a HtmlAgilityPack znacznie ułatwia i przyspiesza sprawę.

Skoro mój bundler daje sobie z tym radę, to co dopiero taki duży bundler, tworzony od lat, jakim zapewne jest ten Webpack.

andrzejlisek napisał(a):

Riddle napisał(a):

Chcesz wsadzić png, mp4, mp3 oraz vtt do .html? ;|

A mogę spytać czemu chcesz to zrobić w taki sposób?

Teraz to jest tak bardziej "sztuka dla sztuki", ale zmotywowane jest to problemami, jakie faktycznie miałem jakiś czas temu:

1. Kilka razy musiałem zbudować aplikację .NET WinForms zawierającą osadzony browser w formatce, w którym miał się wyświetlać wczytany HTML zawierający obrazki. Bywały problemy z obrazkami, raz działało, raz nie działało, a po wsadzeniu obrazków do HTMLa jako BASE64 (jedna z pierwszych odpowiedzi Google, czy w ogóle jest to możliwe i jak to zrobić) problem został rozwiązany raz na zawsze. Sam HTML miał się z czegoś generować, więc nie miało znaczenia, czy obrazki będą osobno, czy wbudowane. Nie szkodzi, że taki HTML ma więcej kilobajtów niż przed połączeniem.

No okej, to nawet się trzyma.

Aczkolwiek jestem ciekaw co to za aplikacja, która wymaga pokazywania części UI przez browser?

2. Testowałem jakiś HTML wgrany do telefonu z Androidem. W rękach to już miałem trzy różne telefony (HTC WildFire S, potem chyba jakiś Samsung, tera Huawei Mate 10 S), na którymś z nich jak próbowałem odpalać HTMLa z menedżera plików, to telefon najpierw kopiował ten plik do jakiegoś folderu tymczasowego, a potem uruchamiał w przeglądarce. Dlaczego telefon tak robił, nie wiem, w ustawieniach niczego nie znalazłem, żeby tak nie robił. Z drugiej strony, zamiast kombinować z telefonem, to mając taki telefon, najprościej wydaje się mieć jeden plik zawierający wszystko w sobie, a przygotować taki plik, to jak widać, żaden problem. Nie przeszkadza, że połączony plik będzie znacznie większy niż pliki składowe przed połączeniem razem wzięte.

A to tojest już dziwne. Czemu nie serwować plików normalnie, i z telefonu to wczytać po URL zamiast wkładać kod źródłowy na telefon?

Aczkolwiek jestem ciekaw co to za aplikacja, która wymaga pokazywania części UI przez browser?

To był element większej aplikacji ERP i w tym przypadku potrzebny był automatyczny odbiór korespondencji ze skrzynki mailowej z możliwością podglądu. Ten browser służył do podglądu treści odbieranych maili, a wiadomo, że to może być HTML z obrazkami. W mailu obrazki są zazwyczaj w załączniku, a w treści jako adres jest podany jakiś specjalny numer. Wstawiałem hen HTML i obrazki do temp i próbowałem zmienić numery na nazwy plików i teoretycznie miało działać, a w praktyce nie za każdym razem. Po wstawieniu obrazków do pliku HTML działały za każdym razem.

A to tojest już dziwne. Czemu nie serwować plików normalnie, i z telefonu to wczytać po URL zamiast wkładać kod źródłowy na telefon?

Wtedy z założenia aplikacja miała być offline dokładnie tak samo, jak każda aplikacja na Androida lub plik exe na Windows, a i jeszcze nie dysponowałem wtedy żadnym serwerem HTTP wystawionym na świat. Akurat te apki które tworzyłem i testowałem miały być traktowane tak samo jak zwyczajne apki, tylko inna technika wytworzenia i fakt, że używa przeglądarki jako runtime, tak to niczym się nie różni. Dla mnie, dostępność online czy offline zależy od założeń i potrzeb, a forma samej apki, czy jest to APK w Javie, czy HTML uruchamiany w przeglądarce nie ma nic do tego. Jedynie nie jest możliwe, wystawienie APK online bez instalowania. Wcale nie jest powiedziane, że jak zrobię w HTML, to musi być online, choć ma to swoje zalety. Jak chcę mieć offline, to nie widzę różnicy czy będzie to APK czy HTML, skoro w obu przypadkach może być w pamięci telefonu, samą apkę można zrobić w czym się chce, w czym się umie. A i jeszcze tu pojawia się kolejny powód, do czego potrzebny bundler, Zamiast sterty wielu plików jest jeden plik, który mogę przenieść, trzymać w folderze z innymi plikami itd.

Po prostu, skoro z jakiegoś tam powodu chcę mieć apkę zainstalowaną w telefonie, to nie widze różnicy, czy zrobię to w Kotninie, czy Flutterze, czy właśnie w HTML+JavaScript, choć w tym ostatnim przypadku mam za jednym zamachem uniwersalną aplikację, któa moze działać i na komputerze z każdym OS i na telefonie i to bez różnicy, czy Iphone, czy Android, czy jeszcze inny, o ile ma przeglądarkę obsługującą to, co ja wykorzystam.

Na moje, to to albo jest jakaś bardzo specyficzna apka, albo prosta apka tylko że przekombinowana. Ale nie wiem które

Riddle napisał(a):

Na moje, to to albo jest jakaś bardzo specyficzna apka, albo prosta apka tylko że przekombinowana. Ale nie wiem które

Ani jedno, ani drugie.
Np. kiedyś zmajstrowałem taką gierkę: https://github.com/andrzejlisek/Roulette , która miała pewne cechy, których nie znalazłem innych. Ja napisałem w HTML+JavaScript, bo tak mi pasowało. W Google Play takich gier jest pewnie dziesiątki i wszystkie instalują się na telefonie. Nie uważam, żeby fakt "zainstalowania" mojej na telefonie pomimo faktu, że jest zrobiona w czymś innym, był przekombinowaniem ani czymś specyficznym. Gdybym nie robił w HTML, tylko w Kotlin jako pakiet APK (albo ewentualnie HTML skompilowany do APK za pomocą Electron lub Tauri), to zapewne nie byłoby niczym dziwnym, że wgrywam na telefon i działa bez internetu.

Inny przykład: https://github.com/andrzejlisek/AudioSpectrum Program wyświetlający widmo dźwięku. Dlaczego akurat w HTML i w JS? Bo jest to możliwe, umiem w tym zrobić i za jednym zamachem mam apkę i na komputer i na telefon. A najprostszy bundler sprawi, że kilkanaście plików zamieni się w jeden plik, co ułatwi proces instalacji, tak samo, jak jest jeden plik APK lub jeden plik EXE na komputerze (przy czym w przypadku C# biblioteki nie są połączone z exe, tylko osobno).

andrzejlisek napisał(a):

Riddle napisał(a):

Na moje, to to albo jest jakaś bardzo specyficzna apka, albo prosta apka tylko że przekombinowana. Ale nie wiem które

Ani jedno, ani drugie.
Np. kiedyś zmajstrowałem taką gierkę: https://github.com/andrzejlisek/Roulette , która miała pewne cechy, których nie znalazłem innych. Ja napisałem w HTML+JavaScript, bo tak mi pasowało. W Google Play takich gier jest pewnie dziesiątki i wszystkie instalują się na telefonie. Nie uważam, żeby fakt "zainstalowania" mojej na telefonie pomimo faktu, że jest zrobiona w czymś innym, był przekombinowaniem ani czymś specyficznym. Gdybym nie robił w HTML, tylko w Kotlin jako pakiet APK (albo ewentualnie HTML skompilowany do APK za pomocą Electron lub Tauri), to zapewne nie byłoby niczym dziwnym, że wgrywam na telefon i działa bez internetu.
Inny przykład: https://github.com/andrzejlisek/AudioSpectrum Program wyświetlający widmo dźwięku. Dlaczego akurat w HTML i w JS? Bo jest to możliwe, umiem w tym zrobić i za jednym zamachem mam apkę i na komputer i na telefon. A najprostszy bundler sprawi, że kilkanaście plików zamieni się w jeden plik, co ułatwi proces instalacji, tak samo, jak jest jeden plik APK lub jeden plik EXE na komputerze (przy czym w przypadku C# biblioteki nie są połączone z exe, tylko osobno).

Tylko czemu tego nie udostępnić po prostu jako stronę? W ogóle byś tego nie musiał instalować, i Twój problem z bundlowaniem znika.

Obie te apki z łatwością możnaby wrzucić na darmowy hosting jak github pages i byłyby dostępna na dowolnym urządzeniu bez instalacji.

Mógłbyś nawet dopisać kawałek kodu żeby z tego zrobić workera, i mógłbyś tego nawet używać bez internetu (pwa).

Riddle napisał(a):

Tylko czemu tego nie udostępnić po prostu jako stronę? W ogóle byś tego nie musiał instalować, i Twój problem z bundlowaniem znika.

Obie te apki z łatwością możnaby wrzucić na darmowy hosting jak github pages i byłyby dostępna na dowolnym urządzeniu bez instalacji.

Teraz to wszystkie moja apki widzą online na https://andrzejlisek.github.io/ . A co do offline, to w tym przypadku nie mam uzasadnionego powodu, jednak idąc tym tokiem myślenia, dochodzimy do wniosku, że tworzenie natywnych aplikacji na komputer lub na telefon nie ma sensu ze względu na brak możliwości udostępnienia online (tak, jak kiedyś były aplety Java i Flash) poza przypadkami, w których zrealizowanie zamierzonej funkcjonalności za pomocą HTML+CSS+JS+WASM nie jest możliwe.

Z webpackiem to pobawię się w weekend i dam znać w niedzielę lub w poniedziałek. Do tego podchodziłem w ten sposób, że jeżeli piszę coś w C++ to dostaję jeden plik program.exe, jak coś robię w Java, to dostaję program.jar, a jak coś robię w HTML to dostanę program.html. Traktuję jako trzy równoważne techniki programowania, jedyna różnica jest taka, że w przypadku HTML nie ma kompilacji, a przed bundlowaniem, ważniejszym problemem niż sterta plików jest to, że przy uruchamianiu z pliku (klikam dwa razy HTML tak samo, jak klikam dwa razy EXE) nie wszystko działa ze względu na "politykę tego samego pochodzenia", a po zbundlowaniu działa.

Mógłbyś nawet dopisać kawałek kodu żeby z tego zrobić workera, i mógłbyś tego nawet używać bez internetu (pwa).

Kiedyś się nad tym zastanawiałem, czy w ogóle "wchodzić w PWA". Wymaga to specjalnej konfiguracji serwera, jakiegoś dodatkowego pliku, na komputerze testowałem jakiś przykład z internetu i przeglądarka jakby nie widziała, że jest PWA i nie proponowała zainstalowania i porzuciłem temat. Nie wiem czy na Github pages to pójdzie. Może wróce do tematu i zobaczę, czy to się da zrobić i jak to działa.

andrzejlisek napisał(a):

Riddle napisał(a):

Tylko czemu tego nie udostępnić po prostu jako stronę? W ogóle byś tego nie musiał instalować, i Twój problem z bundlowaniem znika.

Obie te apki z łatwością możnaby wrzucić na darmowy hosting jak github pages i byłyby dostępna na dowolnym urządzeniu bez instalacji.

Teraz to wszystkie moja apki widzą online na https://andrzejlisek.github.io/ . A co do offline, to w tym przypadku nie mam uzasadnionego powodu, jednak idąc tym tokiem myślenia, dochodzimy do wniosku, że tworzenie natywnych aplikacji na komputer lub na telefon nie ma sensu ze względu na brak możliwości udostępnienia online (tak, jak kiedyś były aplety Java i Flash) poza przypadkami, w których zrealizowanie zamierzonej funkcjonalności za pomocą HTML+CSS+JS+WASM nie jest możliwe.

Ma sens , jeśli jest to konieczne, np jak chcesz je napisać w natywnej technologii. Albo chcesz zapewnić użytkownikowi natywny user experience.

Ale Ty już napisałeś tą apke jako webową, więc nie ma powodu żeby nie serwować jej normalnie z url.

Z webpackiem to pobawię się w weekend i dam znać w niedzielę lub w poniedziałek. Do tego podchodziłem w ten sposób, że jeżeli piszę coś w C++ to dostaję jeden plik program.exe, jak coś robię w Java, to dostaję program.jar, a jak coś robię w HTML to dostanę program.html. Traktuję jako trzy równoważne techniki programowania, jedyna różnica jest taka, że w przypadku HTML nie ma kompilacji, a przed bundlowaniem, ważniejszym problemem niż sterta plików jest to, że przy uruchamianiu z pliku (klikam dwa razy HTML tak samo, jak klikam dwa razy EXE) nie wszystko działa ze względu na "politykę tego samego pochodzenia", a po zbundlowaniu działa.

Trochę to mylna analogia. Nikt praktycznie nie ma takiej potrzeby nigdy - mam wrażenie że Ty też nie.

Brzmi trochę jak wymyślona potrzeba - bo jak wrzucisz tą apke na hosting ,tak jak się robi normalnie , np na github pages Za darmo to będzie to działać tak jak chcesz, tylko bez kombinowania.

Mógłbyś nawet dopisać kawałek kodu żeby z tego zrobić workera, i mógłbyś tego nawet używać bez internetu (pwa).

Kiedyś się nad tym zastanawiałem, czy w ogóle "wchodzić w PWA". Wymaga to specjalnej konfiguracji serwera, jakiegoś dodatkowego pliku, na komputerze testowałem jakiś przykład z internetu i przeglądarka jakby nie widziała, że jest PWA i nie proponowała zainstalowania i porzuciłem temat. Nie wiem czy na Github pages to pójdzie. Może wróce do tematu i zobaczę, czy to się da zrobić i jak to działa.

Ale o czym Ty znowu mówisz? :| wszystko dla Ciebie wymaga "specjalnej konfiguracji" a zrobienie pwa jest tak samo proste jak mój poprzedni przykład z webpackiem.

Zostawmy temat online vs. offline, a także tworzenie PWA, wracamy do walki z WebPack.

Postawiłem wirtualną maszynę z najnowszym Ubuntu, żeby było na świeżo i żeby nie było, że jakiś śmieć lub przestarzała biblioteka uniemożliwia wykonanie jakiejś czynności. W razie czego, można bez problemu zaorać i wszystko powtórzyć od nowa.

Krótko mówiąc, miałem kłopoty z zainstalowaniem node-js i npm, były ostrzeżenia o przestarzałej wersji. Pomijając szczegóły, zaorałem, ponownie zainstalowałem Linux i zacząłem od początku według tego:

https://github.com/nodejs/help/wiki/Installation#how-to-install-nodejs-via-binary-archive-on-linux

Zainstalowało się prawidłowo, wszystko w nowszych wersjach.

Potem zainstalowałem webpack za pomocą NPM i od razu dalsze pluginy:

npm install webpack
npm install webpack-cli
npm install html-webpack-plugin
npm install html-inline-script-webpack-plugin

Nie było żadnych ostrzeżeń, że jest coś nie tak z wersjami.

Do katalogu /home/xxx/Multimedia skopiowałem ten przykład: https://github.com/andrzejlisek/SingleHtmlAppBundler/tree/main/Samples/Multimedia

To jest przykład typu "wszystko w jednym", zobaczymy, co WebPack z tym zrobi.

Tworzę katalog /home/xxx/WPTest

Tworzę pliki /home/xxx/WPTest/package.json i /home/xxx/WPTest/webpack.config.js

{
  "private": true,
  "type": "module"
}

export default {
  entry: './../Multimedia/app2.js',
  mode: 'production'
};

Póki co, próbuję złożyć jakiś skrypt z modułem. Pliki są w katalogu /home/xxx/WPTest/, a źródło do bundlowania w /home/xxx/Multimedia/.

Przeszedłem do /home/xxx/WPTest/, wpisałem webpack build, system zwrócił, ze nie ma takiego polecenia, więc jeszcze raz wypisałem:

npm install webpack
npm install webpack-cli
npm install html-webpack-plugin
npm install html-inline-script-webpack-plugin

Pojawił się katalog /home/xxx/WPTest/node_modules z bardzo wieloma podkatalogami. Wpisałem webpack build, a i tak pojawia się, że polecenie nie zostało znalezione, mogę ewentualnie zainstalować za pomocą "sudo apt install webpack". W katalogu domowym, na którym konsola uruchamia się domyślnie, również jest podkatalog /home/xxx/node_modules z wieloma podfolderami.

Przed chwilą instalowałem, będąc w katalogu, w którym zrobiłem te dwa pliki, a i tak system nie widzi webpack. Co robię nie tak i co powinienem zrobić? Pojawił się plik package-lock.json z obszerną zawartością, nie wiem w którym momencie.

Node, npm i npx mam w wersjach odpowiednio 21.1.0, 10.2.0 i 10.2.0.

Teoretycznie mogę uruchomić coś takiego:

node node_modules/webpack build

Ale nic nie pokazuje, żadnych błędów, ale też nic się nie dzieje. A jak źle napiszę nazwę czy podkatalog, to od razu wyrzuca błąd, że nie ma takiego modułu.

jak chcesz mieć coś jako polecenie globalne w systemie to instalujesz z flagą -g
npm install -g webpack
albo uruchamiasz przez npm / yarn:
npm run webpack build
ewentualnie do PATH dodajesz node_modules/.bin/webpack

Ostatnio znalazłem trochę chęci i czasu na webpack i doszedłem do tego, co następuje:

Okazuje się, że budowanie można uruchomić taką komendą będąc w folderze z plikiem konfiguracyjnym:

./node_modules/.bin/webpack build

Stwierdziłem też, że instalator zmienia plik package.json, więc najlepiej poinstalować wszystkie potrzebne rzeczy, a potem utworzyć package.json.

Podany przykład z pliku "webpack-inline.zip" od @Riddle integruje się i działa, ale to nie jest to, o co chodziło. Docelowo chodzi o to, żeby wskazać plik HTML, a WebPack sam wyczuje, jakie są skrypty wskazane za pomocą <script src="JakisSkrypt.js"><script>. Jak to zrobić? Nawet bez integracji HTML z JS, jak jest jeden czy dwa skrypty, to można zrobić ręcznie, ale jak jest 10 skryptów, to trzeba by zrobić 10 bundlowań, choć to da się zautomatyzować skryptem Bash, mając 10 plików konfiguracyjnych. Tylko, jak przetworzyć skrypty zawarte wewnątrz HTML?

Załączam prosty przykład modułów w pliku Modules.zip Modules.zip , który zrobiłem jakiś czas temu na podstawie https://www.w3schools.com/js/js_modules.asp , sam dorobiłem przykład łączący dwa pierwsze.

W podkatalogu "Modules1" i "Modules2" jest to samo z tą różnicą, że w tym pierwszym skrypty są ręcznie napisane w samym HTML, oprócz samych modułów, a w tym drugim, skrypty są wyciągnięte do osobnych plików specjalnie na użytek testu WebPack, jak integruje moduły. Jak się podaje pliki mod1.js, mod2.js, mod3.js, to bardzo dobrze WebPack integruje, przy czym docelowy plik to main.js, którego nazwę trzeba zmienić. Po tej integracji, skrypty działają poprawnie.

No i pozostaje pytanie, w jaki sposób zintegrować moduły z podfolderu Modules1, gdzie skrypty są zawarte w HTML?

Kolejna rzecz, która bardziej mnie interesuje niż moduły, to Worker i SharedWorker. W takim razie, na tapet wziąłem plik app2.js z https://github.com/andrzejlisek/SingleHtmlAppBundler/tree/main/Samples/Multimedia .

W oryginalnej postaci, Webpack w ogóle nie widzi odniesienia do pliku worker.js. Teoretycznie odnalazłem info, jak to zrobić:
https://webpack.js.org/guides/web-workers/
https://mmazzarolo.com/blog/2021-09-03-loading-web-workers-using-webpack-5/

W praktyce, po zmianie odniesienia do "Worker" tak jak podano, czyli wykorzystując URL, nie uruchamia się w przeglądarce, teoretycznie się integruje, ale w praktyce WebPack też coś robi nie tak. Wytwarza jakiś skrypt i dodatkowy plik, jak się go analizuje, to nie ma śladu oryginalnej funkcji zawartej w Worker, a jak się w ciemno podstawi w miejsce oryginalnego app2.js, to w przeglądarce nie działa.

Pomniejsza kwestia, to wyłączenie minimalizowania, żeby łatwiej analizować, co z czym i jak WebPack łączy:
https://davidwalsh.name/how-to-not-minify-source-with-webpack
https://stackoverflow.com/questions/41255380/can-i-get-webpack-to-bundle-but-without-minification-for-debugging
https://maheshwaghmare.com/webpack/how-to/avoid-minification/?utm_content=cmp-true

Teoretycznie tym czymś jest to: optimization: { minimize: false },, ale w praktyce to tak nie do końca, w praktyce, to po wyłączeniu minifikacji jest natworzone więcej kodu, czyli przy minimalizacji nie tylko są wyrzucone komentarze, spacje, entery i skrócone identyfikatory, ale też tworzony kod jest trochę inny, jak się porównuje. Próba zainstalowania UglifyJs poleceniem npm install uglifyjs-webpack-plugin zakończyła się serią błędów, z drugiej strony, wyłącznie minimalizacji nie jest aż tak ważne (przy jakiś małych skryptach tworzonych do testów można posiłkować się https://beautifier.io/ ), a sam fakt konieczności instalowania dodatkowych wtyczek w celu zrezygnowania z jakiejś czynności (w tym przypadku minimalizacja kodu) brzmi absurdalnie.

Koniec końców, wygląda na to, że w obecnej postaci, WebPack potrafi dobrze tylko dwie rzeczy:

1. Zminimalizować kod JavaScript, żeby plik był możliwie najmniejszy.
2. Zintegrować moduły z skryptem używającego modułu, na użytek starej przeglądarki, która nie zna modułów, i to tylko po wskazaniu pliku *.js, po wskazaniu *.html nie potrafi.

Akurat to są rzeczy, które może i są ważne i przydatne, ale mnie to najmniej interesują.

Co w takim razie z resztą?

Już nie dążę do zintegrowania wszystkiego w jednym pliku, ale chodzi o to, że wskazuje plik HTML, a program sam widzi, jakie pliki *.js są użyte i te wszystkie pliki *.js integruje do pojedynczych. Jak to zrobić?

andrzejlisek napisał(a):

Ostatnio znalazłem trochę chęci i czasu na webpack i doszedłem do tego, co następuje:

Okazuje się, że budowanie można uruchomić taką komendą będąc w folderze z plikiem konfiguracyjnym:

./node_modules/.bin/webpack build

To że piszesz "okazuje się", o tak podstawowej funkcji jak budowanie pliku, sugeruje że raczej nie znasz tego narzędzie najlepiej.

Może zacznij od przeczytania dokumentacji? https://webpack.js.org/guides/getting-started/

andrzejlisek napisał(a):

Stwierdziłem też, że instalator zmienia plik package.json, więc najlepiej poinstalować wszystkie potrzebne rzeczy, a potem utworzyć package.json.

Być może robisz coś nie tak, bo mi żaden package.json się nie zmienia jak odpalam webpack build.

andrzejlisek napisał(a):

Podany przykład z pliku "webpack-inline.zip" od @Riddle integruje się i działa, ale to nie jest to, o co chodziło. Docelowo chodzi o to, żeby wskazać plik HTML, a WebPack sam wyczuje, jakie są skrypty wskazane za pomocą <script src="JakisSkrypt.js"><script>. Jak to zrobić? Nawet bez integracji HTML z JS, jak jest jeden czy dwa skrypty, to można zrobić ręcznie, ale jak jest 10 skryptów, to trzeba by zrobić 10 bundlowań, choć to da się zautomatyzować skryptem Bash, mając 10 plików konfiguracyjnych. Tylko, jak przetworzyć skrypty zawarte wewnątrz HTML?

• Co do parametryzacji wejściowego html'a, to masz dwie opcje:

  • Albo sparametryzować konfigurację, tak żeby można było wywołać build z parametrem, np webpack build --my-html-file custom.html
  • Albo nie używać webpack-cli (czyli już nie webpack build), tylko po prostu użyć funkcji webpack() z poziomu JS, i po prosu ją wywołać, przekazując dowolny parametr.

• Co do bundlowania skryptów prosto z tagów <script>, to wpisałem w google "webpack bundle script from html" i w pierwszym linku znalazłem pytanie na stackoverflow, w której ktoś pyta dokładnie o to:

  https://stackoverflow.com/questions/67523174/how-to-make-webpack-bundle-js-directly-in-script-tag-not-via-src

andrzejlisek napisał(a):

Załączam prosty przykład modułów w pliku Modules.zip Modules.zip , który zrobiłem jakiś czas temu na podstawie https://www.w3schools.com/js/js_modules.asp , sam dorobiłem przykład łączący dwa pierwsze.

W podkatalogu "Modules1" i "Modules2" jest to samo z tą różnicą, że w tym pierwszym skrypty są ręcznie napisane w samym HTML, oprócz samych modułów, a w tym drugim, skrypty są wyciągnięte do osobnych plików specjalnie na użytek testu WebPack, jak integruje moduły. Jak się podaje pliki mod1.js, mod2.js, mod3.js, to bardzo dobrze WebPack integruje,

Nie wiem co próbujesz osiągnąć, musiałbyś mi to lepiej opisać.

andrzejlisek napisał(a):

przy czym docelowy plik to main.js, którego nazwę trzeba zmienić. Po tej integracji, skrypty działają poprawnie.

No weź już nie przesadzaj. Oczywiście że da się banalnie zmienić nazwę wynikowego pliku.

W dokumentacji na stronie "Using configuration" jest to dokładnie opisane. W polu output: {filename} możesz podać swoją nazwę:

https://webpack.js.org/guides/getting-started/#using-a-configuration

andrzejlisek napisał(a):

No i pozostaje pytanie, w jaki sposób zintegrować moduły z podfolderu Modules1, gdzie skrypty są zawarte w HTML?

No jeśli skrypty są zawarte w HTML, to chyba już masz co chciałeś?

Ja chyba zaczynam coraz mniej rozumieć to co próbujesz zrobić, ale jestem przekonany że zarówno bundlowanie jak i wyciąganie skryptów z html da się totalnie zrobić webpackiem, pewnie w nie więcej niż 25 linijek konfiguracji.

andrzejlisek napisał(a):

Kolejna rzecz, która bardziej mnie interesuje niż moduły, to Worker i SharedWorker. W takim razie, na tapet wziąłem plik app2.js z https://github.com/andrzejlisek/SingleHtmlAppBundler/tree/main/Samples/Multimedia .

To jest chyba nawet opisane w dokumentacji jak to zrobić.

andrzejlisek napisał(a):

W oryginalnej postaci, Webpack w ogóle nie widzi odniesienia do pliku worker.js. Teoretycznie odnalazłem info, jak to zrobić:
https://webpack.js.org/guides/web-workers/
https://mmazzarolo.com/blog/2021-09-03-loading-web-workers-using-webpack-5/

W praktyce, po zmianie odniesienia do "Worker" tak jak podano, czyli wykorzystując URL, nie uruchamia się w przeglądarce, teoretycznie się integruje, ale w praktyce WebPack też coś robi nie tak. Wytwarza jakiś skrypt i dodatkowy plik, jak się go analizuje, to nie ma śladu oryginalnej funkcji zawartej w Worker, a jak się w ciemno podstawi w miejsce oryginalnego app2.js, to w przeglądarce nie działa.

Musiałbyś wrzucić kod.

andrzejlisek napisał(a):

Pomniejsza kwestia, to wyłączenie minimalizowania, żeby łatwiej analizować, co z czym i jak WebPack łączy:
https://davidwalsh.name/how-to-not-minify-source-with-webpack
https://stackoverflow.com/questions/41255380/can-i-get-webpack-to-bundle-but-without-minification-for-debugging
https://maheshwaghmare.com/webpack/how-to/avoid-minification/?utm_content=cmp-true

Teoretycznie tym czymś jest to: optimization: { minimize: false },, ale w praktyce to tak nie do końca, w praktyce, to po wyłączeniu minifikacji jest natworzone więcej kodu, czyli przy minimalizacji nie tylko są wyrzucone komentarze, spacje, entery i skrócone identyfikatory, ale też tworzony kod jest trochę inny, jak się porównuje. Próba zainstalowania UglifyJs poleceniem npm install uglifyjs-webpack-plugin zakończyła się serią błędów, z drugiej strony, wyłącznie minimalizacji nie jest aż tak ważne (przy jakiś małych skryptach tworzonych do testów można posiłkować się https://beautifier.io/ ), a sam fakt konieczności instalowania dodatkowych wtyczek w celu zrezygnowania z jakiejś czynności (w tym przypadku minimalizacja kodu) brzmi absurdalnie.

Próbowałeś wpisać w google "webpack disable minification"? Tutaj jest artykuł: https://maheshwaghmare.com/webpack/how-to/avoid-minification/

Mówi przede wszystkim o ustawieniu mode: development oraz innych takich.

andrzejlisek napisał(a):

Koniec końców, wygląda na to, że w obecnej postaci, WebPack potrafi dobrze tylko dwie rzeczy:

1. Zminimalizować kod JavaScript, żeby plik był możliwie najmniejszy.
2. Zintegrować moduły z skryptem używającego modułu, na użytek starej przeglądarki, która nie zna modułów, i to tylko po wskazaniu pliku *.js, po wskazaniu *.html nie potrafi.

Akurat to są rzeczy, które może i są ważne i przydatne, ale mnie to najmniej interesują.

Co w takim razie z resztą?

No, na moje oko to totalnie da się zrobić wszystko co chcesz, tylko nie znalazłeś sposobu na to.

Byłoby najprościej gdybyś po prostu opisał jaki jest Twój spodziewany efekt który chcesz osiągnąć?

andrzejlisek napisał(a):

Już nie dążę do zintegrowania wszystkiego w jednym pliku, ale chodzi o to, że wskazuje plik HTML, a program sam widzi, jakie pliki *.js są użyte i te wszystkie pliki *.js integruje do pojedynczych. Jak to zrobić?

Nie wiem czy mnie znowu nie wysyłasz w pogoń za dziką gęsią, czy to znowu nie jest jakiś pośredni plan, ale to można zrobić bardzo prost:

• sparametryzuj podanie właściwego html'a (albo poprzez parametr w webpack-cli albo przez wywołanie webpack() z poziomu js)
• skorzystaj z linka którego podesłałem, do wczytania skryptu z html'a

Na 1000% nie potrzebujesz pisać do tego swojego parsera.

To że piszesz "okazuje się", o tak podstawowej funkcji jak budowanie pliku, sugeruje że raczej nie znasz tego narzędzie najlepiej.

Powiedziałbym nawet, że (jeszcze) nie znam tego narzędzia wcale, to mój pierwszy kontakt z node.js i webpack, bo nigdy tego nie używałem. Ważne, że wiem już, jak to zainstalować i jak to uruchomić.

Być może robisz coś nie tak, bo mi żaden package.json się nie zmienia jak odpalam webpack build.

Zmiana pliku nie następuje w chwili webpack build, tylko (prawdopodobnie) przy odpalaniu któregoś npm install ... zaszła, co uczyniłem na początku, a potem stwierdziłem zmodyfikowany plik. Potem żadne niekontrolowane zmiany nie zachodzą.

Nie wiem co próbujesz osiągnąć, musiałbyś mi to lepiej opisać.

Przykład z modułami - załącznik Modules.zip
Wejście: Skrypt wewnątrz pliku HTML lub w osobnym pliku, który odnosi się do innego skryptu poprzez import modułu, a ten może ewentualnie odnosić się do jeszcze innego pliku *.js.
Wyjście: Pojedynczy skrypt (osadzony w HTML lub ewentualnie w osobnym pliku), który działa tak samo i nie jest modułem, co pierwotne skrypty.
Dokładnie mówiąc, w przypadku /Modules1, podaję plik index.html i na wyjściu dostaję index.html "ze wszystkim":

W przypadku /Modules2 już połowicznie otrzymałem to, co chciałem, czyli z plików mod1.js, mod2.js, mod3.js otrzymałem samodzielne skrypty, czyli nowe pliki mod1.js, mod2.js, mod3.js, z których każdy zawiera w sobie importowany moduł. Jak zrobię trzy bundlowania, to dostaję to, czego oczekuję. Brakuje tylko tego, żeby do programu wskazać plik index.html, a program sam wyczuł, że bezpośrednio odnosi się do mod1.js, mod2.js, mod3.js i zbundlował.

Przykład z Worker:
Bierzemy te trzy pliki:
https://github.com/andrzejlisek/SingleHtmlAppBundler/blob/main/Samples/Multimedia/app2.js
https://github.com/andrzejlisek/SingleHtmlAppBundler/blob/main/Samples/Multimedia/worker.js
https://github.com/andrzejlisek/SingleHtmlAppBundler/blob/main/Samples/Multimedia/import.js
Wejście: główny plik to app2.js, który odnosi się do worker.js, a ten odnosi się do Import.js
Wyjście: pojedynczy plik, app2.js, który zastępuje trzy wyżej wymienione.

Musiałbyś wrzucić kod.

Dla WebPack, ten kod wymaga zmiany pierwszej linii: https://github.com/andrzejlisek/SingleHtmlAppBundler/blob/main/Samples/Multimedia/app2.js

Przed zmianą:

var WorkerObj = new Worker("worker.js");

Po zmianie:

var WorkerObj = new Worker(URL("./worker.js", import.meta.url));

Dopiero po tej zmianie, WebPack wyczuwa plik worker.js. Celem jest otrzymanie pojedynczego pliku app2.js zawierającego worker.js w sobie.

Nie wiem czy mnie znowu nie wysyłasz w pogoń za dziką gęsią, czy to znowu nie jest jakiś pośredni plan

Niedawno, słusznie zresztą, przekonywałeś mnie, żeby aplikację HTML+JS wystawiać online, wtedy jakiekolwiek bundlowanie nie ma znaczenia, za wystawianiem online stoją konkretne argumenty, z którymi nie da się polemizować. Skoro ktoś wymyślił Webpack, to znaczy, że ja nie jestem jedyną osobą na świecie, która wymyśliła złożenie HTML+CSS+JS do jednego pliku. Złożenie większego projektu, to tak naprawdę wykonanie kilku złożeń elementarnych. Zakładam, że jak się ogarnie, jak z wielu powiązanych plików *.js zrobić jeden plik *.js, a potem się ogarnie jak w HTML wyczuć pliki *.js z HTML i ich treść wrzucić do HTMLa, to ma się już zintegrowanie wszystkiego do HTML, bo to jest połączenie dwóch powyższych czynności. Można tak powiedzieć, że zintegrowanie Worker z plikiem to jest jedno, zintegrowanie modułu to jest drugie, zintegrowanie skryptu w HTML to jest trzecie, a po połączeniu tych czynności otrzymuje się możliwość zintegrowania aplikacji wykorzystującej workery i moduły do jednego pliku.

Cel główny jest następujący: Zamienić to https://github.com/andrzejlisek/SingleHtmlAppBundler/tree/main/Samples/Multimedia na taką postać, że nie będzie potrzebny serwer HTTP, żeby wszystkie skrypty działały. Wstawianie skryptów i multimediów do HTML nie jest na teraz potrzebne, ani ważne. A to, czy taka zamiana ma sens i czy są jakiekolwiek argumenty za tym, żeby nie korzystać z serwera HTTP, to już inny temat. Jeżeli mój amatorski i prymitywny "bundler" dokonał takiego przekształcenia, to WebPack czy inny profesjonalny bundler moim zdaniem tym bardziej powinien dać z tym radę, pewnie kwestia konfiguracji. Aplikacja/demonstracja z powyższego linku jest zrobiona specjalnie do testowania bundlerów.

Jeżeli wyżej opisany cel jest Twoim zdaniem czymś nietypowym, przekombinowanym i niepotrzebnym, to po co wymyślono WebPack?

andrzejlisek napisał(a):

Być może robisz coś nie tak, bo mi żaden package.json się nie zmienia jak odpalam webpack build.

Zmiana pliku nie następuje w chwili webpack build, tylko (prawdopodobnie) przy odpalaniu któregoś npm install ... zaszła, co uczyniłem na początku, a potem stwierdziłem zmodyfikowany plik. Potem żadne niekontrolowane zmiany nie zachodzą.

No to oczywiście że jak instalujesz nową zależność to się zmieni package.json, bo tam jest lista zależnośći :| Więc oczywiście ze jak dodajesz nową zależnośc, to ten plik się zmieni.

Ale to nie ma nic wspólnego z webpackiem, tylko z npm.

andrzejlisek napisał(a):

Nie wiem co próbujesz osiągnąć, musiałbyś mi to lepiej opisać.

Przykład z modułami - załącznik Modules.zip
Wejście: Skrypt wewnątrz pliku HTML lub w osobnym pliku, który odnosi się do innego skryptu poprzez import modułu, a ten może ewentualnie odnosić się do jeszcze innego pliku *.js.
Wyjście: Pojedynczy skrypt (osadzony w HTML lub ewentualnie w osobnym pliku), który działa tak samo i nie jest modułem, co pierwotne skrypty.
Dokładnie mówiąc, w przypadku /Modules1, podaję plik index.html i na wyjściu dostaję index.html "ze wszystkim":

Czyli mówiąc prościej chcesz osadzić wszystkie skrypty z <script> w HTML w tymże HTML'u. No to totalnie webpackiem da się to zrobić, i to nawet nie trudno.

andrzejlisek napisał(a):

W przypadku /Modules2 już połowicznie otrzymałem to, co chciałem, czyli z plików mod1.js, mod2.js, mod3.js otrzymałem samodzielne skrypty, czyli nowe pliki mod1.js, mod2.js, mod3.js, z których każdy zawiera w sobie importowany moduł. Jak zrobię trzy bundlowania, to dostaję to, czego oczekuję. Brakuje tylko tego, żeby do programu wskazać plik index.html, a program sam wyczuł, że bezpośrednio odnosi się do mod1.js, mod2.js, mod3.js i zbundlował.

No to też się da zrobić bez problemu, i napisałem Ci już żę po prostu musisz sparametryzować nazwę tego pliku wejściowego - i nawet napisałem Ci to jak zrobić: albo poprzez przekazanie ścieżki jak parametry uruchomieniowe, albo poprzez wywołanie webpack() z js'a.

Przykład z Worker:
Bierzemy te trzy pliki:
https://github.com/andrzejlisek/SingleHtmlAppBundler/blob/main/Samples/Multimedia/app2.js
https://github.com/andrzejlisek/SingleHtmlAppBundler/blob/main/Samples/Multimedia/worker.js
https://github.com/andrzejlisek/SingleHtmlAppBundler/blob/main/Samples/Multimedia/import.js
Wejście: główny plik to app2.js, który odnosi się do worker.js, a ten odnosi się do Import.js
Wyjście: pojedynczy plik, app2.js, który zastępuje trzy wyżej wymienione.

Czyli chcesz po prostu zbundlować trzy pliki .js w jeden?

Bo jeśli tak, to to jest DOKŁADNIE TO do czego webpack jest zrobiony, i to działa nawet bez specjalnej konfiguracji. Po prostu ustalasz rule w webpacku, że ma importować takie pliki i tyle.

Musiałbyś wrzucić kod.

Dla WebPack, ten kod wymaga zmiany pierwszej linii: https://github.com/andrzejlisek/SingleHtmlAppBundler/blob/main/Samples/Multimedia/app2.js

Przed zmianą:

var WorkerObj = new Worker("worker.js");

Po zmianie:

var WorkerObj = new Worker(URL("./worker.js", import.meta.url));

Dopiero po tej zmianie, WebPack wyczuwa plik worker.js. Celem jest otrzymanie pojedynczego pliku app2.js zawierającego worker.js w sobie.

No to chyba Ci się udało, nie?

andrzejlisek napisał(a):

Nie wiem czy mnie znowu nie wysyłasz w pogoń za dziką gęsią, czy to znowu nie jest jakiś pośredni plan

Niedawno, słusznie zresztą, przekonywałeś mnie, żeby aplikację HTML+JS wystawiać online, wtedy jakiekolwiek bundlowanie nie ma znaczenia, za wystawianiem online stoją konkretne argumenty, z którymi nie da się polemizować. Skoro ktoś wymyślił Webpack, to znaczy, że ja nie jestem jedyną osobą na świecie, która wymyśliła złożenie HTML+CSS+JS do jednego pliku. Złożenie większego projektu, to tak naprawdę wykonanie kilku złożeń elementarnych. Zakładam, że jak się ogarnie, jak z wielu powiązanych plików *.js zrobić jeden plik *.js, a potem się ogarnie jak w HTML wyczuć pliki *.js z HTML i ich treść wrzucić do HTMLa, to ma się już zintegrowanie wszystkiego do HTML, bo to jest połączenie dwóch powyższych czynności. Można tak powiedzieć, że zintegrowanie Worker z plikiem to jest jedno, zintegrowanie modułu to jest drugie, zintegrowanie skryptu w HTML to jest trzecie, a po połączeniu tych czynności otrzymuje się możliwość zintegrowania aplikacji wykorzystującej workery i moduły do jednego pliku.

Cel główny jest następujący: Zamienić to https://github.com/andrzejlisek/SingleHtmlAppBundler/tree/main/Samples/Multimedia na taką postać, że nie będzie potrzebny serwer HTTP, żeby wszystkie skrypty działały.

A działały tzn.? Bo na moje, to wystarczy że weźmiesz te pliku, wrzucisz ja na github pages, otworzysz sobie w przeglądarce adres andrzejlisek.github.io/ i zobaczysz że ta aplikacja działa normalnie.

Czy ja dobrze rozumiem, że po prostu napisałeś sobie apkę w html/js/css i teraz chcesz ją np otworzyć z przeglądarki? Bo jeśli tak, to nawet nie musisz tego bundlować. Wystarczy że ją wystawisz na jakiś hosting i to będzie działac.

andrzejlisek napisał(a):

Wstawianie skryptów i multimediów do HTML nie jest na teraz potrzebne, ani ważne. A to, czy taka zamiana ma sens i czy są jakiekolwiek argumenty za tym, żeby nie korzystać z serwera HTTP, to już inny temat. Jeżeli mój amatorski i prymitywny "bundler" dokonał takiego przekształcenia, to WebPack czy inny profesjonalny bundler moim zdaniem tym bardziej powinien dać z tym radę, pewnie kwestia konfiguracji.

No tak.

andrzejlisek napisał(a):

Jeżeli wyżej opisany cel jest Twoim zdaniem czymś nietypowym, przekombinowanym i niepotrzebnym, to po co wymyślono WebPack?

Webpacka wymyślono dokładnie do tego celu. Dlatego polecam Ci skorzystać z niego.

Czyli chcesz po prostu zbundlować trzy pliki .js w jeden?
Bo jeśli tak, to to jest DOKŁADNIE TO do czego webpack jest zrobiony, i to działa nawet bez specjalnej konfiguracji. Po prostu ustalasz rule w webpacku, że ma importować takie pliki i tyle.

W tym przypadku, tak. Jest skrypt, który tworzy Worker w oparciu o inny plik, a ten inny plik importuje trzeci plik. Jest to przypadek testujący new Worker i importScripts. Taki prosty skrypt da się nawet ręcznie zintegrować do jednego.

No to chyba Ci się udało, nie?

Raczej nie do końca, bo tak:

1. Przed wymaganą modyfikacją pliku JS (chodzi o parametr konstruktora new Worker wg https://webpack.js.org/guides/web-workers/ ) działało po postawieniu na serwerze (np. Github pages lub własny serwer XAMPP na Windows lub PHP na Linux).
2. Po modyfikacji wykonanej tak jak jest napisane w dokumentacji i tylko po to, żeby Webpack wyczuł plik podawany jako parametr Worker, skrypt już nie działa. Przeglądarka Firefox i Chrome wypisuje w konsoli, że nie wie co to jest new URL.
3. Po odpaleniu webpack build faktycznie coś się integruje, ale zintegrowany skrypt nadal nie działa w przeglądarce.

Natomiast z modułami wyszło tak, jak chciałem i działa poprawnie po zintegrowaniu.

A działały tzn.? Bo na moje, to wystarczy że weźmiesz te pliku, wrzucisz ja na github pages, otworzysz sobie w przeglądarce adres andrzejlisek.github.io/ i zobaczysz że ta aplikacja działa normalnie.

Przed jakąkolwiek modyfikacją pod Webpack wszystko działa, jak należy po wrzuceniu na hosting. Raczej trudno, żebym testował jakiekolwiek narzędzie na wadliwej apce. Do testów, to ja nawet nigdzie nie wrzucam, tylko odpalam skrypt basha, który poleceniem cd przechodzi do folderu z apką, po czym wykonuje polecenie php -S localhost:8080. Po uruchomieniu skryptu, w przeglądarce wpisuję http://localhost:8080/ i wszystko działa.

Czy ja dobrze rozumiem, że po prostu napisałeś sobie apkę w html/js/css i teraz chcesz ją np otworzyć z przeglądarki? Bo jeśli tak, to nawet nie musisz tego bundlować. Wystarczy że ją wystawisz na jakiś hosting i to będzie działac.

Taki jest dokładnie cel, jakim jest uruchamianie apki w przeglądarce. Akurat posługuje przykładem, który niczemu nie służy jako apka, a jest specjalnie zrobiony w celu testowania bundlerów. No i tu czuję dysonans. Z jednej strony, bundlowanie to niepotrzebna czynność, bo 99% apek wystawia się na hosting i działa od razu, z drugiej strony, skoro ktoś zrobił WebPack, czy ViteJS, to po prostu jest albo zapaleńcem w tym temacie tak samo, jak ja (z tą różnicą, że mój program da się napisać od zera w kilka dni i zamierzam poświęcić jemu tylko tyle czasu, ile niezbędne do realizacji kilku prostych założeń, które tak naprawdę już zostały zrealizowane, a na program o możliwościach Webpack musiałbym poświęcić zapewne kilka miesięcy), albo bundlowanie w niektórych przypadkach jest potrzebne. Gdzieś czytałem, że jednym z pomocniczych zastosowań bundlera jest dostosowanie skryptów pod starą przeglądarkę i minimalizowanie, ale to raczej marginalne, bo wszystkie przeglądarki samoczynnie się aktualizują i jest dużo powodów za tym, żeby użytkownik końcowy miał aktualną wersję przeglądarki. Natomiast minimalizowanie można przeprowadzić bez integracji plików ze sobą.