Closed danieliser closed 4 years ago
Some 1.1.0 improvements are going to cause merge conflicts with this.
They aren't that complicated, but GitHub can't resolve them on its own.
Milestoning this for 2.0 for now, and when there is a relevant release/2.0
branch to merge this into, I'll be sure this goes in right away.
Read over the arguments in the other topics, gotta be honest, even Automattic doesn't adhere to the class- prefix.
Further we are talking about using a composer package inside a plugin/theme, anybody that far down the rabbit hole is beyond what they coding standards recommend anyways. I know we don't use class- prefixes in any of our plugins and haven't for a while.
In our case we have disabled that particular CS check.
Lastly this package claims to not be dependent on WP at its core, this means following that standard puts off those who may consider it for other projects. Best to stick with modern standards for a generic (non-WP only) package.
Thus this serves to: Replaces #6 - Without the merge conflicts. Resolves #2 - Assuming you want PSR-4 support. Related to #5 as it needs a composer.json to be submitted to packagist.