Jak spolehlivě odinstalovat PHPstan z projektu ??
- m.brecher
- Generous Backer | 863
Ahoj,
nainstaloval jsem si do projektu PHPstan, ale nakonec jsem ho nepoužíval a na produkční server jsem ho nahrávat nechtěl. Sice v composer.json nejsou žádné odkazy na PHPStan:
{
"name": "my/skeleton",
"description": "Starting Skeleton for Nette Web Project",
"keywords": ["nette"],
"type": "project",
"license": ["MIT", "BSD-3-Clause", "GPL-2.0", "GPL-3.0"],
"require": {
"php": ">= 8.1",
"nette/application": "^3.1",
"nette/bootstrap": "^3.2",
"nette/caching": "^3.2",
"nette/database": "^3.1",
"nette/di": "^3.1",
"nette/forms": "^3.1",
"nette/http": "^3.2",
"nette/mail": "^4.0",
"nette/robot-loader": "^4.0",
"nette/security": "^3.1",
"nette/utils": "^4.0",
"latte/latte": "^3.0",
"tracy/tracy": "^2.9"
},
"require-dev": {
"nette/tester": "^2.4",
"symfony/thanks": "^1",
"phpstan/phpstan-nette": "^1.2"
},
"autoload": {
"psr-4": {
"App\\": "app"
}
},
"minimum-stability": "stable",
"config": {
"allow-plugins": {
"symfony/thanks": true
}
}
}
Jenže v composer.lock jsou na phpstan/phpstan nebo phpstan/phpstan-nette desítky odkazů. Takže když jsem /vendor/phpstan na server nenahrál, tak to logicky vyhazovalo výjimku:
Failed opening required '/var/www/hosting/domain.cz/vendor/composer/../phpstan/phpstan/bootstrap.php'
Zkoušel jsem phpstan odstranit composerem, ale neuspěl jsem. Jaký je nejspolehlivější způsob jak mít instalaci knihoven čistou bez phpstanu ??
Pomohlo by smazat celou složku /vendor + composer.lock a podle composer.json vše nainstalovat z čisté vody ?? Šlo by to tak ??
project>composer install
Díky předem za rady a komentáře.
- nightfish
- Člen | 516
m.brecher napsal(a):
Sice v composer.json nejsou žádné odkazy na PHPStan… Jenže v composer.lock jsou na phpstan/phpstan nebo phpstan/phpstan-nette desítky odkazů.
Máš tam phpstan/phpstan-nette, který vyžaduje
phpstan/phpstan.
Zkoušel jsem phpstan odstranit composerem, ale neuspěl jsem.
Co jsi udělal? Co se stalo? Byla nějaká chybová hláška?
Jaký je nejspolehlivější způsob jak mít instalaci knihoven čistou bez phpstanu ??
composer remove phpstan/*
Pomohlo by smazat celou složku /vendor + composer.lock a podle composer.json vše nainstalovat z čisté vody ?? Šlo by to tak ??
Když smažeš composer.lock, tak pak
composer install nemá podle čeho nainstalovat balíčky. V
composer.json jsou většinou jen rozsahy povolených verzí a ne
konkrétní verze, co se mají nainstalovat. Takže když už smazat
vendor a composer.lock, tak pak spustit
composer update.
Jinak ještě na závěr: při vystavování projektu na
testovací/produkční server spouštím composer install --no-dev,
což mi odinstaluje všechny vývojové závislosti (PHPStany, PHPUnity, CS
atd.), takže se mi na produkci dostane jen čistá aplikace se svými
závislostmi.
- m.brecher
- Generous Backer | 863
@nightfish
Díky za vysvětlení, je to malý projektík, kde PHPstan nemá smysl. Proto ho chci odstranit úplně. Vývoj většího projektu obvykle vypadá tak, že se opakovaně cca jednou týdně deployne na testovací server co se zrovna udělalo, a testuje se průběžně pořád. Pak je asi lepší se smířit s tím, že se na testovací/produkční server nahrajou vývojové nástroje, které tam nejsou potřeba.
A co jednoduše composer.lock na testovací/produkční server NEDEPLOYNOUT – máš s tím nějaké zkušenosti ?? Závislosti balíčků zkontroluje composer na vývojovém PC a testovací/produkční server má věrnou kopii.
Editoval m.brecher (6. 7. 2023 23:20)
- Marek Bartoš
- Nette Blogger | 1260
malý projektík, kde PHPstan nemá smysl
Na každém projektu má smysl.
Pak je asi lepší se smířit s tím, že se na testovací/produkční server nahrajou vývojové nástroje, které tam nejsou potřeba
Od toho se vývojové nástroje při jejich instalaci přidávají
s přepínačem --dev, tj.
composer require --dev phpstan/phpstan. V deploy scriptu pak
spouštíš composer install --no-dev, který dev závislosti
nenainstaluje.
A co jednoduše composer.lock na testovací/produkční server NEDEPLOYNOUT – máš s tím nějaké zkušenosti ?? Závislosti balíčků zkontroluje composer na vývojovém PC a testovací/produkční server má věrnou kopii.
composer.lock je právě to, co ti má zajistit, že se ti
všude nainstaluje přesně ta samá verze závislostí. Když ho nemáš, tak
se ti nainstalují nejnovější možné závislosti a v některých
případech se ti mohou nainstalovat i starší, než se kterými jsi
testoval.
- nightfish
- Člen | 516
m.brecher napsal(a):
… Proto ho chci odstranit úplně.
To jsem pochopil. Odstranění balíčku phpstan/phpstan-nette
z dev závislostí
(composer remove --dev phpstan/phpstan-nette) nepomohlo?
Vývoj většího projektu obvykle vypadá tak, že se opakovaně cca jednou týdně deployne na testovací server co se zrovna udělalo, a testuje se průběžně pořád. Pak je asi lepší se smířit s tím, že se na testovací/produkční server nahrajou vývojové nástroje, které tam nejsou potřeba.
Proč? Vždyť odinstalování dev závislostí je otázka dvou
příkazů navíc v deployovacím skriptu
(composer install --no-dev před deployem,
composer install po deployi pro opětovnou instalaci dev
závislostí). A ne, projektík, který vystavuješ jednou týdně, není tak
malý, abys na něm neměl deployovací skript.
A co jednoduše composer.lock na testovací/produkční server NEDEPLOYNOUT – máš s tím nějaké zkušenosti ?? Závislosti balíčků zkontroluje composer na vývojovém PC a testovací/produkční server má věrnou kopii.
Na testovacím/produkčním serveru composer nespouštím, takže na nich
composer.lock nepotřebuji, proto tento soubor nedeployuji.
Předpokládá to ovšem, že na vývojovém, testovacím i produkčním
serveru jsou opravdu shodná prostředí.
- m.brecher
- Generous Backer | 863
@nightfish
Díky za skvělé rady, včera jsem /vendor a composer.lock smazal, znovu nainstaloval a updatoval a je to OK. Předtím se mě nepovedlo odinstalovat phpstan korektně, protože jsem nezadal správně příkaz do composeru.
Na testovacím/produkčním serveru composer nespouštím, takže na nich composer.lock nepotřebuji, proto tento soubor nedeployuji. Předpokládá to ovšem, že na vývojovém, testovacím i produkčním serveru jsou opravdu shodná prostředí.
Doma mám Windows, venku Linux, stejné prostředí tedy nemám, ale hlídám si MINIMÁLNÍ společnou desetinkovou verzi php (uvedena v composer.json) + aby celý /vendor byl 100% nakopírován na testovací/produkční server. Potom bych composer.lock mohl i na produkci smazat, ale zatím jsem to nedělal, protože mě to až do včerejška nečinilo žádné potíže.
- dms
- Člen | 93
Moc si to komplikuješ a já jedu ty věci takto:
- i na windows můžeš mít v dockeru linux server (ale nejjednodušší je prostě mít linux na vývoj a neřešit pak bugy WSLka)
- compoer.json a composer.lock je dobré mít v gitu
- automatické CI by se mělo za tebe vždy starat o instalaci vendoru bez dev závislostí a nahrát soubory na server
Pokud nemáš docker, linux a ci testy + ci deploy tak je celý proces vývoje, testování a nahrávání na server strašně zdlouhavý a často chybový.