[feature request] Validations accept arrays, just like filters

[meleu]

The custom filters for commands accept an array of functions to be executed before running the command.

I'd like custom validations to also accept an array of functions.

---

Sharing the scenario where I noticed the lack of such feature.

I'm creating a random number generator for a bashly tutorial, and at some point of the tutorial I have this in the bashly.yml

# ...

flags:
  - long: --max
    arg: max
    help: Specifies the maximum number to be generated
    default: "32767"
    validate: positive_integer

The next step of the tutorial is to add the --min flag, which adds a new scenario to be validated: min must be less than max.

I'd like to be able to do something like this:

# ...

flags:
  - long: --max
    arg: max
    help: Specifies the maximum number to be generated
    default: "32767"
    validate:
      - positive_integer
      - greater_than_min
  - long: --min
    arg: min
    help: Specifies the minimum number to be generated
    default: "1"
    validate:
      - positive_integer
      - less_than_max # <-- actually not needed (redundant)

[DannyBen]

An argument can be made for both sides:

1. On one hand, this is a reasonable request, and is probably not difficult to add
2. On the other hand, this can be easily done by creating a small function that calls the other two validation functions.

Do you want to take a deeper look at possible implementation, or should I?

[meleu]

this can be easily done by creating a small function that calls the other two validation functions.

Yeah, if it was a "real-life" scenario I would probably solve the issue like this and move on...

But as I'm writing a Bashly tutorial, wanting to highlight how it can make our code easier to handle, I came here with this request... 🙂

The motivation is that I think this:

  - long: --max
    arg: max
    validate:
      - positive_integer
      - greater_than_min

looks more intention revealing than this:

  - long: --max
    arg: max
    validate: max_number

By "intention revealing" I mean: promptly provide useful information for the future maintainer about all the criteria this argument must meet.

My hope is to save future maintainer's time. Maybe they will be unfamiliar with bashly and I want to avoid:

• forcing them to be aware that a validate_max_number function exists,
• search for the function in the codebase to be aware about the validations criteria.

---

Do you want to take a deeper look at possible implementation, or should I?

That could be a good opportunity for me to get more familiar with the codebase. 🧑‍💻

Could you please just show me the files I should start looking at?

[DannyBen]

You had me at "intention revealing" :)

Let's do it. Keep in mind this is probably a bigger change than you are used to, and I will probably look at the changes with a more critical eye.

I am going to finish some refactoring with all the link changes in the 4 repos, and will post here with some of the files and techniques to get you started. At any time, if this seems like more than you intended to invest in it, let me know.

[DannyBen]

Ok - so some high level "getting started" points to start this change.

Note that I did this writeup mostly from memory - so some things may be wrong or I may have missed some steps.
If something is not clear or "not as expected" - let me know.

Development

1. Since there is already another field that behaves like this, always refer to how it is handled and replicate.
2. First, I would create a new bashly environment inside ./dev (which is gitignored) - run bashly init, and create an array field.
3. Then, run bashly validate - the validation should fail.
4. Now, I would go to ConfigValidator to allow it to receive an array.
5. Running bashly validate now should pass.
6. Next, I would generate a bashly script in my ./dev folder, but with normal string filters
7. Noe you can look at the generated script, and look for where the filters are handled. This will give you the name of the template that handles it.
8. Then we can look at this gtx template, compare it with the one that handles filters, and do the same here.
9. Then you should be able to generate a script with array validations

If this portion was completed successfully, then the majority is done, with these appendix tasks remaining:

Specs

1. Create a test and if needed example for it - in this case, the validations example is a great place to serve both purposes. Just need to update the bashly.yml to show (and explain via a comment) the two formats, and run the tests.
2. A good way to run the tests in this case, is using my respec rspec wrapper - then I just run something like this: EXAMPLE=validations respec only examples - otherwise your dev-test-fix cycles will be long.
3. Another advantage of respec which is useful in a large test suite like bashly's is that you can "continue on failure" easily - you first run respec to test the entire suite, if it fails, you fix, and then can run respec continue.

Schema

When testing is do, it is time to update the JSON schema. We do this by editing a YAML file, which is easier to edit.
It is found in the support/schema folder. We edit it, and then can run bundle exec run schema generate to rebuild the JSON output.

Running bundle exec run will show other available commands, and specifically bundle exec run schema. These tasks are provided by the runfile file at the root dir.

Docs

When this is all complete and pushed as a PR, and verified, documentation should be updated - but I can do it once you reach this point.

[DannyBen]

I would like to start finalizing version 1.3
Do want to include this feature in it?

[meleu]

I won't be able to really focus on this until next weekend. Then, no need to hold a new release because of this.

[DannyBen]

Tracked in #658