feat: authorize adding extra rules, no override allowed

[yannchabed]

Why?

As this config user
I want to be able to add custom rules
And make sure the standard rules are never overriden
In order to share the same cs-fixer rules with the company and, optionnaly, my team's more restrictive ones

TODO

• code is tested
• documentation is updated (if needed)

[Oliboy50]

I thought that the whole point of BedrockStreaming/php-cs-fixer-config was to share the exact same rules between all PHP teams at Bedrock... Isn't it weird to allow custom rules, then? 🤔

[yannchabed]

You're right. We do wish to keep sharing the exact same cs-fixer rules between the company PHP teams.
However, this has some limitations. In case of specific needs per team / project, then we happen to decide extra rules. For now we have no solution to apply them properly and automatically.
The correct wording is extra rules rather than custom rules (I changed it to prevent any confusion).
This feature quarantees that those extra rules do not override the ones defined at the Bedrock PHP teams level.

[Oliboy50]

ℹ️ adding a new item to the $standardRules will be a potential breaking change for those who uses $extraRules

example:

1. Toto uses new BedrockStreaming(['explicit_string_variable' => true])
2. 'explicit_string_variable' => false is added to the $standardRules
3. Toto updates its dependencies and then he cries because its code does not work anymore... Will it pin its dependencies to the previous version? 👀

now, the question for this repository maintainers will be to define if they should bump a new major release each time they add an item to $standardRules or minor release like before

[Fabex]

I think we can take the problem by another angle.
Why not, have an empty configuration and create a BR CS who decorate this empty config. And if a project or team want the same BR CS rules and add his own rule, they could just decorate the BR CS config. And why not add a overrideRules parameter that allow to override all decorated config.

Some pseudocode:
empty config

class EmptyConfig {
    contructor () {
        this->rules = []
    }
}
config = new Config()

BR CS config

class BRCS {
    constructor(config Config, array extraRule, bool overrideRules) {
        this->rule = ["rule1" => true]
        merge rules with override or not
    }
}
config = new BRCS(new Config)

project1 of BR config

class Project1BR {
    constructor(config Config, array extraRule, bool overrideRules) {
        this->rule = ["rule2" => false]
        merge rules with override or not
    }
}
config = new Project1BR(new BRConfig(new Config), ["rule1" => false], true)

It's just pseudocode, and I miss certainly a lot of things, but the idea is here.
What to you think ?

[yannchabed]

Thanks for your suggestion!

I think I understand your suggestion. Technically, it looks ok (although, I think we must forbid overriding). Using decorators looks clean.

However, I think it's a bit overkill regarding the original proposition where we (my team) wish to add a few extra rules to the company rules.

Maybe you've got a more complex use case in mind?

[yannchabed]

Choose another way: increase the README to exploin how to achieve the same goal on the project side ➡️ #25