Skoop,
@Skoop@phpc.social avatar

Is my search-fu leaving me, or is there no PHAR for Rector?

danielsiepmann,

@Skoop I guess there is none, as rector package is delivered as a shim only requiring a specific phpstan version: packagist.org/packages/rector/… So it already is like a phar shipped as composer package in some way.

Skoop,
@Skoop@phpc.social avatar

@danielsiepmann but that's the thing: we're doing a lot of upgrades right now, and dependency-issues are the biggest problem we run into. mostly issues with dependencies of dev-tools. so I was hoping to put all QA/analysis tools as PHARs to minimize those issues. Everything is a PHAR, but not rector. and that requires PHPStan again. Opening up the issues again.

danielsiepmann,

@Skoop I guess because phpstan already follows the same approach …

I don't think you will get phar from official rector: github.com/rectorphp/rector/is… I'm sorry.

heiglandreas,
@heiglandreas@phpc.social avatar

@Skoop IIRC there isn't...

Skoop,
@Skoop@phpc.social avatar

@heiglandreas then it's not just me. that is a shame, because Rector requires PHPStan, so my effort to use PHARs for the QA tools is sort of moot then

shochdoerfer,
@shochdoerfer@phpc.social avatar

@Skoop I feel you. There's always one piece of the puzzle that does not work the I want things to work which then makes my whole idea pointless /cc @heiglandreas

heiglandreas,
@heiglandreas@phpc.social avatar

@Skoop That is the "problem" with PHARs. They are great for standalone tools. But as soon as you need plugins, dependencies or whatever, you get either into a lot of trouble or .. let's not discuss the OR...

heiglandreas,
@heiglandreas@phpc.social avatar

@Skoop The biggest hinderer for PHARs is IMO the "let's just use dev-dependencies in composer" attitude...

And opinions.

heiglandreas,
@heiglandreas@phpc.social avatar

@Skoop Which is why I tend to lean more and more towards Marcos approach to use tool-specific composer.json files

sven,
@sven@phpc.social avatar

@Skoop @heiglandreas this is the way.

heiglandreas,
@heiglandreas@phpc.social avatar

@sven It shouldn't be. As it's even more complex than having to use a different tool.

But in times of developers not being capable of using 2 different tools for 2 different things it looks like it's the way people go.

It's not DRY, it's using wrong abstractiosn. But .... 🤷

/cc @Skoop

Skoop,
@Skoop@phpc.social avatar

@heiglandreas @sven Right now, I'm leaning towards using Phive to install PHPUnit, PHP CS Fixer, PHPStan. And using a separate composer.json for Rector, which may install PHPStan, but that will only be for Rector, I'd use the PHAR for actually running PHPStan.

theseer,
@theseer@phpc.social avatar

@Skoop @heiglandreas @sven Why not talk to Thomas about it? :)

If we need to enhance phive to support this, I can do that..

Skoop,
@Skoop@phpc.social avatar
theseer,
@theseer@phpc.social avatar

@Skoop @heiglandreas @sven Okay, that's a lame excuse he wrote there, tbh.

There is no need to "manually update files".

We could also consider creating a phar-io update wrapper component that allows for an easy "--self-update" process to be included.

heiglandreas,
@heiglandreas@phpc.social avatar

@theseer Opinions.... 😕

/cc @Skoop @sven

heiglandreas,
@heiglandreas@phpc.social avatar

@Skoop @sven Depending on how Rector calls PHPStan you can even use the replace config inside the composer.json to make it not install PHPStan and then use PHPStan from the tools-directory...

roughly speaking...

heiglandreas,
@heiglandreas@phpc.social avatar
  • All
  • Subscribed
  • Moderated
  • Favorites
  • random
  • DreamBathrooms
  • Durango
  • mdbf
  • magazineikmin
  • InstantRegret
  • rosin
  • modclub
  • Youngstown
  • slotface
  • thenastyranch
  • cubers
  • kavyap
  • everett
  • khanakhh
  • megavids
  • GTA5RPClips
  • osvaldo12
  • ngwrru68w68
  • normalnudes
  • cisconetworking
  • Leos
  • ethstaker
  • tester
  • tacticalgear
  • provamag3
  • anitta
  • JUstTest
  • lostlight
  • All magazines