Webpack, notifikacija nakon završetka kompajliranja


#1

Pozdrav,

webpack mi javi notifikacijom kada prvi puta kompajlira fileove nakon što se pokrene watch metoda.
No, kako upaliti da tu notifikaciju dobijem nakon svakog sljedećeg kompajliranja, dok watch prati izmjenu skripti?

Hvala.


#2

Mozes iskoristiti Webpack done hook, i ujedno napraviti svoj mini Plugin koji bi u biti izgledao vrlo jednostavno:

class SuccessCompileNotifier {

    constructor(cb) {
        this.cb = cb
    }

    apply(compiler) {
        compiler.plugin('done', this.cb)
    }

}

Zatim u webpack fajlu instanciras plugin i proslijedis mu callback unutar kojeg ces izvrsitit notifikaciju.Ja korisim node-notifier za desktop notifikacije:

const notifier = require('node-notifier')

plugins: [
    new SuccessCompileNotifier(() => {
        notifier.notify({
            title: 'Compile Success',
            message: 'Hello world !'
        })
    })
]

Trebalo bi da sljaka, nisam testirao :slight_smile:


#3

Detaljnije cu gledat kasnije, ali hvala, čini se mnogo koristan odgovor …jer bi se bas volio kačiti na webpack evente :slight_smile:

Postao si pun znanja, svaka cast :wink:


#4

Hvala ti još jednom na ovome, pomoglo je upravo sada :slight_smile:

Nego imao sam jednu malu “nezgodicu”, pa ako imaš slučajno neku ideju što se moglo desiti, bit ću zahvalan da podjeliš.

Naime, napisah neki testni plugin (tj. prepisao ga sa tvog linka) za webpack …te sam ga uploadao na www.npmjs.com s namjerom da ga od tamo instaliram s npm-om. Pretpostavljam da nisam morao tim okolnim putem, nego direktno referencirati webpack config file prema pathu gdje je plugin…ali reko neka ide po PS-u.

I sada, kako sam svjež sa package.json-om i npm-om …bilo me malo struh samo editirati package.json file i pokrenuti npm install. Pa sam išao zadati točno naredbu: “npm install my_test_plugin -D” .
Čega me bilo strah? Pa bilo me strah da npm prilikom te instalacije ne potegne neke svježe fileove sa NPM-a, jer sam ja lokalno neke skripte malo editirao po potrebi…a one koje su moje sam relativno dosta i nadogradio kako je tekao projekt. Pa sam smatrao teškim užasom da mi se moje promjene izbrišu, a da dobijem svježe fileove sa NPM-a. (Mada sam već ranije testirao da će npm instalacija raditi promjene samo ako je definirana nova verzija uz dependencies name …no svejedno me bilo strah.) Dodatno opreza radi sam cijeli projekt copy-paste u zasebni folder…pa kud puklo da puklo…imam svježi backup.

E sada, pokrenem ja “npm install my_test_plugin -D” …i zaista mi se nakon te instalacije u potpunosti pobriše cijeli jedan folder u node_modules? Znači cijela jedna komponenta je nestala …sva sreća pa je svježi backup bio tu…

Nakon što sam komponentu vratio iz backupa, namjerno pokrenem kompletan install : “npm install” …da vidim hoće li opet nestati i više nije nestajala.

E sada mene zanima jel možeš ikako naslutiti koji vrag se tu mogao desiti?
Dovoljno bi mi već bilo da kažeš iz iskustva da npm install logika nije najpouzdanija i da je svakako ok prije instalacije napraviti backup …ili možda znaš neke očigledne greške/cake koje tu vrebaju?


#5

Ne znam tacno sta uzrok problema, ali sigurno znam jednu stvar, a to je da se po node_modules direktoriju NE rade nikakve promjene - to se kosi sa svim nacelima samog NPM-a.

Ukoliko trebas neke specificne izmjene na nekom paketu, forkas ga, uradis izmjene i onda ga koristis.

Ako tako nastavis, vjeruj da ces samo sebi napraviti velike probleme.


#6

Upravu si ovo…ali opet…skroz je nepraktično (gotovo nemoguće) neki paket koji se dinamično razvija svako malo updejtati na NPM pa instalirati u projekt za svaku sitnicu koja se izmjeni. To bi bio enooorman gubitak vremena…

Zato ja radim promjene direktno u node_modeles dirketoriju, tako svaku izmjenu dobijem odmah da radi bez ikakvih dodatnih kerefeka …a onda kada imam gotovu neku cjelinu, onda te izmjene kopiram u originalni direktorij tog paketa, od kuda ga updejtam na NPM. Pa sve ostane sinkronizirano…te drugi projekti mogu povući novu verziju sa NPM-a.

Problem može jedino nastupiti ako bi na dvije strane tako lokalno razvijao neki paket kroz različite projekte…pa to onda povezati u neku cjelinu koju bi updejtao na NPM server. No u praksi nikada ne razvijam na dvije strane…nego samo u sklopu projekta na kojem radim i koji koristi odgovarajući paket. Kada se prebacujem na drugi projekt…onda prije prebacivanja updejtam po spomenutoj proceduri sve izmjene na paketima na NPM. (što je uvijek malo bolno…i definitivno koči da se lakše skače sa projekta na projekt)

Prije dok nisam radio sa NPM-om, imao sam jedan folder koji sam zvao CROS_FOLDER, u njemu sam imao sve svoje komponente koje sam koristio unutar drugih projekata. Prilikom razvoja nekog projekta i korištenja tih paketa, dirketno sam referencirao na neki paket u CROSS_FOLDER-u, tako da su svi projekti koristili neke zajedničke skripte. Tada, kada bi radio neki updejt na nekom od paketa…taj updejt bi se automatski aplicirao na sve projekte koji koriste taj paket (samo u lokalnom radu). To je bilo s jedne strane praktično…s druge strane boli glava kada nema verzioniranja, pa se napravi neki updejt koji pokrši nešto u projektu koji zapravo miruje sastrane.

Ipak, kod svakog publishanja online bi došlo do zaključavanja tog projekta, jer kod uploada bi se uploadale i skripte iz CROSS foldera, pa bi projekt postao nezavisan od daljnih updejta. Ali zato je trebalo uvijek gledati što se polomilo lokalno kada bi nakon nekog vremena se vraćao u neki projekt. Doduše, i lokalno kada sam htio zaključati neki projekt, (napraviti ga nezavisnim)…onda bi lupio copy-paste taj CROSS folder i samo u configu projekta promjenio path prema novoj kopiji CROSS foldera.

Sve je to radilo zapravo i dosta dobro :slight_smile: …i tjeralo me da pišem backward compatible code. Rekao bi da je bilo i praktičnije nego što imam trenutno sa NPM-om …samo što je NPM dakako bolje prilagođen za korporativni rad i suradnju s drugima.

Nisam još probao, ali pretpostavljam da bi se webpack mogao podesiti da dobijem isto što sam imao sa CROSS FOLDEROM, a da zadržim i mogućnost verzioniranja sa NPM-a po potrebi. To bi mi trenutno super odgovaralo :slight_smile:


#7

Jedino kada bi se napravila (ili postoji) neka skripta koja bi automatski novonastale promjene u nekom paketu updejtala na NPM i na zadane projekte odmah nasnimila zadnju verziju.


#8

Upravo to je i olakšavajuća okolnost rada sa npm-om, composer-om ili sličnim dependency manager-om.
Nikad se ne kopiraju fajlovi iz localhost-a na online server već package.json file a na online serveru se samo izvrši komanda np install - slično k’o i sa PHP-om, composer install.
Kad se mijenja kod modula, to se upravo radi kako je gore objašnjeno, forkuje se izmijeni i uključi u package.json fajl. Ako se radi još izmjena, forkuje se u novu verziju, izmijeni se i uključi se ta verzija u package.json.
Evo vidi u docs-u, vrlo je jednostavno.

U tome je sva mudrolija npm-a - (again) izmijeni se komponenta u package.json fajlu i izvrši komanda npm install.

I opet NE, NE i NE kopirati node_modules i vendor direktorijume. Tako kako radiš, realno ne bi moglo da se uskladi/standardizuje ni dvoje ljudi a kamoli projekat koji realno zahtjeva >= 3 čovjeka.
Stvarno sam prvi put mislio sa se šališ navodeći izmjene paketa bez ikakve dokumentacije i/ili izmjene verzije. :frowning: :zipper_mouth_face:


#9

Znači oko reloadanja stranice sekunde igraju ulogu…a ne da se mora mijenjati dodatno neki file i još pokretati neka komanda. (U ovom slučaju bi se komanda trebala pokretati čak na dva mjesta, “publish to npm” i “npm install”)

Današnji sustavi idu tako daleko da su napravili čak da se promjene u skriptama apliciraju na web (lokalni rad)…čak i bez reloadanja stranice. Znači hot moduli koji ažuriraju skripte na stranici čim se promjene opaze…bez reloadanja stranice. CSS još nije problem…ali JS, to je već malo kompleksnije za tako nešto složiti…pa se ide u tom smjeru. Hoću reći, vrijeme je dragocjeno…oko relodanja stranice svaka sekunda igra ulogu…a ne da se dodatno mora mijenajti package.json file…i vršiti npm komande …samo da bi se promjene afektale na stranicu.

Kužim ja da grupni rad nosi svoju problematiku…ali i tu postoje pametne tehnologije merganja koje dopuštaju da se file istovremeno mijenja na dva mjesta i da se provjeravaju konflikti prije merganja. Još ako je sve pokriveno testovima, onda ima tu puno prostora da se radi paralelno i da ne boli glava.

No ovdje nije slučaj da radim paralelno na istim skriptama…pa onda neke probleme nemam. Shodno tome si pojednostavim život gdje mogu. (Dok mogu)
A kao što sam rekao…prije bilo kakvog kritičnog trenutka napravim svježi publish na NPM.

Kada neću moći ovako zbog okolnosti, onda ću definitivno prvo uložiti vrijeme u automatizaciju procesa (Da se izmjene na paketima automatski publishaju u NPM i da se to automatski instalira u zadani projekt…bez ikakvih tipkanja komadi, nego sve po “watch” pristupu)


#10

Čini mi se da se ovde ne pravi razlika izmedju testing/development servera i produkcijskog.
A scripte postoje, nešto poput push to deploy. Recimo Laravelov Forge (enterprise solution) može da se podesi da pokreće komande i skripte na bilo koji event a push to deploy može da se podesi i na bitbucket/github.
Napravi se skripta na serveru koja će biti webhook za bitbucket npr.
Svaki put kad se pošalju izmjene u repozitorijum, bitbucket će gadjati ovaj URL a na njemu može da se postavi Symfony-jeva Process komponenta šta server (sve) da uradi kad ga se trigeruje.