Can nabs do anything to make it easier to manage scripts with arguments

[breathe]

Suppose I have npm scripts like this:

"some:process": "...",
"some:process:variant1: "npm run some:process -- --someArg variant1",
"some:process:variant2: "npm run some:process -- --someArg variant2",
"some:process:variant3: "npm run some:process -- --someArg variant3",
"some:process:variant4: "npm run some:process -- --someArg variant4",
"some:process:variant1:a": "npm run some:process -- --someArg variant1 --someArg2 a",
"some:process:variant2:b": "npm run some:process -- --someArg variant2 --someArg2 b",
"some:process:variant3:c": "npm run some:process -- --someArg variant3 --someArg2 c",
"some:process:variant4:d": "npm run some:process -- --someArg variant4 --someArg2 d",

(Note I'm not yet using nabs -- the above use of ':' in above example comes from an existing convention I'm using in my project -- some:process is not a parent of each variant in the nabs sense but rather a generic version of a process that can be run in different ways -- i should probably not have used ':' in my example -- imagine some other delimiter instead)

Can nabs help with (or grow features to help with) managing really regular run-script patterns like this?

My real project has a list of run-script entries like: some:process(1..N):variant(1..K):variant(1..J). I use this pattern to represent the different processes that can be run and the different arguments each process can meaningfully be run with. The goal of this pattern is to statically enumerate the different meaningful process execution scenarios and avoid passing arguments to npm run via -- this works well with tools like vscode that provide functionality to invoke package.json scripts and simplifies/controls the interface between the run scripts and external automation agents like jenkins or other CI.

It would be nice to figure out a way to not have to manage K*J nearly identical run-script entries for each N ... Could something be added to nabs to support this?

[artlogic]

@breathe This is a very interesting idea. I think the challenging part is getting the syntax right for the YAML file. I can try an come up with something appropriate, but if you have ideas I'd certainly welcome them. My initial thought is something along these lines:

some:
  process:
    "variant[1-4]":
      $action: "blah --someArg variant{}"
      "[a, b, c, d]":  "blah --someArg variant{} --someArg2 {}"

What do you think? Thanks for the suggestion!

[breathe]

@artlogic I'm not quite sure that I understand the syntax suggestion above. Questions that pop into my mind: Squashing the list arguments into strings might be error prone? Would I be able to fit non-range arguments into the lists and could I reuse the same lists for different commands?

To spitball another idea -- perhaps something vaguely inspired by ansible syntax ...

$data:
  variants:
    - variant1: a1
      variant2: b1
    - variant1: a2
      variant2: b2
    - variant1: a3
      variant2: b3
    - variant1: a4
      variant2: b4
    - variant1: a5
      variant2: b5

some:
  process:
    $template: "blah --someArg1 {{ item.variant1 }} --someArg2 {{ item.variant2 }}"
    $items: $data.variants
  processWithoutArg2:
    $template: "blah --someArg1 {{ item.variant1 }}"
    $items: $data.variants

...?

[texastoland]

This was already on my list. My proposal is to just pass agrs to $depend:

some:
  process:
    $depend: ~ # don't batch child scripts
    $action: ...
    variant1:
      $depend: some:process --someArg variant1
      a:
        $depend: some:process:variant1 --someArg2 a
# etc.

To spitball another idea -- perhaps something vaguely inspired by ansible syntax ...

Variable templating is a separate issue also on my list. Super straightforward with js-yaml but still ironing out my proposal. Simplicity will be key.

[artlogic]

@breathe Sorry for the long delay in responding. Let me try and explain a bit more - basically the idea is that an item name containing square brackets represents something you can iterate over, and supports syntax for ranges - for example:

"variant[1-4]":
  $action: "blah --someArg variant{}"

Would expand to:

"variant1": "blah --someArg variant1"
"variant2": "blah --someArg variant2"
"variant3": "blah --someArg variant3"
"variant4": "blah --someArg variant4"

I'm not sure the ranges that would be supported, but in the case of something not range-able, you would just list items directly: "[a, b, c, d]" or even "some[one, two, three]item".

Some other points you brought up:

Squashing the list arguments into strings might be error prone?

Given that everything ends up being a string anyway, I think it's pretty safe to think of all list items as strings to begin with. Do you have a specific example.

...could I reuse the same lists for different commands?

The scheme I'm suggesting wouldn't allow for re-use of lists, unless you look at the case where the list you're reusing is a parent - like a nested loop. Do you have a need for re-use beyond this?