Personally I'm inclined to bump the PHP requirement up to 7.3 or 7.4, given that even 7.2 is about to get EOL'd. And 7.4 is not a very big leap from 7.3.

Rector looks pretty swanky, and if I'm understanding correctly, it wouldn't be a runtime dependency, nor even a permanent dev dependency - we'd only need it for the duration of a hypothetical migration. (Of course we could keep it around for more ongoing/sustainable maintenance, but the point is that we don't really have to think about it outside the context of migrations.) Is that right?

My only reservation is some potential subtlety in an automated change breaking the API in a hard-to-detect way. So once the 2.x is totally solidified, I'd want to run Rector in at least two phases - first for production code (lib) and then make sure all the completely unchanged tests still pass. Then and only then would we run a migration on tests. Seems like it's designed for that kind of incremental migration so I don't see this being a problem in theory.

All that is to say, I'm open to it, and Rector seems like it could be a game-changer in terms of the feasibility of actually getting such a migration done. That said, this should be part of the discussion already happening on #1863.

Uh oh!

Modern code in the repo #2339

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions