Naja a její závislosti – jsou nutné?
- Šaman
- Člen | 2659
Ahoj @jiripudil
Při instalaci Naja přes npm
se mi stáhnou i její
závislosti:
"dependencies": {
"event-target-shim": "^2.0.0",
"object-assign": "^4.1.0",
"qwest": "^4.4.5"
},
Já je ale nikde nenačítám, nejsou přilinkované do html. Jsou opravdu nutné, nebo jak je to s nimi?
P.S. Ten qwest
si vyžádal i jeho závislosti
"dependencies": {
"jquery-param": "^0.1.2",
"pinkyswear": "^2.2.2"
},
- David Matějka
- Moderator | 6445
Jak to vkládáš do stránky? používáš nějaký webpack nebo čím builduješ bundle?
- David Matějka
- Moderator | 6445
j, tohle už je připravený bundle, takže ty závislosti nemusíš už nijak linkovat
- David Grudl
- Nette Core | 8218
To si vykopíruj do /www, dávat tam celé node_modules je obrovské bezpečnostní riziko, vůbec netušíš, co tam všechno může být.
- Šaman
- Člen | 2659
Tak jestli to tu není moc offtopic – jak je teda doporučené pracovat s frontendovými repozitáři, když jsem ohledně javascriptu BFU?
Líbilo se mi, že teď když dám npm update
, tak se mi
zaktualizují všechny knihovny.
Nelíbí se mi, že třeba Ublaboo\Datagrid
mám teď dvakrát –
jednou v Composeru pro PHP a podruhé v npm pro frontend. A může se stát,
že se ty verze budou rozcházet.
Už jen ten základ co mám je myslím lepší řešit přes npm
než ručně.
{
"name": "myProject",
"private": true,
"dependencies": {
"@fortawesome/fontawesome-free": "^5.13.0",
"bootstrap": "^4.4.1",
"bootstrap-datepicker": "^1.9.0",
"bootstrap-select": "^1.13.16",
"happy-inputs": "^2.1.0",
"jquery": "^3.5.0",
"jquery-ui-dist": "^1.12.1",
"naja": "^1.8.3",
"ublaboo-datagrid": "github:ublaboo/datagrid"
}
}
Plus nette.forms.js
, které mám jinde.
Na produkci se při nasazení spustí composer install
, ale
žádný npm install
, takže node_modules
mám
verzovaný.
Mám to tedy:
- stahovat ručně (tak jsem to dělal doteď)
- na úrovni
/www
mítnode_modules
a spravovat to přesnpm
(tak to mám teď) - mít nějaký neverzovaný adresář pro
npm
a do/www
si zkopírovat jen/dist
adresáře z těch repozitářů? - dělat úplně jinak?
Díky.
Editoval Šaman (30. 4. 2020 18:41)
- Toanir
- Člen | 57
node_modules určo verzovat nechceš. S frontendovýma záležitostma si hraju pomocí Gulp (dá se použít i Grunt) a řeším to zatím že si pomocí gulp-copy naivně nechám do www/vendor nakopírovat dist složky frotnendových závislostí.
Tímhle způsobem můžeš právě podchytit ty dvojí repozitáře, prostě udáš cestu k datagrid.js v composerovým vendoru.
Zároveň když si zrovna hraju se SASS, používám gulp-sass na buildění do www/dist. Není to žádná extra raketová věda ale jsem s tím zatím spokojený páč si připadám, že to mám pod kontrolou.
Ve výsledku bys měl mít vedle composer.json zároveň package.json (případně nějaký lock soubor) a vedne vendor/ node_modules/. Potom přes nějaký nějaký tool, třeba gulp anebo vlastní symfony/console příkaz, zkopíruješ do www jen to, co tam skutečně chceš.
Editoval Toanir (30. 4. 2020 19:14)
- CZechBoY
- Člen | 3608
Použij radši nějakej bundlovač, kterej za tebe vyřeší i závislosti závislostí atd. např. webpack/parcel/rollup a další, je jich spousta a já používám jen webpack tak ostatní neznám :D
ps. to že má php knihovna na packagistu i assety je spíš výjimka a pomocná ruka vývojářů než nějaká běžná praxe. Pro contributte/datagrid existuje balíček na npm https://www.npmjs.com/…boo-datagrid.
Editoval CZechBoY (30. 4. 2020 19:33)
- Pavel Janda
- Člen | 977
@CZechBoY Úplný souhlas.
A nebo (pokud to není velký projekt a potřebuješ to vyřešit rychle), klidně využij CDNky jednotlivých knihoven. Viz například https://github.com/…layout.latte.
- d@rkWolf
- Člen | 167
Tak tohle mě taky zajímalo, jednou jsem to NPM zkusil, výsledek byl obří balík dat stažený kdesi v user profilu, u projektu složka node_modules(opět plná bordelu-já prostě nechci obří několik desítek mega velký balík vývojových dat jQuery, mě stačí aktuální jquery.xyz.min.js a to je vše) a pak to šlo všecko z disku a vrátil sem se ke starému dobrému systému=vše co je na rychlých CDNkách linkuju přímo z nich(s http/2 a cache v prohlížečích je skoro jistý, že už návštěvník většinu bude mít stejně v cache), zbytek, kterýho už nebejvá moc pak nalinkuju ručně v minified stavu a dolinkuju jeden svůj konfigurační.
Dřív sem různě řešil ještě spojování do jednoho, dnes s http/2 zbytečné, lepší mít samostatné soubory, co už skoro jistě budou mít lidi v cache, než je nechat stahovat obří balík, jedinečný, takže ho budou stahovat zaručeně.
Teďka teda v aktuálním projektu trochu laboruju s Webloaderem, ten je teda taky určenej spíš na ten starý způsob se spojováním souborů, ale můžu si tam dát a nechat spojit/minifikovat jen věci, co minifikované nejsou a zároveň mi to kompiluje scss soubory a výsledek cache-busteruje novým názvem. Vyžaduje to sice vypsat všechny soubory do configu Webloaderu, ale co už(automatické načítání ze složky je u js použitelné jen při spojení do jednoho, nebo bych musel soubory číslovat aby byly správně seřazené, u scss stačí zadat rootovej soubor, includy si kompilátor najde sám).
Naprosto nesnáším, když se mi stahují hromady souborů co nechci. Teď koukám, že mám ve Vendoru přes 80MB, wtf…asi 30 je phpstan, co ani nevím, co je a kde se to tam vzalo.
- Marek Bartoš
- Nette Blogger | 1263
vše co je na rychlých CDNkách linkuju přímo z nich(s http/2 a cache v prohlížečích je skoro jistý, že už návštěvník většinu bude mít stejně v cache
Na to bych moc nespoléhal, prohlížeče momentálně implementují double-key cache, která blokuje sdílení cache souborů napříč doménami https://www.chromestatus.com/…299309072384
- d@rkWolf
- Člen | 167
@CZechBoY ???
@Mabar píšou tam o resource-není problém a subresource-je problém, ale nějak jsem z toho nepoznal, co je resource a co subresource. Z logiky věci mi přijde, že při tom, kdy jsou cdn masově rozšířené a podporované, že by to mělo být promyšleno tak, aby se s nima počítalo. Ale i kdyby ne, furt mi v pohodě vyhovuje loadnutí 5 minifikovaných scriptů z CDN a jeden lokální.
- Pavel Kravčík
- Člen | 1195
@darkWolf: Ten velký balík máš jen pro vývoj, jak někdo radil výše – to zařídí bundlovač. Ten Ti mimifikuje jen potřebné soubory a výsledek má třeba 80kB i přestože mají celé node_modules 200MB. It's magic. Vše máš aktuální, bezpečné, rychlé.
S composerem si samozřejmě může hrát a samozřejmostí bylo mělo být něco jako „–no-dev“, když pouštíš na produkci. To Tě PHPStan a podobných věcí zbaví, ale v základu je samozřejmě na dev prostředí chceš nebo alespoń autoři balíčků kvůli testům a spolehlivost.
- d@rkWolf
- Člen | 167
@PavelKravčík ale to já chápu, ale já ten 200MB node_modules na disku nechci, já bych to využil, kdyby to mělo parametr, kterým můžu říct, že chci akorát aktuální distribution files, třeba jquery.min.js, nebo slick.min.js a slick.min.css pro slick carousel, to je všecko co potřebuju, další desítky mega bordelu nechci, nikde, ani na vývoji, ani na provozu, protože mi na nic nejsou, je to mrhání datovým prostorem, momentálně je to teda jedno, protože radši stejně připojím linky na CDN, takže mi zbyly jen assety k ublaboo datagridu co minifikovaný nejsou, ty si nalinkuju do webloaderu a až chci, zapnu sloučení a minifikaci a webloader mi to hodí do jednoho css/js. A nemusím mít na disku stovky mega node_bordelu. Composer na produkci nespouštím, protože tam, kam dáváme weby podobný věci jako spouštět composer nejde. Na provoz jdou soubory Filezillou…
- Pavel Kravčík
- Člen | 1195
@darkWolf: Chápu tvůj postoj, viděl jsem to dříve stejně. Na jednoduché weby je to ultimátní a pohodlné řešení. Dříve či později Tě to stejně nemine. ;)
Určitě to apriori nezavrhuj a zkus začít třeba nějaký FTP auto-deployem místo Fillezilly.
- Mysteria
- Člen | 797
d@rkWolf: A čemu konkrétně to vůbec vadí? Je rok 2020, SDD disky s kapacitou 1TB jsou běžnou realitou, 100Mbit/s přípojky taktéž. Aplikace se deployují pomocí docker image (což je teprve plýtvání daty, když i kvůli změně jednoho souboru musím přenést třeba 200MB docker image).
Editoval Mysteria (8. 6. 2020 19:56)
- David Grudl
- Nette Core | 8218
d@rkWolf napsal(a):
ale to já chápu, ale já ten 200MB node_modules na disku nechci
Tohle naprosto chápu, ekosystém kolem JavaScriptu je šílenej, jenže v tuto chvíli je nejrozumnější to prostě překousnout a věřit v lepší budoucnost.
Zlatý PHP, jako fakt…