Command line tool

[olivernybroe]

So as drift is going to have a command line tool, I think we should discuss how the command should work and what should be available.

My first idea is the following

# Change the code to pest test classes
$ drift migrate {path}

# Show the diff instead of actually changing the code.
$ drift show {$path}

Would love to hear if you guys have some better ideas for naming 👍

For example rector uses the following syntax

# Change code based in the specified path based on the specified set
$ vendor/bin/rector process  {path} --set {set-name}

# Show the diffs instead
$ vendor/bin/rector process  {path} --set {set-name} --dry-run

[olivernybroe]

An issue that came to me is how a user should be able to specify if they just want to run some rectors. Let's say a user has pest tests already and want to change them to higher order tests, how should this be specified?

Ex.

$ drift migrate {path} --only=higher-order-tests

[alexmartinfr]

Since migrating tests will mostly consist in "cleaning" them up*, we could go with a more fun & expressive syntax:

# Change the code to pest test classes:
$ drift polish {path}

# Show the diff instead of actually changing the code:
$ drift show|check {$path}

That way we keep the naming metaphor going on 🙂 I'm not sure which is best between show & check. I think both would work and are short though!

• Unless I'm missing the point on what you intend Drift to do?

[alexmartinfr]

An issue that came to me is how a user should be able to specify if they just want to run some rectors. Let's say a user has pest tests already and want to change them to higher order tests, how should this be specified?

Ex.

$ drift migrate {path} --only=higher-order-tests

How would that work with tests that use named routes?

[olivernybroe]

Since migrating tests will mostly consist in "cleaning" them up*, we could go with a more fun & expressive syntax:

# Change the code to pest test classes:
$ drift polish {path}

# Show the diff instead of actually changing the code:
$ drift show|check {$path}

That way we keep the naming metaphor going on 🙂 I'm not sure which is best between show & check. I think both would work and are short though!

• Unless I'm missing the point on what you intend Drift to do?

I like the idea of having some naming that is more in the style of the naming, keeping it fun while still explaining 👍

I like show the most, as the command will "show" a diff.

[olivernybroe]

How would that work with tests that use named routes?

Not sure I follow your question 😃 Could you explain a little more in detail what you mean.

[alexmartinfr]

(This was out of topic, moved to #5)

[olivernybroe]

Ah, thanks for explaining. The parameter where I specified higher order methods was just an example it could for example also be order tests alphabetically or something else.

I don't have a solution for that scenario yet. I opened an issue about creating that rector #5. So I think figuring out a way to avoid that problem should be left to that issue. 🙂

[alexmartinfr]

You are right, I digress.

1 - Back on track (no pun intended), we'll need a help function to explain the API to a first time user:

# Display drift's API
$ drift --help | drift -h

2 - What if a user want to revert back to PHPUnit tests? Should he just go back to his previous commits (not optimal imho), or use that kind of command?

# Converts back to PHPUnit
$ drift reverse {$path}

[olivernybroe]

@AlexMartinFR Yep, we totally need a help method 👍

Hmm, I like the idea about a reverse command, however it would require us to make a rector that converts pest to phpunit.

[olivernybroe]

We got a basic command line now, let's close this issue and open specific ones things missing in it or improvements that we could make.