Skip to content
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

Rewrite for the PHP CLI? #20

Open
stevegrunwell opened this issue Dec 2, 2015 · 8 comments
Open

Rewrite for the PHP CLI? #20

stevegrunwell opened this issue Dec 2, 2015 · 8 comments
Assignees
Milestone

Comments

@stevegrunwell
Copy link
Owner

I'm considering rewriting the main wp-enforcer Bash script in PHP. It would still be run the same way, but rather than dealing with a very procedural scripting language we could a) leverage the PHP CLI Tools package maintained by the WP-CLI team, b) make testing the code for this [very WordPress-specific tool] way easier (see #16), and generally make the script more portable (considering the package is installed via Composer and thus only available in environments that can already execute code via the PHP CLI).

Anyone want to either talk me off that ledge or convince me to take the plunge before we hit a 1.0.0?

Cc: @bswatson @daveross @ericmann

@johnpbloch
Copy link
Collaborator

👍

1 similar comment
@bswatson
Copy link
Collaborator

bswatson commented Dec 2, 2015

👍

@ericmann
Copy link
Collaborator

ericmann commented Dec 2, 2015

Anyone want to either talk me off that ledge

No, but I'll gladly give you a friendly shove ...

or convince me to take the plunge before we hit a 1.0.0?

A rewrite in a different language can potentially break backwards compat. If you're going to retain back-compat, by all means ship 1.0 and we can do a rewrite afterwards. If it's going to be a major usability change, we'd have to bump to 2.0 and provide upgrade instructions and whatnot. While semver allows for major releases to break compat, I think it's a really mean thing to do.

Particularly if people use 1.0, then find 2.0 is effectively a completely different product. If you're OK with that, ship. If it makes you as queasy as it does me, let's hold the release until post-rewrite.

@stevegrunwell
Copy link
Owner Author

@ericmann you raise some very valid points – the goal is to not change the way the script works at all, just write it in a way that will be easier to maintain (as @daveross and @bradp have proven my Bash skills could use some work) and for other PHP devs to contribute to.

Also, PHPUnit. I loves me some PHPUnit.

@johnpbloch
Copy link
Collaborator

Also, PHPUnit. I loves me some PHPUnit.

got _6839d07db570250122cb4837d5738760

@stevegrunwell
Copy link
Owner Author

An update on this:

In what little free time I've had recently I've started work on a more generic "Git hooks via Composer"-type package, which will then be utilized by WP Enforcer 1.0+ to have a more PHP-powered experience.

More details coming at a later date. For now, it's Star Wars' Day!

@stevegrunwell stevegrunwell self-assigned this Dec 18, 2015
@stevegrunwell stevegrunwell added this to the 1.0.0 milestone Dec 18, 2015
@stevegrunwell
Copy link
Owner Author

Ahead of this I've started work on a more abstracted Git Hook package for Composer, with the goal of that being the underlying tool and WP Enforcer becoming a WordPress-specific implementation of GitHook'd. My hope is that would easily allow other devs to spin up projects like Drupal Enforcer, "PSR, PLS", and other clever Git Hook-powered packages.

@stevegrunwell
Copy link
Owner Author

Another update: GitHook'd was a dumb name, and I know a lot more now than I did at the time.

Smee is the current plan, with WP Enforcer being rewritten as a WordPress-specific implementation of that library. Work is happening, just very, very slowly.

I blame the toddler.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants