Webpack plugin compiler

Pozdrav,

htio bih napraviti dumy compiler plugin za webpack…znači nije fokus na compaliranju, može biti nešto suviše trivijalno. Npr. neka u svim JS file-ovime prekompajlira #ana# u #ivo#

Ali kako to najjednostavnije ubaciti, ne uspijevam baš. Ima brdo dokumentacije oko tih pluginova i ne da mi se sve prolaziti da bi napravio basic kompajler.

…a ne uspijevam izgooglati neki basic primjer.

Pa možda netko ima funkcionalan primjer, da krenem od te točke?

@belmin, ti si ovdje najupoznatiji sa webpackom koliko znam, imaš li štogod što bi mi moglo pomoći?

Hvala.

P.S. basic plugin sam napravio po tutorijalu…ali ne kužim gdje je event da se ukopčam prije ostalih kompajlera, tako da prvo source code provučem kroz svoj kompajler…prije nego završi na obradi kod drugih kompajlera…

Kad god imas nesto ovakvo treba ti alat za leksicku analizu i parser.

Recimo nesto ovako:
https://pegjs.org

Zvuči korisno, mada ću se zagledat kasnije. Jer ne vidim da ovo rješava traženi problem, ili griješim?

Znači, kao što rekoh…što se tiče parsera, može biti maksimalno pojednostavljen. Nije poanta oko toga.
Zanima me gdje i kako se ugrađuje u webpack plugin?

Napravis si skriptu npr. u bash-u ili powershalu , ovisi sto koristis, koja ce ti odraditi stvari po redu.

To se spaja kao webpack plugin, ili pričaš o čemu?

Tvoje pitanje sam shvatio da moras odraditi neke predradnje prije nego sto pokrenes webpack i sl.

Dakle iz ovog tvojeg primjera gore, kako sam ja shvatio tvoj problem:

– parser – odradi nesto sa mojim js file-ovima
– tvoj kompajler
– webpack

A sve te radnje, jednu po jednu mozes rijesti sa skriptom, koja ce ti to odraditi po redoslijedu koji stavis u skriptu.

Na brzinu, najbolje je da uzmes neki postojeci Plugin i vidis kako je to odradjeno.

Evo npr jedan vrlo jednostavan, koji radi slicnu stvar kao i to sto tebi treba.

Ili evo ti oficijelna verzija, slicne stvari

Sto se tice samog ordera, mozda da pozoves svoj Plugin prvo, pa onda ostale ? :thinking:

1 Like

Imao sam tu ideju, ali nisam znao pronaći neki jednostavan plugin da vidim bitno.
A u onom uglify pluginu kojeg ima…tamo se bogme nisam mogao snaći ni za vraga.
Ovo je super što si dao…pomoći će. (Nadam se) :slight_smile:

Je da, to je slijed radnji koje želim postići, ali:

Znači za webpack, da se uštekam na njega. A ne da radim pre-parser izvan webpack sustava.

Mislim da se ipak budućnost daleko manje komplicira, ako je sve pokretano jednim te istim sustavom.

To ima i prednosti i mane.

Sve ima prednosti i mane…pitanje je samo kako ih odvažemo, jer o tome će ovisiti odluka :slight_smile:

Generalno, ovdje puno više problematike vidim ako idem izvan webpacka.
Ali, nije to toliko bitno. Logika parsera je u konačnici najbitnija…a onda se drži zasebno. Kasnije ako se izađe iz sustava webpacka, ista logika se samo ušteka na neki drugi triger.

Koje vidiš da su mane sa webpackom?

Bez webpacka bi bilo nešto zezancije oko podešavanja da izlazni file-ovi tog pre-parsera budu ulazni fileovi webpacka.
Nadalje, webpack je trigiran kada se neki file promjeni. (Ako je watch metoda zadana, a uglavnom je zadana prilikom rada) …i onda kada bi taj pre-parser mijenjao više file-ova, webpack bi poželio poletiti prije vremena. Pa bi se i s time trebalo zaebavati…

Nadalje, webpack je već unutar sebe odradio dependency fileova. Tako da se neću ništa morati s time zamarati, u ruke pre parsera će dolaziti svi file-ovi koji zahtjevaju parsiranje…a da ja s time neću trebati ni najmanje razbijati glavu…

I tako… mislim da su to gore solidni razlozi za držat se jednog sistema.

A jel moram spomenuti da kada bi imao i dva sistema da bi svaki puta morao nekako i pokrenuti oba sistema … a ovako samo startam webpack i on sve odrađuje.

Potpuno krivo, zato imas bash ili powershall skriptu.

Krivo. Ako se file-ovi mijenjaju, to se radi lokalno kod razvoja i kad se radi deploy na produkciju , radi se build svega.

Krivo. Pokreces samo bash skriptu i ona odradi sve, ono sto stavis unutra ili ako radis build na produkciju ili test to onda sve ide na klik.:innocent::innocent:

Ne razumijem baš bash i powershall, pa neću tvrditi da nisi u pravu. Ali daj pojasni onda kako će webpack pomoću toga znati koji su mu ulazni file-ovi?
Pa neke mora imati zadane, zar ne?
A ako je pre-parser utjecao na te fileove, to je onda output pre-parsera?
Što god bash i powershall značili, ne vidim kako mogu činiti da nestane gornja kaskada.

Koliko mi se čini, ovdje nisi skužio što sam ti rekao. A bome ni ja ne kužim što si ti napisao…djeluje mi skroz nepovezano s onim što ti rekoh, pa preskačem…ili pojasni.

Moguće, ali webpack mi nije čak niti na click…nego sam prati promjenu stanja. Ok, sigurno da bi se dalo i ovo tako podesiti…ali onda treba podesiti i da taj prvi triger nakon sebe trigira webpack. Nepotrebna zezancija što se mene tiče…

Btw. nisi napomenuo koje su mane da je sve unutar webpacka podešeno? Umjesto da budu dva sustava…

@bozoou

Npr. sav svoj code držiš na gitu, deploy se radi tako da se napiše skripta koja će odraditi build svega što treba, pokrenuti rsync i kopirat će se promjene na server sve na živo, bez da je site down.

Skripte se pišu u određenom jeziku, npr. uzmimo bash, ništa se ne razlikuje od programiranja php-a, perla i drugih skriptnih jezika.

Skriptu za build možeš napraviti i u perlu, pythinu itd…, nisi ograničen.

U bash skripti ti je sve dostupno kao i linux consoli, sve naredbe i i pišeš code i kao u svakom drugom jeziku.

Ne da bi se dalo podesiti ovako, nego se tako radi, jer ako imaš deploy aplikacije na više servera, onda ti na svakom serveru sve mora biti isto, prvo jedan build i onda rsync.

Mana ovog tvojeg je što si vezan za webpack, tu moraš voditi računa , ako imaš više pluginova da iz konfiguracije čitaš koji ti je plugin aktivan po potrebi i koji će se pokretati i kojim redoslijedom. Što ako imaš više aplikacija, i sad svaka aplikacija koristi samo određene pluginove i neki pluginovi ne smiju biti aktivni za neku aplikaciju , a moraju biti aktivni za drugu aplikaciju, a ti moraš kompajlirat sve aplikacije?
Ovo se sve lako riješi u skripti i imaš odvojene te svoje pluginove kao js skripte ili nešto i samo ih pozivaš tamo gdje ti treba koji.

Možda imam krivo razmišljanje ili drukčije percipiran webpack.

Nadalje tu je održavanje, ako imaš x pluginova, to je teško održavati, reći češ to je samo nekoliko file-ova i sl., međutim to nije tako.

Isto tako nekad se zna dogoditi da u projektu imaš x različitih aplikacija koje moraju biti buildane po određenom redoslijedu na određeni način , a koje čine skup koji se koristi u aplikaciji.

Uglavnom deploy-em se bavi dev ops koji je level više od administracije Os-ova.

Ti si promasio ceo fudbal, sto bi se forumski reklo.

Covjek je fino pitao o Plugin API-u koji Webpack nudi, a ti pricas o Bashu, powershellu, deployu i nekim desetim stvarima.

Meni nije jasno, zasto se uvijek i svugdje komplicira, a rjesenja mogu biti tako jednostavna, i onda nastanu takva rjesenja i takav code kojeg vise nitko ne zeli taknuti i koji je nocna mora i onda ih dev ops psuje na najjace. :smile::smile::smile:
Ovo je iz real world.

Ja ne znam je l’ ti trollas ili ne znas sta je Webpack.

Samo mi objasni kakve veze ima Webpack sa DevOps-om ?

1 Like

Hebate, nisam se snašao ni u tome…možda zato jer ja nemam chunkove pa mi ne vrijedi isto… jer mi se nikakav console.log nije htio aktivirati tamo gdje se u tom primjeru obavlja srž posla.

Na kraju otvorim css-loader i skužim koja sprdačina od code-a mi treba, znači samo ovo:

module.exports = function(content, map){
  
  content = content.replace("nesto", "u nesto");  //proizvoljna obrada contenta 
  return content;

};

I u webpack config file se loader naravno treba dodati među loadere za željeni tip fileova. Huh…

Također bi se dalo naći i ovdje korisnih informacija, oko setupiranja loadera da radi asinkrono:

1 Like

Mene isto zanima… @jorgovan, jel nam možeš molim te objasniti na koje pitanje ti odgovaraš u ovoj temi?

Dao sam ti upute kako bi bilo pravilno raditi, to ne znači da ovo tvoje ne funkcionira.

Ako radiš app za sebe to nije problem, ako radiš app u firmi ili u timu, onda baš i ne možeš raditi kako bi nekad htio jer se moraju poštivati određena pravila ili misliti i na one koji će doći poslije tebe raditi ili na tim, isto tako se treba misliti kako će dev ops to posložiti stvari za deploy.

Deploy više nije danas copy-paste, nego je to cijelo jedno novo područje.
Tiketing sustav, git, dev ops , deploy i ostalo u kombinaciji za kvalitetniji razvoj i održavanje sustava sve automatizirano.

Tipa od toga kad ti se javi neki exception u code-u da se zapiše u bazu i otvori tiket automatski, ako se dogodi drugi puta greška na istom mjestu da se više ne otvara tiket, deploy app i baze iz migracije automatski na klik, uglavnom imam opis na dvije strane od jedne firme kad su tražili c++ developera, i vagao sam da li da idem ili ne. A sustav im je posložen brutalno dobro.

Sve to stoji da istražuješ , tražiš načine kako si olakšati posao u razvoju, sve to stoji, ali onda gledaš kako su to drugi napravili, ako slično postoji, ako ne postoji onda ili otvoriš temu na više foruma pa će ti netko dati smisleno rješenje za to, za svaki problem uvijek postoji više rješenja.

Za webpack, koliko sam skužio to je alat za build js skripti u bundle, kratki odgovor.