Open kumar303 opened 8 years ago
I have a patch started but it depends on https://github.com/yargs/yargs/issues/464
FWIW, a yaml config might be nicer than JSON because you could put comments in it
I would suggest making a .js file that exports a settings object instead.
How about using a grunt task ie. Gruntfile.js like we can with jpm
? I feel we are needlessly reinventing the wheel here.
Sure, a .js
file would be nice because you can add comments. I think yargs might need a patch to support that but maybe not.
Looks like something like this should work:
var argv = require('yargs')
.config('settings', function (configPath) {
return require(configPath)
}).argv
web-ext.config.js
module.exports = {
"sign": {
"apiUrlPrefix": "https://addons-dev.allizom.org/api/v3"
}
}
oh cool, that looks like it will work. I like using .js
config files, let's do it.
You could use something like rc to use JSON or INI config files. Or I think ESLint supports config files as:
module.exports
)I believe their specific config loader logic is in eslint/eslint /lib/config/config-file.js.
It looks like rc will parse command line args and env vars but yargs already does that. It would be nice to just fix https://github.com/yargs/yargs/issues/464 but I don't know how difficult that is.
After chatting with @shubheksha yesterday, I think we have a good plan to do this without patching yargs:
default
values~/.web-ext-config.js
and load that file./web-ext-config.js
and load that, overwriting any previous config values--config=web-ext-config.js
and load that, once again overwriting previous values{sign: {apiKey: ...}}
@kumar303 @shubheksha I think that it can be useful to keep an eye to how eslint does its config file loading, e.g. some of the relevant pieces:
Hi @shubheksha , I split this into three issues (linked above). The patch you've already started applies to https://github.com/mozilla/web-ext/issues/728 so don't worry about any other features that we need later on. This should help land each patch sooner!
If a user has a magically named config file in the current working directory (e.g.
web-ext-config.json
) thenweb-ext
should use this to set default option values (and web-ext should log a message about using it). Here are a few other examples of how it should work:The config can also be specified explicitly:
The config file should apply to global option values as well as sub-command option values. Here is an example of a config that is the equivalent of
web-ext --verbose sign --api-url-prefix https://addons-dev.allizom.org/api/v3
:The camel case variants of each option should also be supported, such as:
Some additional rules:
~/.web-ext-config.json
as well as./web-ext-config.json
(these would override each other in the order listed here).