Proces minifikace souborů (CSS, JS) - jak na to?

Aby existoval jen jeden seznam souborů je asi nereálné. Ať si to ujasníme. Ty si představuješ, že při commitu se tvoje javascripty a csska zminifikují a v repozitáři budou jen zminifikované verze? Jak v tom pak budeš dělat úpravy?

Buildované soubory nepatří do repozitáře. Vývojáři pracují s nezbuildovanými soubory a build provádí až deploy server (stačí ta nejlevnější VPS cca za 100 Kč/měs) po pushnutí do deploy větve.

CSS není problém, máš jeden soubor s @import příkazy, který používáš jak pro vývoj, tak pro build. Trochu problém může být s JS, tam ty soubory píšeš na dvě místa (do šablony a do gruntfile). Řešením by mohlo být místo grunt-contrib-uglify používat grunt-contrib-requirejs, u toho snad není potřeba soubory vyjmenovávat, stačí zadat složku. Ale nevím, nějak hlouběji jsem se tím nezabýval.

loyza:
„Ty si představuješ, že při commitu se tvoje javascripty a csska zminifikují a v repozitáři budou jen zminifikované verze? Jak v tom pak budeš dělat úpravy?“
Ne, on si představuje, že v šabloně bude nějaký "if produkce/else vývoj", přičemž tu produkci mu bude generovat nějaký nástroj. To je správný způsob, až na to, že je blbost, aby si to pouštěl každý sám a commitoval výsledek. Pokud na projektu dělá víc lidí, tak to vede ke kolizím v těch buildovaných souborech a všichni to musí pořád dokola řešit.

joe:
„Co myslíš tím deploy serverem a deploy větví?“
Deploy větev, my jí máme pojmenovanou production, je větev, podle které se automaticky aktualizují soubory webu. Udělá se rebase z master na production, pushne se výsledek a web je aktulizován. Máme na to nastavené i mazání tempu apod., ručně jen aktualizuji změny v databázi.

Také mám nyní na stole vyřešení problému s css a js. Stavím na řešení volání jediného css a js souboru. Do toho jsou includovány jednotlivé soubory, věřím, že bych je dokázal minifikovat, i když to zatím nedělám. Nyní hledám nějaký elegantní způsob, jak automatizovat zvýšení verze u načítání scriptu, např. script.js?v=102, když dojde ke změně některého z includovaných souborů.

Alphard:
proč ji potřebuješ zvyšovat?
Kvůli informaci o verzi nebo keši v prohlížeči?

Kcko:
Kvůli cache.

Alphard:
Tak na to stačí jednoduché soubor?zmena=<?= filemtime("soubor"); ?> ne?

Děkuji za návrhy, podobný princip byla první byla první věc, co mě napadla; nyní to tak mám, pouze tam přes vlastní funkci procházím seznam souborů. Byl bych ale radši, kdyby se to během deploye upravilo fixně, nyní si hraji s náhradou něčeho jako @JS_VERSION@. Ve volných chvílích to postupně vylepšuji, zrovna tohle mě teď moc netíží, jen jsem to zmínil, že joe založil tohle vlákno.

Pokud jde o opravu překlepů, nejsou zas tak časté a ten výsledný soubor není zas tak velký (ve srovnání s pár obrázky), takže to neřeším.

Jde-li o chyby při minifikaci, nemám zkušenosti, ale co třeba hned při commitu zkusit provést (a výsledek zahodit)? Když to projde, je to ok a půjde to i později.

joe:
„Co myslíš tím deploy serverem a deploy větví?“
Deploy server je prostě VPS, která někde pořád běží a ve chvíli, kdy někdo provede push do deploy větve v centrálním repozitáři, tak spustí deployment.

Na té VPS máme nainstalovaný Gitlab CI, který spustí nějaký náš skript. Výstup toho skriptu je dostupný přes webové rozhranní, spolu s informací o tom, jestli neskončil chybou (podle exit kódu). Ten skript projede testy, vytvoří buildy JS a CSS a když všechno dobře dopadne, tak aktualizuje produkční server - přenese změněné soubory z repozitáře (podle diffu mezi aktuálním a naposledy deployovaným commitem), přenese nově zbuildované soubory a smaže temp. Ještě to nemáme úplně vychytané, ale v principu to tak funguje. Pokud něco selže, ať už testy, nebo grunt, tak proces nedoběhne, na produkci zůstane stará verze a v rozhranní Gitlab CI uvidíme, co se stalo.

„A na vývojovém stroji, jak rozhodnu, že budu načítat neminifikované verze?“
To se detekuje v PHP, v šablonách pak máme něco jako {if $productionMode}...{else}...{/if}.

„A proč ne i s CSS? Nechci hromadu souborů CSS, chci třeba skupinku CSS - opět dva seznamy.“
Tohle moc nechápu. Naše řešení je, že při vývoji máme hromadu souborů načítaných přes @import v nějakém index.css, na produkci je jeden CSS soubor vytvořený kompilací toho index.css (resp. index.less).

> „Stavím na řešení volání jediného css a js souboru.“
> To mi nepřijde správné, protože když includuješ třeba 30 JS souborů a a třeba jen opravíš překlep, proč budeš nutit všechny, aby si stáhli celý balík souborů znovu? To je zbytečné.
Díky minifikaci ten soubor nebude nijak velký a pokud jde o výkon, tak je podstatnější počet requestů, než celková velikost stahovaných dat.

[#9] joe - Proc? Prozen kod programem, ktery ti tam prislusne znacky doplni nebo upozorni na mozne problemy. Pripadne total commander ma moznost vyznacit zmeny v souboru proti jinemu souboru.

Mam to řešené tak, že se minifikovaná verze (js, css i html) udělá až při odesílání ke klientovi. Tedy fyzicky jsou soubory neminifikované.

joe:
Soubory jsou samozřejmě cachované, všechny js i css mají tvar main-1375609130.css. Čili commitem se změni timestamp a uživatelé si stáhnou nový soubor. Provozuji to takto 2 roky a zatím k žádné chybě nedošlo.

joe:
„To je právě i to, o co mi šlo - takže máš dva seznamy. Už předvídám ty chyby, že se načítání souboru připíše na neprodukční verzi, ale po pushnutí na serveru nic nepřibyde (zapomene se na úpravu gruntfile). Líbilo by se mi to mít sjednocené a seznam mít jen jeden. Asi by šlo i nějak nechat generovat gruntfile.“
U CSS máme jeden seznam - index.less. Ten slouží jednak jako jediný stylopis, který načítám při vývoji (a kompiluje se v prohlížeči, což při vývoji tolik nevadí) a zároveň slouží jako ten seznam pro kompilaci (resp. v Gruntfile mám v seznamu pouze tento jeden soubor, ostatní se najdou přes @import).

Dva seznamy máme u JS a ten problém si uvědomuji. Není to ale primárně můj problém, je to problém frontendistů... Dá se to řešit podobně, jako u CSS, na vývoji načítat pouze jeden skript, který bude zároveň sloužit jako "seznam" pro kompilaci.

„Myslíš, že tedy bude lepší minifikovat vše dohromady a nějaké balíky souborů (skupinky souborů) neřešit? I v případě, že třeba je web dost navštěvovaný?“
Přesně tak. Dělá to tak i Seznam, Gmail, Google Docs...