Open prabirshrestha opened 2 weeks ago
Are you using Grit outside a terminal shell? I regularly use globs, but the shell has built-in expansion support.
Ex. I just ran:
$ grit apply '`console.log`' **/*.test.js
I'm using it under bash. Seems like it partially works.
Here is a failing case. Notice how the dir
doesn't contain any *.test.js
file.
$ tree
.
├── a.js
└── dir
└── c
├── b.js
└── b.test.js
3 directories, 3 files
$ grit apply '`console.log`' **/*.test.js
ERROR (code: 100) - **/*.test.js: IO error for operation on **/*.test.js: No such file or directory (os error 2)
Processed 0 files and found 0 matches
Now If I add a dir/d.test.js
it works.
$ touch dir/d.test.js
$ tree
.
├── a.js
└── dir
├── c
│ ├── b.js
│ └── b.test.js
└── d.test.js
3 directories, 4 files
$ grit apply '`console.log`' **/*.test.js
Processed 1 files and found 0 matches
I expect **
to recurse the dir.
Unfortunately we can't control how bash handles directory traversal.
We might consider our own glob matching in the future but I also want to avoid too much scope creep.
For now you might want to try an alternative shell like zsh. Or using a util like find/xargs to feed paths into the Grit CLI.
Haven't looked at the code yet but my thought was that the last arg to grit apply was just glob pattern which could be solved by using crates such as glob and that the rust code actually does the traversal of the directory.
In javascript/typescript world it is common to separate files using
app.test.js
vsapp.js
. Sometimes I want to run apply only for*.test.js
. Would be good if it support glob pattern for paths when using apply.