-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Separate phpcs.xml.dist
Files for Each Plugin to Isolate Text Domains
#997
Comments
I spent a bit of time experimenting with some options for this, and while extending rulesets using relative paths is pretty straightforward (see docs), overriding configuration set in one ruleset with another is not as straightforward due to this issue. To address this, we would need to create a new ruleset in the relative directory that includes the base rules from performance lab, and also includes an override ruleset that updates the config value for Ex <?xml version="1.0"?>
<ruleset name="WPP Auto-sizes">
<description>PHPCS rules for the WPP: Auto Sizes plugin</description>
<rule ref="../../phpcs.xml.dist"/>
<rule ref="./override.phpcs.xml"/>
</ruleset> Ex <?xml version="1.0"?>
<ruleset name="WPP Auto-sizes Overrides">
<description>PHPCS overrides for the WPP: Auto Sizes plugin</description>
<config name="text_domain" value="auto-sizes"/>
</ruleset> This starts to seem a bit over complicated, and makes configuring PHPCS locally more difficult. Instead, we might want to prefer updating our workflow action to configure the
|
Thanks @joemcgill. Jetpack use custom package for PHPCS filters for different modules: https://github.com/Automattic/jetpack/blob/trunk/.phpcs.config.xml |
@joemcgill One more thought that comes to my mind is to split the current PHPCS config into a different ruleset file. Later import that ruleset with required overrides at all other places including the root Ex: Config<?xml version="1.0"?>
<ruleset name="WordPress Coding Standards for Performance Plugin">
<description>Sniffs for WordPress plugins, with minor modifications for Performance</description>
<rule ref="PHPCompatibility"/>
<config name="testVersion" value="7.0-"/>
<rule ref="WordPress-Docs"/>
<rule ref="WordPress-Extra" />
<rule ref="WordPress.WP.I18n"/>
<arg value="ps"/>
<arg name="extensions" value="php"/>
<!-- Do not require file headers on generated files -->
<rule ref="Squiz.Commenting.FileComment.WrongStyle">
<exclude-pattern>default-enabled-modules.php</exclude-pattern>
<exclude-pattern>module-i18n.php</exclude-pattern>
</rule>
<!-- Other rules -->
<rule ref="SlevomatCodingStandard.Functions.StaticClosure" />
</ruleset>
Config<?xml version="1.0"?>
<ruleset name="WordPress Coding Standards for Performance Lab Auto Sizes Plugin">
<rule ref="./phpcs.ruleset.xml"/>
<config name="text_domain" value="performance-lab,default,auto-sizes"/>
<file>./admin</file>
<file>./load.php</file>
<file>./modules</file>
<file>./server-timing</file>
<file>./tests</file>
</ruleset>
Config<?xml version="1.0"?>
<ruleset name="WordPress Coding Standards for Performance Plugin">
<rule ref="./phpcs.ruleset.xml"/>
<config name="text_domain" value="default,auto-sizes"/>
<file>.</file>
</ruleset> |
@thelovekesh, thank you for sharing. I've opened a draft PR for testing. Would you please take a look when you have a moment? |
@mukeshpanchal27 @thelovekesh Similar to my feedback in #1012 (comment), I would much prefer to not have individual config files for each plugin, as this creates a maintenance overhead. Part of the benefits of a monorepo is that the "bootstrap code" can be shared, instead of having to duplicate a file that looks almost the same in tons of projects - which also means updating n files instead of 1 file when e.g. something relevant in PHPCodeSniffer or PHPUnit changes. I agree that there may certainly be room for individual tweaks to the config that should only apply to a single plugin. For those cases though, I much prefer the ideas outlined by @joemcgill above. At a minimum, if we create individual config files, they should mostly inherit the overall config file rather than duplicating everything it contains. Last but not least, this also ensures our plugins follow a consistent set of requirements. @joemcgill Regarding your idea of |
@felixarntz I think what you're describing here is exactly what has been implemented in #1002. There is a root |
Thanks @westonruter, I just spotted the PR and noticed it's what I was suggesting :) @mukeshpanchal27 @thelovekesh In that case, all good 👍 |
Fixed in #1002 |
Follow-up: #972 (comment)
Currently, our project utilizes a single
phpcs.xml.dist
file containing text domains for multiple plugins. However, this setup poses a risk of accidental misuse of text domains, especially during copy/paste operations between plugins. To mitigate this risk and enhance code quality, we propose maintaining separatephpcs.xml.dist
files for each plugin.cc. @joemcgill
The text was updated successfully, but these errors were encountered: