Ava: Not accepting globs arguments any more?

[cancerberoSgx]

Just updated ava and I noticed that is not accepting glob patterns as aguments any more. Example, this worked in the previous version:

npx ava "./dist/test/**/*Test.js"

And now it is not. I have to manually expand the pattern :(

`npx ava ./dist/test/Test.js ./dist/test//Test.js``

I notice that the --help mention this "The above relies on your shell expanding the glob patterns."

So I wanted to know if this i the right behavior, and if this was a conscious decision, although I'm new using the library I strongly recommend that you support globs and don't rely on the terminal since basically you are forcing users to test the patterns on every platform if using the CLI

Thanks, keep it up, great library!

[novemberborn]

Per the release notes: https://github.com/avajs/ava/releases/tag/v2.0.0

The CLI now only takes file paths, not glob patterns.

If you want to use glob patterns you should specify them in AVA's config, under the files key.

(I'm closing this issue for housekeeping purposes, but let's keep the conversation going.)

[vladimiry]

Let's say I have 2 npm scripts which work well with ava@^1:

"test:e2e": "ava --verbose \"./src/e2e/**/*.{spec,test}.ts\"",
"test:main": "ava --verbose \"./src/main/**/*.{spec,test}.ts\"",

How do I specify files for each run separately with ava@^2? Does it mean I will have to list each file explicitly? That would be a very bad UX if it's so.

[novemberborn]

@vladimiry for that use case, you could remove the quotes and depending on your shell it should expand to the correct files.

Alternatively you can use ava.config.js, perhaps in combination with an environment variable, so that you can customize files.

I appreciate that this use case isn't as well served now than it was before. It does greatly simplify the file selection logic however.

We have an issue somewhere about being able to specify the config file. Perhaps that would work nicely for your use case?

[vladimiry]

@novemberborn Thanks for the input. Did I get it right that Ava CLI is not going to get back glob files resolving support? Asking since I still like Ava and if glob resolving is not getting back I will just hack the stuff for my particular case like calling Ava through the preload node script.

@vladimiry for that use case, you could remove the quotes and depending on your shell it should expand to the correct files.

Being dependent on the shell would essentially be a hack as that would not be a cross-platform solution. I totally understand that simple preloader-like node script can be used which will glob the files independently and then call either Ava CLI as a shell command or Ava lib programmatically with resolved files list. So that preload-like script would become a custom CLI for Ava. But in such case, it's not fully clear what is the point of Ava having CLI support at all.

If you want to use glob patterns you should specify them in AVA's config, under the files key.

Specifying/hardcoding something in the config file is obviously not the CLI way of doing things.

[novemberborn]

Did I get it right that Ava CLI is not going to get back glob files resolving support?

@vladimiry I'd really rather not. But let's figure out how to best support this use case that does not require terrible hacks.

Being dependent on the shell would essentially be a hack as that would not be a cross-platform solution.

Fair enough.

If you want to use glob patterns you should specify them in AVA's config, under the files key.

Specifying/hardcoding something in the config file is obviously not the CLI way of doing things.

It can be a reasonable compromise, though.

Again if we had a --config option and you could select a file appropriate for the set of tests you'd like to run, would that work?

[vladimiry]

Again if we had a --config option and you could select a file appropriate for the set of tests you'd like to run, would that work?

Yes, this would allow solving the use case. I'd suggest waiting for a while, maybe there will be other ideas. Or the need won't be in demand and so no need to do anything.

[novemberborn]

I've finally dug up the issue: https://github.com/avajs/ava/issues/1857

We're definitely open to landing this.

[vladimiry]

Great as that would be the most holistic solution allowing overriding not only the files to test but all the config parameters per specific run.

[novemberborn]

Hey @vladimiry could you give https://github.com/avajs/ava/pull/2166 a try?

[vladimiry]

@novemberborn it seems to be working but doesn't recognize relative to config file glob paths which is somehow confusing. So this works (config file located in src/main):

    "files": [
        "src/main/**/*.spec.ts"
    ],

But this doesn't (in this case it resolves all the *.spec.ts files located in the project directory, ie not only files from src/main):

    "files": [
        "./**/*.spec.ts"
    ],

Anyway, I'm still thinking of using loader script that will resolve the globs based on the CLI argument and pass it the to ava which will essentially get back ava@1 behaviour. There are projects I intentionally made to have zero JavaScript files but ava currently support JS files only as external config (no YAML, no JSON, etc).

[novemberborn]

Oh that's interesting, I hadn't considered using config files in subdirectories. I should be able to make that work, though worst case we'll have to reject config files that are in the "wrong" place, at least for now. We'll see how much time I have.

[novemberborn]

Of course if you extend a config file from a different directory you'll have to rewrite the glob patterns… it may be easier to understand if top-level is enforced.