Best practice tweak regarding the use of PHPCompatibility.
It is strongly recommended to use inline ignore annotations when a reported issue is not a problem (because it is accompanied by a `function_exists()`, `defined()` or other check), instead of excluding a rule completely via the ruleset.
Blanket code-base wide ignores mean that:
* ... if a PR introduces new code (or changes existing code) which uses a non-cross-version compatible PHP feature...
* ... and the code doesn't have the right safeguards in place for cross-version compatibility...
* ... PHPCompatibility would not flag it because of the codebase wide ignore...
* ... which could cause problems for the end-users.
Selective, inline ignores ensure that only the annotated error is ignored and only for that specific bit of code, preventing the above described problem.
It also means that when something changes in PHP - like a deprecated method being removed -, you will be notified about the issue again so you can review if the current cross-version compatibility tweak is still the most optimal one.
Long anticipated, finally here: PHPCompatibility 10.0.0-alpha1 🎉
PHPCompatibility 10.0.0 brings huge improvements in both what is being detected (> 50 new sniffs), as well as the detection accuracy for pre-existing sniffs.
Even though still "unstable", it is stable enough for our purposes and the advantages of using it outweigh the disadvantage of it being an unstable version. By setting the `minimum-stability` and `prefer-stable` settings in the `composer.json`, we can ensure that we don't get the `dev-develop` branch, but rather get a `10.0.0` tag, unstable or not.
Includes updating the PHPCS version constraints to match.
Includes updating the exclusions in the ruleset for changes in the error codes due to further changes in PHP having been made (and now being detected).
Ref:
* https://github.com/PHPCompatibility/PHPCompatibility/wiki/Upgrading-to-PHPCompatibility-10.0
* https://github.com/PHPCompatibility/PHPCompatibility/releases/tag/10.0.0-alpha1
As per the options described in https://github.com/PHPMailer/PHPMailer/pull/3202#issuecomment-3212478928.
Note: the linting ignore comment triggers some PHPCS errors (_sigh_), so I'm selectively excluding those.
Alternatively, it could be considered to exclude test fixture files completely from the PHPCS scan.
In a number of places in the code base I came across hard-code error messages, which were not set up to be translatable.
For those I found, I've now fixed this.
Note: I've not added the labels used for logging errors via the `PHPMailer:edebug()` method. If so desired, that could be added in a future iteration.
Existing translation files have not been updated. Translators may need to be pinged before the next release to update the translation(s) they maintain.
Includes a minor tweak to the PHPCS configuration to allow lines in language files to exceed the "120 chars line max" as using concatenation for text strings in translation files will not work with the current way of loading these files and the new "buggy PHP" message is a long text which would result in nearly all translation files throwing the warning.
* PHPCS: rename config file
... to `phpcs.xml.dist` to allow devs to locally overload the file by using a `.phpcs.xml` or `phpcs.xml` file, to, for instance, test out some new rules.
Includes:
* Adding the local overload files to `.gitignore`.
* Adding the standard config file to `.gitattributes`.
* PHPCS: scan missing file
The `get_oauth_token.php` file in the project root seems to have been overlooked when configuring the PHPCS ruleset.
Fixed now by adding it to the file to be scanned.
Includes minor fixes to make the file comply with the configured standard.
* CS: fix two files
Two minor CS fixes.
* PHPCS: miscellaneous changes
* Don't fix the PHPCS/external standards version restraints.
* Add the PHPCS cache file to `.gitignore`.
* Removing the no longer existent `.php_cs` file from `.gitattributes`.
Co-authored-by: jrfnl <jrfnl@users.noreply.github.com>
jrfnl
Juliette