revert removal of phar from vendor-bin about faker HOT 9 CLOSED

@GrahamCampbell

Because phars bin subdeps without all the other hacks that were merged after.

Can you explain, please?

I do not understand this sentence.

from faker.

The situation before was better and minimal.

from faker.

@GrahamCampbell

What exactly was better in the situation before and what exactly is worse now?

from faker.

Before we had 2 composer.json files that pinned the analyzers to their phar builds. Very simple and robust. Now we need to force resolving dependencies at 7.1.x and commit a lock file. Totally unnecessary.

from faker.

@GrahamCampbell

From https://github.com/psalm/phar:

This allows you to install Psalm without worrying about composer conflicts.

Since we require psalm/phar in its own composer.json it can not conflict with any other packages. Therefore we can easily require vimeo/psalm instead of psalm/phar.

At the end of the day, it doesn't matter.

Before we had 2 composer.json files that pinned the analyzers to their phar builds. Very simple and robust. Now we need to force resolving dependencies at 7.1.x and commit a lock file. Totally unnecessary.

Now we do not need to to anything.

Where before we either had to manually update

• phpstan/phpstan
• phpstan/phpstan-deprecation-rules
• vimeo/psalm

or continue using them in the pinned versions, we now benefit from automatic updates made by Dependabot.

from faker.

Can dependabot not automatically update pinned versions in composer.json?

from faker.

@GrahamCampbell

Can dependabot not automatically update pinned versions in composer.json?

It doesn't.

I'm sure it could - but if it did, then people would probably stop using it.

from faker.

Bummer is that it does not really support semver right so that we can just lock it on minor or patches instead

from faker.

They do, but that isn't enough. We don't want new analysis features to fail our builds. We want to control when we upgrade.

from faker.