Closed leoloso closed 3 years ago
tl;dr;
Just to clarify, the goal is to make https://github.com/rectorphp/rector/pull/4370 Whatever automated steps it takes.
The final PHP 7.1 version would be released in own tag or split repository, like rector-prefixed is
E.g. as rector-downgraded
@TomasVotruba I had an idea
So far I said that we could either always run the downgrade on the whole vendor/
folder for convenience, or manually find out which packages require PHP 7.2+ and downgrade only those.
But there's a better option: we could have a CLI script find out which are the packages needing PHP 7.2, 7.3 and 7.4, and we then integrate it into the CI, so it only downgrades those folders and only with the required downgrade set.
Something similar to compose check-platform-reqs
(source code here):
For instance, we could execute something like rector analyze-packages-to-downgrade vendor/ --php-version=7.2
and same for 7.3
and 7.4
. Then we capture this output and feed it into the next process: rector process ${LIST_OF_PHP72_FOLDERS} --set=DOWNGRADE_PHP72
.
Doing this, you can run DOWNGRADE_PHP74
only on those packages requiring PHP 7.4, but not the ones requiring 7.3 and 7.2, so it will take the minimum possible time. And the 2nd process can be a multitude of rector process
commands, possibly 1 command per downgrade set per package, so you get a failure as soon as possible.
What do you think?
Oh, actually we can use composer why-not
!
$ composer why-not php 7.3
$ composer why-not php 7.2
$ composer why-not php 7.1
Then we grep
the output to get those packages
The PATCH version must also be included. Doing:
composer why-not php 7.2
includes result:
symfony/cache-contracts v2.2.0 requires php (>=7.2.5)
So must do:
$ composer why-not php 7.3.23
$ composer why-not php 7.2.34
$ composer why-not php 7.1.33
Or better, this also works:
$ composer why-not php 7.3.*
$ composer why-not php 7.2.*
$ composer why-not php 7.1.*
For instance, doing composer why-not php 7.2.*
, I get:
graphql-api/graphql-api - requires php (~7.4)
getpop/access-control 1.0.x-dev requires php (~7.4)
getpop/api 1.0.x-dev requires php (~7.4)
getpop/api-clients 1.0.x-dev requires php (~7.4)
getpop/api-endpoints 1.0.x-dev requires php (~7.4)
getpop/api-endpoints-for-wp 1.0.x-dev requires php (~7.4)
getpop/api-graphql 1.0.x-dev requires php (~7.4)
getpop/api-mirrorquery 1.0.x-dev requires php (~7.4)
getpop/cache-control 1.0.x-dev requires php (~7.4)
getpop/component-model 1.0.x-dev requires php (~7.4)
getpop/definitions 1.0.x-dev requires php (~7.4)
getpop/engine 1.0.x-dev requires php (~7.4)
getpop/engine-wp 1.0.x-dev requires php (~7.4)
getpop/field-query 1.0.x-dev requires php (~7.4)
getpop/guzzle-helpers 1.0.x-dev requires php (~7.4)
getpop/hooks 1.0.x-dev requires php (~7.4)
getpop/hooks-wp 1.0.x-dev requires php (~7.4)
getpop/loosecontracts 1.0.x-dev requires php (~7.4)
getpop/mandatory-directives-by-configuration 1.0.x-dev requires php (~7.4)
getpop/modulerouting 1.0.x-dev requires php (~7.4)
getpop/query-parsing 1.0.x-dev requires php (~7.4)
getpop/root 1.0.x-dev requires php (~7.4)
getpop/routing 1.0.x-dev requires php (~7.4)
getpop/routing-wp 1.0.x-dev requires php (~7.4)
getpop/translation 1.0.x-dev requires php (~7.4)
getpop/translation-wp 1.0.x-dev requires php (~7.4)
graphql-by-pop/graphql-clients-for-wp 1.0.x-dev requires php (~7.4)
graphql-by-pop/graphql-endpoint-for-wp 1.0.x-dev requires php (~7.4)
graphql-by-pop/graphql-query 1.0.x-dev requires php (~7.4)
graphql-by-pop/graphql-request 1.0.x-dev requires php (~7.4)
graphql-by-pop/graphql-server 1.0.x-dev requires php (~7.4)
phpunit/php-code-coverage 9.2.0 requires php (>=7.3)
phpunit/php-file-iterator 3.0.5 requires php (>=7.3)
phpunit/php-invoker 3.1.1 requires php (>=7.3)
phpunit/php-text-template 2.0.3 requires php (>=7.3)
phpunit/php-timer 5.0.2 requires php (>=7.3)
phpunit/phpunit 9.4.1 requires php (>=7.3)
pop-schema/basic-directives 1.0.x-dev requires php (~7.4)
pop-schema/commentmeta 1.0.x-dev requires php (~7.4)
pop-schema/commentmeta-wp 1.0.x-dev requires php (~7.4)
pop-schema/comments 1.0.x-dev requires php (~7.4)
pop-schema/comments-wp 1.0.x-dev requires php (~7.4)
pop-schema/custompostmedia 1.0.x-dev requires php (~7.4)
pop-schema/custompostmedia-wp 1.0.x-dev requires php (~7.4)
pop-schema/custompostmeta 1.0.x-dev requires php (~7.4)
pop-schema/custompostmeta-wp 1.0.x-dev requires php (~7.4)
pop-schema/customposts 1.0.x-dev requires php (~7.4)
pop-schema/customposts-wp 1.0.x-dev requires php (~7.4)
pop-schema/generic-customposts 1.0.x-dev requires php (~7.4)
pop-schema/media 1.0.x-dev requires php (~7.4)
pop-schema/media-wp 1.0.x-dev requires php (~7.4)
pop-schema/meta 1.0.x-dev requires php (~7.4)
pop-schema/metaquery 1.0.x-dev requires php (~7.4)
pop-schema/metaquery-wp 1.0.x-dev requires php (~7.4)
pop-schema/pages 1.0.x-dev requires php (~7.4)
pop-schema/pages-wp 1.0.x-dev requires php (~7.4)
pop-schema/post-tags 1.0.x-dev requires php (~7.4)
pop-schema/post-tags-wp 1.0.x-dev requires php (~7.4)
pop-schema/posts 1.0.x-dev requires php (~7.4)
pop-schema/posts-wp 1.0.x-dev requires php (~7.4)
pop-schema/queriedobject 1.0.x-dev requires php (~7.4)
pop-schema/queriedobject-wp 1.0.x-dev requires php (~7.4)
pop-schema/schema-commons 1.0.x-dev requires php (~7.4)
pop-schema/tags 1.0.x-dev requires php (~7.4)
pop-schema/tags-wp 1.0.x-dev requires php (~7.4)
pop-schema/taxonomies 1.0.x-dev requires php (~7.4)
pop-schema/taxonomies-wp 1.0.x-dev requires php (~7.4)
pop-schema/taxonomymeta 1.0.x-dev requires php (~7.4)
pop-schema/taxonomymeta-wp 1.0.x-dev requires php (~7.4)
pop-schema/taxonomyquery 1.0.x-dev requires php (~7.4)
pop-schema/taxonomyquery-wp 1.0.x-dev requires php (~7.4)
pop-schema/user-roles 1.0.x-dev requires php (~7.4)
pop-schema/user-roles-access-control 1.0.x-dev requires php (~7.4)
pop-schema/user-roles-wp 1.0.x-dev requires php (~7.4)
pop-schema/user-state 1.0.x-dev requires php (~7.4)
pop-schema/user-state-access-control 1.0.x-dev requires php (~7.4)
pop-schema/user-state-wp 1.0.x-dev requires php (~7.4)
pop-schema/usermeta 1.0.x-dev requires php (~7.4)
pop-schema/usermeta-wp 1.0.x-dev requires php (~7.4)
pop-schema/users 1.0.x-dev requires php (~7.4)
pop-schema/users-wp 1.0.x-dev requires php (~7.4)
sebastian/cli-parser 1.0.1 requires php (>=7.3)
sebastian/code-unit 1.0.7 requires php (>=7.3)
sebastian/code-unit-reverse-lookup 2.0.3 requires php (>=7.3)
sebastian/comparator 4.0.5 requires php (>=7.3)
sebastian/complexity 2.0.1 requires php (>=7.3)
sebastian/diff 4.0.3 requires php (>=7.3)
sebastian/environment 5.1.3 requires php (>=7.3)
sebastian/exporter 4.0.3 requires php (>=7.3)
sebastian/global-state 5.0.1 requires php (>=7.3)
sebastian/lines-of-code 1.0.1 requires php (>=7.3)
sebastian/object-enumerator 4.0.3 requires php (>=7.3)
sebastian/object-reflector 2.0.3 requires php (>=7.3)
sebastian/recursion-context 4.0.3 requires php (>=7.3)
sebastian/resource-operations 3.0.3 requires php (>=7.3)
sebastian/type 2.3.0 requires php (>=7.3)
sebastian/version 3.0.2 requires php (>=7.3)
Combined with grep -o
on any word containing "/"
:
composer why-not php 7.2.* | grep -o "\S*\/\S*"
I get the packages!
graphql-api/graphql-api
getpop/access-control
getpop/api
getpop/api-clients
getpop/api-endpoints
getpop/api-endpoints-for-wp
getpop/api-graphql
getpop/api-mirrorquery
getpop/cache-control
getpop/component-model
getpop/definitions
getpop/engine
getpop/engine-wp
getpop/field-query
getpop/guzzle-helpers
getpop/hooks
getpop/hooks-wp
getpop/loosecontracts
getpop/mandatory-directives-by-configuration
getpop/modulerouting
getpop/query-parsing
getpop/root
getpop/routing
getpop/routing-wp
getpop/translation
getpop/translation-wp
graphql-by-pop/graphql-clients-for-wp
graphql-by-pop/graphql-endpoint-for-wp
graphql-by-pop/graphql-query
graphql-by-pop/graphql-request
graphql-by-pop/graphql-server
phpunit/php-code-coverage
phpunit/php-file-iterator
phpunit/php-invoker
phpunit/php-text-template
phpunit/php-timer
phpunit/phpunit
pop-schema/basic-directives
pop-schema/commentmeta
pop-schema/commentmeta-wp
pop-schema/comments
pop-schema/comments-wp
pop-schema/custompostmedia
pop-schema/custompostmedia-wp
pop-schema/custompostmeta
pop-schema/custompostmeta-wp
pop-schema/customposts
pop-schema/customposts-wp
pop-schema/generic-customposts
pop-schema/media
pop-schema/media-wp
pop-schema/meta
pop-schema/metaquery
pop-schema/metaquery-wp
pop-schema/pages
pop-schema/pages-wp
pop-schema/post-tags
pop-schema/post-tags-wp
pop-schema/posts
pop-schema/posts-wp
pop-schema/queriedobject
pop-schema/queriedobject-wp
pop-schema/schema-commons
pop-schema/tags
pop-schema/tags-wp
pop-schema/taxonomies
pop-schema/taxonomies-wp
pop-schema/taxonomymeta
pop-schema/taxonomymeta-wp
pop-schema/taxonomyquery
pop-schema/taxonomyquery-wp
pop-schema/user-roles
pop-schema/user-roles-access-control
pop-schema/user-roles-wp
pop-schema/user-state
pop-schema/user-state-access-control
pop-schema/user-state-wp
pop-schema/usermeta
pop-schema/usermeta-wp
pop-schema/users
pop-schema/users-wp
sebastian/cli-parser
sebastian/code-unit
sebastian/code-unit-reverse-lookup
sebastian/comparator
sebastian/complexity
sebastian/diff
sebastian/environment
sebastian/exporter
sebastian/global-state
sebastian/lines-of-code
sebastian/object-enumerator
sebastian/object-reflector
sebastian/recursion-context
sebastian/resource-operations
sebastian/type
sebastian/version
The package can be installed under a custom folder, so that sebastian/version
is not found under vendor/sebastian/version
.
So then, we can run composer info package-name --path
to find out where it's located:
composer info sebastian/version --path
This returns:
sebastian/version /user/Temporary/graphql-api-php71/vendor/sebastian/version
And we obtain the path like this:
composer info sebastian/version --path | sed "s/sebastian\/version //"
Which returns:
/user/Temporary/graphql-api-php71/vendor/sebastian/version
This approach takes a bit of time though! Each time we run composer info
it takes a few seconds... Is there any way to speed it up?
Sounds good.
Please put that in the CI script.
Resolved in https://github.com/rectorphp/rector/pull/4447
Feature Request
Make Rector be able to run on PHP 7.1, by applying the Rector downgrade rules on itself.
Objective
Rector's source code must not be modified, so the experimental PR (#4370) will not work, and is not meant to work. Instead, the downgrade must be applied on the CI process to produce an additional asset (maybe a
.zip
file?): "Rector on PHP 7.1"Question: how will users access, install and execute this asset?
Status
I have Rector already working on PHP 7.1 in my computer:
I'll describe what I've done so far.
Running a PHP 7.1 environment
I'm using Lando to spin an environment running PHP 7.1 up, and install a sample project. I can access the project files from both the Lando environment on PHP 7.1, and from my terminal on PHP 7.4.
Steps
All dependencies for production must be downgraded to 7.1. Dependencies for development, we don't need to bother about them, because the new "Rector in PHP 7.1" asset is generated for production: even if the developers are, themselves, using Rector on the development mode, the installed dependency from Rector will be the production one. This simplifies the task of having to make sure that all 3rd party dependencies can be downgraded.
I checked what 3rd-party dependencies need PHP 7.2 or above, by going to
vendor/rector/rector
(installed as a dependency in my project), runningcomposer install --no-dev
on PHP 7.4, and thencomposer why php
. The list of packages on PHP 7.2 or above is this one:So I downgraded all of them to 7.1, by running Rector on PHP 7.4 with
rector.php
:Can exclude the
tests
folders, since we don't care about them (this is only for prod), and also must exclude/vendor/rector/rector/packages/rector-generator/templates/*
or it throws errors. The others are for enhancement.The downgrade went well. I got 4 errors, which I've ignored for the time being and should be dealt with:
Having Rector downgraded to PHP 7.1, I switched to the Lando environment.
I modified the php constraint on Rector's
composer.json
to"^7.1 || ^8.0"
, or running Rector would throw an error.I also fixed an issue with migrify (https://github.com/migrify/migrify/pull/194), or it would an error (that PR must still be merged... for the time being, I applied the change manually under
vendor
to test it)After that, Rector executes well. I run it on my project with these sets:
It worked. Running my application works. I assume there's no leftover PHP 7.3/7.2 code (no dependency currently uses 7.4), for which we haven't created the Rector rule yet, because running Rector on PHP 7.1 didn't complain at all. But this is still a guess: to be sure, we'd need to check all code from all 3rd party dependencies and make sure no unsupported feature is there.
I also attempted set
SetList::NAMING
at the end of this list, but this one thows this error:And then huge amount of erros with no message:
I assume this is not connected to the downgrading, but maybe with being applied after the previous list, or maybe this set is buggy. Must research on it.
Also, please not that no downgrade set can be run on PHP 7.1! For instance, to apply the
DOWNGRADE_PHP72
set, the source code is expected to contain PHP 7.2. But then, running Rector on PHP 7.1, it fails to parse that file.All other sets must also be tested on the downgraded code:
Next steps
downgrade-rector.php
in the CI, to generate a new asset. To test it, if using GitHub actions, might require this workflow:SetList::NAMING
doesn't work