Jak spolehlivě odinstalovat PHPstan z projektu ??

m.brecher
Generous Backer | 775
+
0
-

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 | 475
+
+2
-

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 | 775
+
0
-

@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 | 1186
+
+1
-

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 | 475
+
0
-

m.brecher napsal(a):
… Proto ho chci odstranit úplně.

To jsem pochopil. Odstranění balíčku phpstan/phpstan-nettedev 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 | 775
+
0
-

@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 | 88
+
+1
-

Moc si to komplikuješ a já jedu ty věci takto:

  1. 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)
  2. compoer.json a composer.lock je dobré mít v gitu
  3. 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ý.