denoland / deno_task_shell

Cross-platform shell for deno task.
https://crates.io/crates/deno_task_shell
MIT License
108 stars 18 forks source link

`deno task` - Support brace expansion #91

Open gaoxiaoliangz opened 1 year ago

gaoxiaoliangz commented 1 year ago

I have this in my deno.json

{
  "tasks": {
    "check": "deno check services/*/{prod,dev}.ts"
  }

When I run deno task check, I got:

Task check deno check services/*/{prod,dev}.ts
error: Error parsing script 'check'.

Caused by:
    Unexpected character.
      {prod,dev}.ts

My deno version:

deno 1.36.3 (release, aarch64-apple-darwin)
v8 11.6.189.12
typescript 5.1.6
bartlomieju commented 1 year ago

@dsherret is this supposed to work?

dsherret commented 1 year ago

No, brace expansion has not been implemented in deno task.

armichaud commented 1 year ago

This is something I'd be interested in taking a crack at. Looking at the GNU docs @dsherret shared, there are a few discrete features of brace expansion we might consider implementing.

  1. Basic: Comma separate string lists, e.g. "deno check services/*/{prod,dev}.ts"
  2. Nested: "deno check services/{service1/{prod,staging,dev},service2/{prod,dev}}.ts"
  3. Numeric Range Expansion: "deno check services/service{0..10[..2]}/{prod,dev}.ts"
  4. Lexicographical Range Expansion: "deno check services/service{a..z}/{prod,dev}.ts"

Should I aim to tackle all four at once? Or should we start perhaps with just the first 1 or 2 and go from there?

armichaud commented 1 year ago

Having looked a bit further into this, I think this would necessitate changes to the deno_task_shell. @dsherret should we transfer this issue there?

armichaud commented 1 year ago

So at the very least, this would require modifying the parser such that curly braces are allowed when applying word parts combinators.

However, the major issue is that the glob module does not support string alternative syntax. A couple potential solutions to this:

  1. Use the globset crate, which supports brace expansion, instead of glob. This, however, will almost certainly behave differently: for example, it doesn't support the require-literal-leading-dot option, which is enabled here. This could be a breaking change.
  2. Write custom logic which runs at some point while we're evaluating word parts inner to replace WordParts that contain curly braces with a number of WordParts representing the expanded strings.

@dsherret between these approaches, what do you think?