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

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?

I need this also!

+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

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

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 😄

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.

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"
}

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.

@novemberborn like it

@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.

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.

https://github.com/avajs/ava/issues/2152#issuecomment-499810046

Jus tried that and worked like a charm.

export default () => {
  let files;
  if (process.env.TEST_MODE === "integration") {
    files = ["test/integration/**/*.test.ts"];
  } else {
    files = ["test/unit/**/*.test.ts"];
  }

  return {
    compileEnhancements: false,
    extensions: ["ts"],
    require: ["ts-node/register", "dotenv/config"],
    files: files
  };
};

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.

Shouldn’t relative paths be allowed? For example:

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

@rauschma I believe location is forced for now https://github.com/avajs/ava/pull/2166#issuecomment-507039490 Didn't try it yet though.

@vladimiry Yes it is, I just tried it.

@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 https://github.com/avajs/ava/issues/2185 to discuss solutions.