feature request: cli option of config file --config-file [path]

[iamstarkov]

Prerequisites

• issue isn't reported

Description

hi 👋,

I'm attempting to build nodejs flavour of react-scripts from create-react-app. But instead of jest I would love to use ava. Unfortunately, there is no way to put config inside the project itself. Currently it gotta be either in package.json or in ava.config.js. It will help a lot if I can point ava to the relevant config.

It's very common feature, i can help to implement it.

Relevant Links

• https://github.com/iamstarkov/zen-scripts here is it

---

IssueHunt Summary

Sponsors (Total: $60.00)

• issuehunt ($60.00)

Become a sponsor now!

Or submit a pull request to get the deposits!

Tips

• Checkout the Issuehunt explorer to discover more funded issues.
• Need some help from other developers? Add your repositories on IssueHunt to raise funds.

[novemberborn]

Yes we left this as a follow-up. Some things to consider:

• Should this silently override config from package.json#ava / ava.config.js?
• Should we allow a package.json#ava.config value so you don't need to provide the argument?
• And if so, what if package.json#ava contains other properties?

[bichikim]

I need this also!

[cantremember]

+1

in my case, as in my comment against #1820, i can't use esm + { mode: "strict" } if 'ava.config.js' doesn't have an .mjs extension (because currently the file must use ESM export syntax)

ava --config ava.config.mjs or some equivalent would be very helpful. until then, i am relegated to using { ava } in package.json

[bichikim]

Maybe we will run into a problem which a project root folder has so many xxx.config.js files
so I mostly move those things into /config
owing to Ava is not supporting ava --config xxx the Ava config remains in a project root folder.
it is so sad 😭

my opinion

• Yes it Should override or ignore all the config silently
• no because it means I don't want to use package.json#ava.config or projectRoot/ava.config.js

[novemberborn]

my opinion

Should -c xxx override(disable) all config
no because -c means I don't want to use package.json#ava.config

@bichikim could you clarify your answer? It doesn't quite map to my questions, and I don't want to presume anything 😄

[bookmoons]

Would also appreciate this. I'd like to make the config file a dotfile. Try to put them all in dotfiles to shunt them out of view.

[bookmoons]

Should this silently override config from package.json#ava / ava.config.js?

Seems sensible. If someone explicitly specifies a custom config file, probably not surprising if that becomes the sole config.

Should we allow a package.json#ava.config value so you don't need to provide the argument?

The command line argument would work fine for me. I set up an npm script to run ava, so that's a fine place to put the arg. I do JSDoc that way - one config file, one arg in the script.

Another benefit to this would be easy setup of separate test suites. Just make a config file for each, and an npm script for each. Clean all around.

npm run unit-test
npm run integration-test
npm run network-test

"scripts": {
    "unit-test": "ava -C .unittest.conf.js",
    "integration-test": "ava -C .integrationtest.conf.js",
    "network-test": "ava -C .networktest.conf.js"
}

[novemberborn]

Should this silently override config from package.json#ava / ava.config.js?

Seems sensible. If someone explicitly specifies a custom config file, probably not surprising if that becomes the sole config.

I agree. The implicit question is whether we should print a warning.

Should we allow a package.json#ava.config value so you don't need to provide the argument?

The command line argument would work fine for me. I set up an npm script to run ava, so that's a fine place to put the arg. I do JSDoc that way - one config file, one arg in the script.

I frequently use npx ava. Having to specify the --config argument would be bothersome. So I'm 👍 on a package.json#ava.config option, but in that case I do think we should exit if package.json#ava contains other options.

[iamstarkov]

@novemberborn like it

[IssueHuntBot]

@issuehunt has funded $60.00 to this issue.

---

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.

[dougmaitelli]

I was looking into the code to make the change.
The problem is that cli is parsed by meow and the default values (which come from the config file) are passed as parameters to meow.
So, if you want meow to parse a --configFile flag it would cause problems, because before having the configFile value meow would need to know the current default value for all other options in cli (which need to come from the config file that we do not know at this point yet).

The only options I can think about are:

• Change meow to accept this kind of feature (probably not the best approach)
• Call meow twice, first time to parse the config file, second to parse the rest (this works but is ugly)
• Do not use meow default values

Something I saw someone else suggesting in another thread is to just use environment variables in ava.config.js to export the config for each scenario. This solution makes more sense to me at this point.

#2152 (comment)

[novemberborn]

We could use a different library to look for the --config argument. Or re-parse the arguments with different defaults, I think that's fine too.

Something I saw someone else suggesting in another thread is to just use environment variables in ava.config.js to export the config for each scenario. This solution makes more sense to me at this point.

Regardless we're still keen on a --config feature.

[rauschma]

Shouldn’t relative paths be allowed? For example:

ava --config ava-configs/typescript.config.js

[vladimiry]

@rauschma I believe location is forced for now #2166 (comment) Didn't try it yet though.

[rauschma]

@vladimiry Yes it is, I just tried it.

[novemberborn]

@rauschma it's hard to know how to interpret the various relative glob patterns, Babel options and require paths in a nested configuration file. Rather than come up with a perfect solution I figured we'd at least ship this one.

I've opened #2185 to discuss solutions.