Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
1 task done
iamstarkov opened this issue Jul 3, 2018 · 17 comments · Fixed by #2166
Closed
1 task done

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

iamstarkov opened this issue Jul 3, 2018 · 17 comments · Fixed by #2166
Assignees
Labels
💵 Funded on Issuehunt This issue has been funded on Issuehunt enhancement new functionality help wanted scope:internals

Comments

@iamstarkov
Copy link
Contributor

iamstarkov commented Jul 3, 2018

Issuehunt badges

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


IssueHunt Summary

Sponsors (Total: $60.00)

Become a sponsor now!

Or submit a pull request to get the deposits!

Tips

@iamstarkov iamstarkov changed the title feature request: config file --config-file [path] feature request: cli option of config file --config-file [path] Jul 3, 2018
@novemberborn
Copy link
Member

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
Copy link

bichikim commented Jul 6, 2018

I need this also!

@cantremember
Copy link

cantremember commented Jul 7, 2018

+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
Copy link

bichikim commented Jul 13, 2018

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
Copy link
Member

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
Copy link

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
Copy link

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
Copy link
Member

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
Copy link
Contributor Author

@novemberborn like it

@IssueHuntBot
Copy link

@issuehunt has funded $60.00 to this issue.


@dougmaitelli
Copy link

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)

@dougmaitelli

This comment has been minimized.

@novemberborn
Copy link
Member

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.

@novemberborn novemberborn self-assigned this Jun 23, 2019
novemberborn added a commit that referenced this issue Jun 23, 2019
novemberborn added a commit that referenced this issue Jul 7, 2019
novemberborn added a commit that referenced this issue Jul 7, 2019
@rauschma
Copy link

Shouldn’t relative paths be allowed? For example:

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

@vladimiry
Copy link

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

@rauschma
Copy link

@vladimiry Yes it is, I just tried it.

@novemberborn
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
💵 Funded on Issuehunt This issue has been funded on Issuehunt enhancement new functionality help wanted scope:internals
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants