Webpack - UglifyJsPlugin - dead code removing by switch

Pozdrav,

zanima me kako da napravim kontrolne točke / konstante preko kojih ću upravljati ponašanjem death code removera?

Znači, ako imam sljedeći code:

function test(){

	const x=1;
	if(x) return;

	console.log("ovo je maknuto by death code remover")

}

death code remover vidi da je x uvijek true, i miče zadnji dio code-a sa console logom. Ali već sljedeći code neće biti na isti način obrađen od death code removera:

const x=1;
function test(){

	if(x) return;
	console.log("ovo (ni)je maknuto by death code remover")
}

.tj. death code remover neće pokušati dokučiti koje je permanento stanje varijable x.

Sada mene zanima jel ima način da se nekako kroz webpack konfiguraciju postave tako nekakve konstante koje će diktirati ponašanje death code removera?

Hvala.

to inače radi javascript garbeage collector možda da pokušaš tako proguglati, recimo najpoznatiji javascript engine se zove V8, pa možda da provjeriš ako ima gdje kako oni to rade.

Koliko znam, svrha garbeage collectora je da čisti RAM memoriju od adresa koje se više u programu ne koriste. Tipa recikliranje adresa koje su privremeno bile zauzete od lokalne varijable …a ovo je statička analiza codea, i sve što se tu desi…treba se desiti prije negoli skripte uopće stignu do browsera, ili ti do V8 enginea…

1 Like

Koliko se ja razumijem u JS u tvom drugom primjeru ti je x false i zato ti ga neće maknuti. Proguglaj malo varaible scope pa če ti biti jasnije.

Inače baš i ne koristim const deklaraciju…što to nije globalna deklaracija konstante? Hmm … lako se to provjeri, al sam sad na mobu :slight_smile:

Ne const nije globalna varijabla, var bi to bio, const je samo konstanta, znači nepromjenjiva.

A mozes li nam pokazati kako si konfigurisao UglifyJs Plugin ?

Nije false.Ako se x ne nadje u scope-u od test funkcije, JS interpreter ce nastaviti traziti x - iz unutra, prema van.

Sto se const deklaracije tice to samo znaci da ne mozes raditi re-assignment.Ako ti je konstanta neki objekat, ti i dalje mozes raditi s tim objektom sta ti je volja.

Pa jasno mi je to …ali ako je const definiran izvan scopea funkcije…onda je globalno deklariran (Tj. onoliko globalno koliki je taj scope globalan). A ako je deklariran unutar scopea funkcije, onda je lokalno deklariran unutar te funkcije.

Evo ga …

    new webpack.optimize.UglifyJsPlugin({
        beautify: false,
        mangle: {
            screw_ie8: true,
            keep_fnames: true
        },
        compress: {
            screw_ie8: true
        },
        comments: false
    })

Dodaj toplevel: true unutar compress objekta.

1 Like

Nice ako je to rješenje ;).
Probam čim za komp sjednem. :wink:

Tko bi dočekao sutra…digao si me iz kreveta xd

…ali nažalost ne djeluje …

Djeluje! :smiley:

https://skalman.github.io/UglifyJS-online/ (verzija 3.3.9., provjeri da koristiš istu)

Testirao sam ovdje, imaš dole pri dnu Options pa onda pod compress promijeni toplevel u true i trebao bi dobit /** no output */

Ali ja bi svakako izbjegavao uključivati ovu opciju

Zašto?

Prije svega zbog mog neznanja i drugačijeg pogleda na programiranje.

Kada pročitam ovaj kod:

function test(){
    if(x) return;
    console.log("ovo (ni)je maknuto by death code remover")
}

Znači samo izoliramo funkciju. Šta je X? Ne znamo. Ali zato znamo da je funkcija, u tvom primjeru, definirana u globalnom prostoru i dodana u globalni objekt (window).

Dodajemo const x = 1. Znamo da je const kao skalar nepromjenjiv, znamo da je definiran u istom scopeu, i znamo da će funkcija uvijek koristit istu vrijednost i znamo da se console.log nikad neće izvršit. Hoćeš li ikada u stvarnosti napisati takvu funkciju?

Samo hoću reći da po meni optimizacija koda treba biti onaj završni dio, da reducira kod, da reducira veličinu datoteke, a ne da briše dijelove koda koji se možda mogu koristiti iz vana.

Ti kao developer, kad se za mjesec dana vratiš u taj kod, ćeš se uvijek iznova pitati šta ta funkcija radi? Ona će ostat u dev kodu i dalje će ti smetati.

Nisam bio pazljivo procitao, moja greska

Neces vjerovati koliko takvog kod mozes pronaci u produkciji.

Ali isto tako mislim da je ovo samo bio primjer, a ne stvarni produkcijski kod.

Pa gle, ne znam ni ja jesam li odabrao ispravan pristup i ima li bolji…kad se sve može rješiti na mnogo različitih načina. …al da pojasnim koju primjenjivu svrhu vidim…

Taj kode je bio samo ogoljeni primjer da ukažem na ponašanje dead code removera…

Pa u realnom primjeru će se znati što je x. Pogotovo ako je konstanta, onda je i vrijednost istog dobro poznata. Recimo da code u praksi može biti nešto poput:

const Develop=true;
function someFunction(a,b,c){

	
	if(Develop)checkInputs(a,b,c);

	console.log("ovo je meso funkcije");

}

Znači imamo situaciju da želimo u development modeu raditi neke dodatne operacije u modulima. Tipa ugraditi neku extra analizu input / output parametara …generirati iz istoga analitiku u GUI consoli koja će biti dostupna developeru… generirati bogatiji error log za development potrebe…itd…

Svi ti extra development moduli zahtjevaju i dodatan CPU i povečavaju dependency skripti koje su potrebne da se može izvršavati ta dodatna logika.

Onog momenta kada izlazimo iz development modea i flag Develop postavljamo na false …sav taj extra CPU smo stavili na spavanje, ali ne i suvišan dependency koji se stvorio zbog tih development alata. Dok gornjim pristupom sa dead code removerom možemo i taj suvišni depedency odbaciti za određeni mode buildanja programa.

Ovo mi se čini dosta praktičnim da mogu ručno prebaciti Develop flag u false i izbildati program sa onim što je minimalno potrebno za produkcijsku verziju. Te se tako više oslobađam da razvijam dodatne development komponente, ne mareći da time povećavam nekakav “teret” konačnom proizvodu.

Bilo bi još praktičnije da se ti switchevi mogu postaviti direktno u webpack konfiguraciji, tako da ne moram prije bildanja određene verzije, ručno mijenjati stanje const flagova u codeu. (Mada je to stvarno mirezan extra zahvat postavit vrijednost flagova prije buildanja određene produkcijske verzije)

I kao što rekoh napočetku, moram priznati da nisam upoznat sa drugim mogućnostima za postizanje istoga. Ono što vidim većim nedostatkom u ovom pristupu je da onda nisam u mogućnosti u produkcijskoj verziji se logirati kao system admin i učitat web u Development modeu i da mi se sustav ponaša kao što se ponašao u developmentu. Jer tih modula onda tamo jednostavno nema.
Ali se zato može kod buildanja programa izbildati više različitih verzija …pa onda složiti server logika da isporuči development verziju za slučaj da user ima privilegiju učitati development verziju …ili koju već želi.

Opet mi jedino fali znanja kako se to može unaprijediti već na razini webpacka i konfiguracije različitih buildanih verzija.
Ono što trenutno vidim najpraktičnijim, da se za različite konfiguracije webpacka postavi drugi distribution folder …i onda se lako server natjera u koji folder će gledati kod distribucije fronted asseta.

razumijem poantu, da li je to node projekt, postoji li package.json pa da to probaš riješiti kroz neki devDependencies?

Postoji. Npm instalacija je.

Ali nisam upoznat kako bi sljedeće mogao postići sa devDependenciem ?

const Develop=true;
function someFunction(a,b,c){

	
	if(Develop)checkInputs(a,b,c);

	console.log("ovo je meso funkcije");

}

Jer valja primjetiti da je ovo situacija kada je “produkcijska funkcija” miksana sa djelovima code-a koji će raditi svoj posao samo u developmentu.

devDependecies vidim izvedivim samo kada kompletno neki modul želimo ili ne želimo imati u nekoj radnoj okolini …ali ovakav miks proširenja logike unutar neke funkcije ne znam na koji bi drugi način elegantno mogao postići. Ovo sa dead code removerom mi djeluje poprilično simpatično rješenje. :slight_smile: