search

10up / wpcs-action

GitHub Action to help you lint your PHP without additional dependencies within your codebase
MIT License
54 stars 13 forks source link

Include VIP Coding Standards with 10up Default. #25

Closed peterwilsoncc closed 1 year ago

peterwilsoncc commented 1 year ago

Description of the Change

Since https://github.com/10up/phpcs-composer/commit/5f9ac994db1af9924a71b0f5663fe7f6bd59c812 the 10up Default coding standards require the WordPress VIP sniffs be installed. This includes the sniffs with the 10up-Default ruleset.

Closes #24

How to test the Change

Changelog Entry

Fixed - Include WP VIP coding standards with 10up-Default sniffs.

Credits

Props @peterwilsoncc

Checklist:

peterwilsoncc commented 1 year ago

LGTM.

Works as expected: 10up/simple-podcasting@1a97247

May produce new errors and warnings on existing projects because of rulesets change.

@cadic @dkotter Do you think we should hold of merging for now and consider changing to using numbered versions in the OSP repos, rather than stable?

dkotter commented 1 year ago

Do you think we should hold off merging for now and consider changing to using numbered versions in the OSP repos, rather than stable?

Hmm... yeah, not sure here. I recently thought that we should change all our public Actions to use version numbers in their releases, which seems to be the standard there (so instead of including stable or a release like 2.0.0, you include v1 or v2. I don't think our Actions work like this right now).

That's a slightly different, though similar, thing then what's at play here. The concern as I see it here is if we merge this in, it could start causing failures on existing projects due to the new rules. While it would be great to update any project that uses this Action to reference a tagged release instead of stable, not sure how realistic that is.

I guess I lean towards merging this in and not seeing it as a bad thing if new issues are flagged that need fixed. But then would love to get on a more normal release pattern (and update docs) so projects aren't loading straight from stable. Any thoughts on this @jeffpaul?

jeffpaul commented 1 year ago

1) I'm fine merging this in. 2) I'm fine with projects referencing stable if we effectively want to be on the latest version of an action. 3) I'm also with projects referencing a specific release branch, e.g. v2, if we want to maintain functionality and avoid breaking changes.

So, kinda saying... YOLO I guess?

peterwilsoncc commented 1 year ago

Thanks Jeff. YOLO!