What is the recommended way of including the same rector in multiple projects?

[freiondrej-lmc]

Hello,
first, kudos to the Rector team, it is a wonderful project with an enormous potential for the coming years!

We are considering in the team to have a shared rector configuration and custom rules for multiple repos. Is there a recommended way to distribute these? Maybe in a way of some kind of rector extension (in the form of a composer package)? We are using monorepo approach, so maybe the right way to go would be to have one single rector for all the other repos which would access it as a relative path ../rector? That would mean that we wouldn't have to update composer.lock in all our repos when we update a custom rule / change the config, moreover the config for all projects would be the same (because all the repos would use the shared one in ../rector). I hope this is understandable, let me know if I should provide some examples.

And an additional question - in each repo, we currently have rector separately from the root composer.json (the original thought was easier maintenance, because the dependencies of the project don't block rector's and vice versa) in the project root folder we havecomposer.json without rector and there is a directory called rector with a dedicated composer.json which requires rector/rector in its require section plus phpstan/phpstan and phpunit/phpunit in its require-dev section to analyze and test custom rules. The rector config then specifies the Option::PATHS to be __DIR__ . '../src' and it has worked properly so far. Is this the right approach, or should we have rector/rector in the require-dev section of the main composer.json? (we also have a dedicated ecs and phpstan mini-projects).

Thank you! 🙂

[samsonasik]

My take is always use rector.php per-project, you can use rector.php for shared project, and working on some cases, but will fail eventually due to different dependencies with different projects, that's will be hard to debug. To reduce vendor/rector installation, you can do:

1. Install Rector globally (still, not recommended, but may work for limited resource):

composer global require --dev rector/rector

2. Create rector.php per-project basis, you can start with :

rector init

[freiondrej-lmc]

Thank you @samsonasik for your advice :) just a couple more clarifications:

1. how should the custom rules be distributed? In a custom composer library? Are there any docs resources how to do this?

2. does that mean that when the team decides for e.g. some rule settings change, this must be changed manually in every project of the monorepo? Or could some configuration be part of a custom composer library, which means it can be updated as a dependency and the new configuration will then immediately take effect? E.g. the main rector.php would contain require_once __DIR__ . '/vendor/company-name/custom-rector-rules/config.php'; ?

[Wirone]

Personally I would discourage everyone for installing anything globally. Each project should be standalone with own dependencies and tools' configuration. In terms of Rector you should configure rule sets depending on the project etc, customise some rules etc. And ideally each project should be encapsulated within specific runtime (Docker, Vagrant), but that's different story 😉

[samsonasik]

@freiondrej-lmc

1. you can publish your own custom rule in the separate repository/directory, this post seems may help https://alanstorm.com/composer-path-repositories/
2. you can import config via $containerConfigurator->import(), see https://github.com/rectorphp/rector-src/blob/86eb0dd3632cac7e97fc21c3f59f0e80d6a9d579/build/config/config-downgrade-parallel.php#L9